> I ask that with an especial emphasis on the zero knowledge password system which is currently undocumented but, if I'm understanding correctly, also unimplemented?
That one’s easy, it’s just (likely augmented) PAKE. There are a couple options in this space. The zero-knowledge stuff likely comes from the blind salt (OPRF, Oblivious Pseudo-Random Function). There are different variants to chose from, with slightly different security & performance trade-offs. This stuff indeed allows password authentication without ever revealing the password to the server, but the password database itself is still vulnerable to dictionary attacks once it’s stolen.
What worries me though is how they failed to mention PAKE. I’ve seen much of their talk, and to be honest it smelled like snake oil. Very shallow explanation of the protocol, and many missing steps between that and an actual use case. It’s supposed so solve many Big™ problems, but how it achieves it is very unclear to me.
Indeed, although undocumented, this is implemented and is a PAKE variant ([1] and [2]).
The way that it works, at a high level, is similar to how SRP works. Two random salts are generated (let's say, A and B), where A is used for authentication (and hence public) and B is used for deriving the other cryptographic keys.
When you authenticate, you retrieve A and then you prove to the server that you know what scrypt(A, password) is. At this point, the server provides you with B, and you can use this information to derive scrypt(B, password), which in turn you use to derive other cryptographic keys.
It being an oblivious password store, there are other steps taken to make the protocol stateless (from the perspective of the server) and to make parties commit to random values used so that runs of the protocol cannot be replayed.
> but the password database itself is still vulnerable to dictionary attacks once it’s stolen
This is correct, and I'm not sure there are good ways to prevent this or equivalent scenarios from occurring. Therefore, you should see this as an additional layer on top of your already secure password and not as a substitute for a secure password.
The reason for having this mechanism rather than not having it is to protect your password from brute-forcing by the public at large, in a scenario where the server operator is semi-trusted. Without this implementation, you have three alternatives: (1) Forego passwords entirely; (2) make the salted password 'public', along with the salt, which is all the information you need to brute-force it or (3) make more "normal" authentication flows without PAKE, in which case you need to trust the server even more. If you insist on using passwords, this is a compromise solution between (2) and (3), i.e., between anyone can break it and trust the server entirely.
> This is correct, and I'm not sure there are good ways to prevent this or equivalent scenarios from occurring.
I believe there isn’t indeed, sorry this part came out as a criticism.
I actually have deployed a PAKE at work for a corporate CRUD app once, and the entire security hinged on login/password. Clients authenticate to the server with the password, server authenticates to the clients with its database entry.
Sure the password could be brute forced if the databased leaked, and sure anyone could impersonate the server with a database entry, but this reduced security allowed simpler and more convenient administration: no need to bother with a PKI, just take good care of the password database and reset everyone’s passwords when we suspect a leak.
(Now if this was for the wider internet I would have added a PKI layer on top to prevent server impersonation.)
> The reason for having this mechanism […]
Yeah, PAKE is real nice. Ideally every password based login system would use augmented PAKE under the hood. Not only does it protect the passwords better, the protocol itself doesn’t need to happen in a secure channel (this can help reduce round trips), and the bulk of the computation (slow password hashing) happens on the client side. This reduces both network load and server load, what’s not to like?
That one’s easy, it’s just (likely augmented) PAKE. There are a couple options in this space. The zero-knowledge stuff likely comes from the blind salt (OPRF, Oblivious Pseudo-Random Function). There are different variants to chose from, with slightly different security & performance trade-offs. This stuff indeed allows password authentication without ever revealing the password to the server, but the password database itself is still vulnerable to dictionary attacks once it’s stolen.
What worries me though is how they failed to mention PAKE. I’ve seen much of their talk, and to be honest it smelled like snake oil. Very shallow explanation of the protocol, and many missing steps between that and an actual use case. It’s supposed so solve many Big™ problems, but how it achieves it is very unclear to me.