4 ms·

> Let's hope that's not literally the encryption key, but the alternative -- it's a token used to lookup the key in their database -- would completely defeat th

by pfg 9y ago

> Let's hope that's not literally the encryption key, but the alternative -- it's a token used to lookup the key in their database -- would completely defeat the purpose of encrypting the PII with a PBK in the first place?! And, even if it was the literal encryption key, when you change or update your PII, if they don't also keep it on their side, how would they update their secondary encrypted PII record? Without having looked at the actual implementation, here's one option that could work: Upon account creation, the server generates a key pair and a random string - the recovery code. The server stores the public key and an encrypted version of the private key, with the encryption key being the recovery code. Any changes to PII can be encrypted using the public key. The server does not need to store the recovery code (which would beat the whole point of this exercise). Instead, it can simply attempt to decrypt the PII with the user-provided recovery code, and if it succeeds, the server knows the entered recovery code was valid.

zaroth 9y ago
This would indeed work! I'm still studying their code for handling the recovery key, but as of yet I haven't found any asymmetric encryption of PII. It does look like they are using the recovery key as a second password, and running it through scrypt to verify it, but I haven't traced past that point yet, and Ruby is not my first, second, or 3rd language. From what I can tell, they do the same key derivation process as with the primary password, but then also encrypt the secondary 'cek' with another key -- perhaps just HSM(R) -- so they can get back 'cek' without needing the token. But I'm not sure I'm reading it right because there are variables called things like 'encryption_key', 'encrypted_code', 'encryption_code', 'encrypted_key', 'encrypted_password', 'personal_code', 'raw_personal_code', 'code', 'hashed_code', ahhhh..... If there's one good thing to say about all this, the fact it's open source and I can even look at it all, and open issues on GitHub against the US Government's code for authenticating citizens... well just that is pretty awesome.

by pfg 9y ago

zaroth 9y ago

This would indeed work! I'm still studying their code for handling the recovery key, but as of yet I haven't found any asymmetric encryption of PII. It does look like they are using the recovery key as a second password, and running it through scrypt to verify it, but I haven't traced past that point yet, and Ruby is not my first, second, or 3rd language. From what I can tell, they do the same key derivation process as with the primary password, but then also encrypt the secondary 'cek' with another key -- perhaps just HSM(R) -- so they can get back 'cek' without needing the token. But I'm not sure I'm reading it right because there are variables called things like 'encryption_key', 'encrypted_code', 'encryption_code', 'encrypted_key', 'encrypted_password', 'personal_code', 'raw_personal_code', 'code', 'hashed_code', ahhhh..... If there's one good thing to say about all this, the fact it's open source and I can even look at it all, and open issues on GitHub against the US Government's code for authenticating citizens... well just that is pretty awesome.