Hacker News Reader

Comment by lovetocode | Hacker News Reader

Your response scares me. Are you sure you are in the right business?

Seriously, why on earth would you even recommend storing a password in plaintext anywhere?

I didn't down vote you, but in any case, that's not what I said. I should have been clearer, my bad.

I said we'd store the user's key in local storage referring to the user's randomly generated key our client uses to encrypt data before sending to the server.

Passwords are never stored in plaintext anywhere. We don't even send passwords to the server in plaintext -- we hash passwords client-side.

But yes, even storing the key in plaintext in local storage has undesirable properties, which is why it's opt in. But an app that encrypts data with a key stored in local storage has a significantly higher level of privacy than an app that sends all data in plaintext to the server for storage.

> we hash passwords client-side

Is that instead of or in addition to any hashing done on the server? It seems like doing all hashing on the client side essentially means that you would be storing plaintext passwords, since the value sent to you by the client would end up in a DB without modification. Curious as to why you went with client-side hashing as opposed to something like SRP.

Short answer: because the password is used to encrypt the user's randomly generated seed, then the resulting ciphertext is stored on the server. If we didn't hash client-side and sent passwords in plaintext to the server, our end-to-end encryption scheme using password-based encryption would be broken (though I know that’s not exactly what you were saying)

Long answer: Based off my understanding, we do implement something analogous to SRP with some minor differences.

We'll have supporting documents explaining our approach complete with diagrams soon. But for right now, this is close to what the architecture looks like for clarity:

https://user-images.githubusercontent.com/26468430/69532862-...

In order to be fully authenticated, the client must first prove they know the password token. The server then sends the client the password encrypted seed, then the client proves they can decrypt that seed (using Diffie-Hellman). So functionally the client is proving it knows both derivatives of the password to the server.

Note there are 2 major differences between that image and what's currently in the code:

1. We also do a single SHA-256 hash of the password token before storing it on the server (prevents someone with access to only the server's data from passing round 1 of our authentication flow)

2. The optionals are not optional anymore, what I described above is how it’s working today.

Disclaimer: there are a lot of missing pieces in the above description. So if it feels like there are gaps, that's why. It's difficult to explain the full scheme in a single comment like this.

Our approach is pretty similar to Firefox's described here: https://hacks.mozilla.org/2018/11/firefox-sync-privacy/