Comment by danenania | Hacker News Reader

Comment by danenania | Hacker News Reader

Parent Full thread

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

2 - https://github.com/dropbox/zxcvbn

What 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.

Good 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.

Apples 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.)

Tying 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?

Please explain to us how FIDO keys can be "remote-killed".

I 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.

The obvious question is: what if you lose both keys?

Deep down, I think it's something that requires cooperating with real world entities (governments, banks, basically real world trust), not something that tech bros seem to want to do for ideological reasons

Stop. Humans are the weakest link in security, and doubly so for humans with less training and accountability than myself.

We have already seen cases of SIM swapping attacks. I don’t want to see this to be more widespread.

Only because companies are trying to do this human verification on the cheap. SIM swapping-alike attacks aren't a problem with institutions like banks where they keep ID on file and you can visit in person to prove your identity.

It's even worse now, no company truly locks you out and with enough noise on social media a real human can get you your access back even if you don't have your Yubikey. So it's always vulnerable to social engineering.

Of course I'm not talking about just relying on SIM. Maybe we can stop with the knee-jerk reaction and actually think of how to add better ways to do it. Government IDs could enter as some piece of the puzzle, trusted contacts, yeah, even SIM... At the very least out here in the real world I have some recourse if my ID is stolen, and I don't have to worry about having to buy all my stuff back because I lost my keys.

As I understand it, Keybase actually has a very interesting concept of spreading key materials over your social media. So it's not even unprecedented.

> governments, banks, basically real world trust

surely you're joking, mr. drowsspa

Oh yeah, I guess we can be all about getting 10 yubikeys and keep one in your wallet, another together with your keys, another in your home, bury another in your family's farm, another in a safe in the capital city of every country you visit...

That 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?

I'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.

This 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.

What's the difference from an eternal session?

Reply on news.ycombinator.com