You can't get right/left balance metrics with a single pod. Several old metrics are now applied to both feet, so you can compare right to left. EG, if you notice your right leg spring stiffness increasing, but not your left, you know the right leg is getting stronger, which might prompt you to increase the strength in your left leg. That sort of stuff.
But yeah. The goal is to get existing Next Gen Stryd customers to purchase a second Next Gen pod as well as a membership. But for older Stryd pod owners like myself, $250 for two Next Gen pods and a membership is a pretty sweet deal.
Biometrics aren't the second factor when using WebAuthn, the hardware security key is. But anyone with access to the security key can use the second factor. Biometrics would tie the key to you preventing them from being used by others. The best we have right now for unlocking the security key are PINs, AFAIK.
2FA is rife with problems. FIDO2/WebAuthn isn't tied to biometrics and can be inconvenient. TOTP can get out of sync and can be phished. Email can also be phished. Voice and SMS are vulnerable to SIM swaps. Now we're seeing that passkeys are horribly opaque without proper management and at risk of getting lost.
I was very disappointed in that Kickstarter. Yubikey ran a 54% off discount May 4th last year and not knowing when I would get my v2 SoloKeys, I purchased two. I had them within the week and have since integrated them into all my accounts.
I debated backing out of the Kickstarter as the Yubikeys were working so well for me, but decided to stick with it and see what the SoloKey experience would be like. Yeah, disappointing. I ordered USB-A and USB-C keys. The USB-A key doesn't make a good connection with the USB port. It needs to be carefully held to register with the OS, otherwise it doesn't get power.
Some rebuttals to that critique outline that the author doesn't fully understand the arguments Thomas Ptacek laid out, and may have a simplified understanding of PGP:
> On the other hand, virtualization _already_ lets you run whatever arm64 BSD, Linux, or Windows that you want. The trackpad and everything else will work flawlessly thanks to guest additions.
The OpenBSD kernel doesn't support loadable kernel modules, so virtual machine guest additions are not an option for a virtualized OpenBSD.
I would recommend the default be 6 words, and let people choose down to 4, but not lower. At last that way, users know what a "secure default" looks like. Granted, it breaks the four-word "correct horse battery staple" XKCD format, but Randall was in some error with that comic anyway.
Further, sufficiently seeded cryptographically secure RNGs are indistinguishable from true random white noise, so from a practical perspective, there is no point to require "true random".
I audit web-based password generators as a hobby, and this one does well.
What it does well on:
The source code is open source licensed. Passwords are generated in the client, not on the server. The generator is random. The generator is cryptographically secure. The generator is unbiased. Mobile devices are supported. There are no JavaScript trackers loaded on the page. The site is not calling out to external resources without SRI.
Unfortunately, by only choosing 4 random words, the security margin of the passphrase is 52 bits (13 bits per word). This is practical for a hobbyist password cracker to exhaust in an offline attack. The security would be better if 6 random words were chosen instead.
If that password was hashed with a single pass of vanilla MD5, the Jeremi Gonsey's cluster of 8 Nvidia GTX 1080i GPUs [2] would be running at 307,200,000,000 hashes per second.
In order to exhaust half of the keyspace, so odds would be in the favor of the password cracker finding the original hash, they would need to search only 140,737,488,355,328 hashes.
At 307.2 gigahashes per second, this would take approximately 458 seconds, or just under 8 hours using the Niceware list.
However, jumping to 4 random words grows that time by a factor of 65,536, which means reaching 50% exhaustion would take approximately 1 full year. Moving to 5 randomly generated Niceware words, and it's impractical to attempt cracking the MD5 hash.
Cherry-picking 3 words is a little dishonest for the discussion surrounding password security. The right "best answer" for password generation is to use a password manager, no argument there. And I don't know of any password generators that generate passphrases by default, Niceware, Diceware, or otherwise.
But if a user wants a passphrase instead, I don't know of a security expert who would recommend 3 words.
From my testing with Python's base64, hashlib, and passlib.hash modules, SHA-256 prehashing and base64 encoding is only approximately one one-hundredths the total execution time of bcrypt_sha256 for a 4 KB "password". This is why slurping in the password during the initial state isn't noticeably adding to the overall execution time of password prehashing with bcrypt, and it is analogous to why PBKDF2, scrypt, and Argon2 all show constant time in execution regardless of password length- slurping in the password during initialization is a fraction of the execution time.
The sha256/512crypt algorithms, as well as md5crypt, hash the input based on each character in the password. This is why the execution time increases. bcrypt does not do this.
bcrypt is constant-time, not because it truncates at 72 characters. It's constant-time, because it slurps the password and salt once into the state (initial setup), then spends the rest of the time manipulating that state based on the cost (expand key).
Yes, you could pre-hash with sha256crypt or sha512crypt, and that completely works around the password-length performance issue. You pre-hash with bcrypt to get around a maximum length restriction, not to get around a performance bottleneck.
> Seems like this can radically narrow the focus of a dictionary attack.
It's leaking information, and we don't like this, but it's not fatal. 96% will have passwords less than 16 characters (see https://blog.cynosureprime.com/2017/08/320-million-hashes-ex...). This is within the first "step" in the sha512crypt hashing process, and longer passwords may have enough entropy, so learning their length is not providing any practical advantage in cracking the password, should the database be compromised.
The larger concern is CPU load. There are load jumps between 1-15, and 16-23 characters, and 24-80, etc. Even though 96% of users will fall in the 1-16 range, if you put a minimum length requirement of perhaps 12 characters, you may see that you need to decrease your sha512crypt cost to handle your tested load, because more of your users are passing 16 characters in length (yay) than normal (although most will like do exactly 12 characters).