Hacker News Reader

Comment by ywecur | Hacker News Reader

>In the latter case you will probably be forced to cough up the decryption keys.

Not if you make the users password the key.

I've always wondered, what do you do in the case of a user forgets their password and has to reset it? Reset it and lose all their data?

Seems like the only way.

If a group planned ahead they could give out some secondary kind of key. Gmail gives out these really long codes I can use to login should I not have the authenticator app.

Sorry, I might be missing something here, but would there be any tangible differences between the service provider having access to a secondary key vs them having access to the primary key if both can be used to access your data?

I'm honestly interested because I'm building a distributed system where only the user has the decryption key, and I've always just assumed that password recovery is a lost cause in such systems.

I would assume the recovery key is not stored in plain-text - it's likely hashed, similar to a password. If you need to use it, you enter the (hopefully safely stored) recovery key you have, they re-hash it and compare to the hashed one they keep.

OS X's whole-disk encryption (FileVault 2) similarly creates a recovery key at encrypt-time.

I believe it is the only way if you truly want a single user to have complete control of decryption. There are other solutions if you don't. I heard of one the other day (from MaidSafe maybe?) where you have a shared secret amongst your "friends" and if a quorum of them agree, it can reset your password. I assume this means your data is duplicated and encrypted via that shared secret as well which could be coerced I suppose.

https://en.m.wikipedia.org/wiki/Shamir's_Secret_Sharing

Reply on news.ycombinator.com