undefined | Better HN

0 pointsdekz14y ago0 comments

> the client gets it at will from the server, decrypts it by prompting for password

That solution doesn't really solve the problems we're seeing all too often these days, user data being stolen and used. How do you determine who gets what encrypted keypair file, what's to stop an attacker from bruteforcing a persons keypair or even selectively attacking someone and decrypting their keypair. (I'm assuming you mean encrypted with a key generated from a PBKDF here).

Authentication is quite the hard thing to accomplish. BrowserID is a step forward for what we have today, but IMO it's not a step in the right direction, it's just moving the burden somewhere else.

0 comments

mmatants14y ago

So the server stores a keypair for the given account, and the keypair is encrypted with the account password. The keypair itself, once "unlocked" on the client-side, is then used to encrypt/decrypt a nonce at login time.

The inherent trait of this approach is that an attacker gets everyone's encrypted keypairs "for free", and can brute-force away. My hope was that the keypair's own encryption is more resilient to brute-forcing than a hash.

But that's very much questionable.

j / k navigate · click thread line to collapse

0 pointsdekz14y ago0 comments

> the client gets it at will from the server, decrypts it by prompting for password

Authentication is quite the hard thing to accomplish. BrowserID is a step forward for what we have today, but IMO it's not a step in the right direction, it's just moving the burden somewhere else.

0 comments

mmatants14y ago

But that's very much questionable.

j / k navigate · click thread line to collapse