6 ms·
We took a similar approach to passphrase stretching in EnvKey v1 [1] (EnvKey is a secrets manager, not a password manager, but uses end-to-end encryption in a s
by danenania 4y ago
We took a similar approach to passphrase stretching in EnvKey v1 [1] (EnvKey is a secrets manager, not a password manager, but uses end-to-end encryption in a similar way). We used PBKDF2 with iterations set a bit higher than the generally recommended levels, as well as Dropbox's zxcvbn [2] lib to try to identify and block weak passphrases.
Ultimately, I think it's just not good enough. Even if you're updating iteration counts automatically (which is clearly not a safe assumption, and to be fair not something we did in EnvKey v1 either), and even with safeguards against weak passphrases, using human-generated passphrases as a single line of defense is just fundamentally weak.
That's why in EnvKey v2, we switched to using high entropy device-based keys for our root encryption keys. It's a similar model to SSH, except that on Mac and Windows the keys get stored in the OS keychain rather than in the file system. Also like SSH, a passphrase can optionally be added on top of the device key.
The downside (or upside, depending how you look at it) is that new devices must be specifically granted access. You can't just log in and decrypt on a new device with only your passphrase. But the security is much stronger, and you also avoid all this song and dance around key stretching iterations.
1 - https://github.com/envkey/envkey https://github.com/envkey/envkey
2 - https://github.com/dropbox/zxcvbn https://github.com/dropbox/zxcvbn
- nequo 4y agoThat sounds like a good idea. Using device-specific keys sounds a lot like Keybase to my naïve ears. Are there any major differences in your design and theirs?
- danenania 4y agoI'm not deeply familiar with Keybase's design, but speaking in broad strokes, our approach is similar. That said, one area that Keybase compromised on that we haven't is offering a web interface. It's well known among security and encryption people that you can't do serious end-to-end encryption in a web app--an attacker with access to the server can just modify the html/js payload, rendering the encryption pointless. Of course, web interfaces are convenient and users want them, so many products give in on this for the sake of UX even though it fully undermines the zero-trust model. EnvKey hasn't though. It has a desktop app and a CLI--there's no web interface.
- eloeffler 4y agoThis is especially bothersome with Bitwarden and the reason I ditched it shortly after trying it. You can use the desktop/mobile clients, but some functions require the use of the web UI and that's a dealbreaker for me... I wish there was a browser plugin that verifies the congruence of the web UI with upstream source - or even better a client that supports all functions that the web UI supports.
- deleted 4y ago[deleted]
- nine_k 4y agoWhat are your expected failure modes? Consider this pretty common scenario: ahe user lost their one and only enrolled device. How can the user reinstate access? I suppose the user must have printed the real root password / secret key / whatever and put the paper somewhere in a safe. That password should allow to reinstate access when all hardware is lost. But it should not be required daily.
- danenania 4y agoGood point. We have recovery keys for this. These are 12 word random phrases generated from a 1952 word list (about 131 bits of entropy). They require email authentication to redeem, so a recovery key by itself isn't sufficient to access an account, though of course they do need to be protected. An org admin can also re-invite a user that loses access this way. The only scenario where you're really in trouble is if you're the only admin, you lose access to your only authorized device, and you lose access to your recovery key.
- bigiain 4y agoApples solution for this with their new hardware 2fa stuff is to not let you turn it on without registering two hardware keys. So perhaps forcing two enrolled devices might work? (I have all my totp seeds on my iPhone and my iPad, for that reason.)
- criley2 4y agoTying my entire life (every account etc) to two devices that can be remote-killed by a corporation which is not your friend is definitely a risk that I would not take. You really keep no access to your life that isn't under someone else's control?
- SSLy 4y agoPlease explain to us how FIDO keys can be "remote-killed".
- criley2 4y agoI was under the impression that the user is using 2 iOS devices as key generators for their 2FA. And Apple can certainly blacklist their device, delete their Account, and remotely disable their devices permanently. If they are just registering yubikeys to their iphone and ipad so they can use their apple account... then sure, welcome to 2012.
- GoblinSlayer 4y agoWhat's the difference from an eternal session?