That’s complicated to do correctly. Normally, for the server to verify the user has the correct password, it needs to know or receive the password, at which point it could decrypt all the user’s files. They’d need to implement something like SRP.
That’s complicated to do correctly. Normally, for the server to verify the user has the correct password, it needs to know or receive the password, at which point it could decrypt all the user’s files. They’d need to implement something like SRP.
What I proposed is that the server does not know the password (of course), but that it knows a thing derived from it (lets call it the loginSecret) which the client can send to obtain the encryptedMasterKey. This can be derived in a similar fashion to the keyEncryptionKey (eg, they could be different outputs of an HKDF). The downside to the server knowing something derived from the passphrase is that it enables the server to do an offline brute force of it, but in any system like this where the server is storing something encrypted using [something derived from] the passphrase the server already has that ability.
Is there any downside to what I suggested, vs the current design?
And is there some reason I’m missing which would justify adding the complexity of SRP, vs what I proposed above?
The only reason I can think of would be to protect against a scenario where an attacker has somehow obtained the user’s loginSecret from the server but has not obtained their encryptedMasterKey: in that case they could use it to request the encryptedMasterKey, and then could make offline guesses at the passphrase using that. But, they could also just use the loginSecret for their offline brute-force. And, using SRP, the server still must also store something the user has derived from the password (which is equivalent to the loginSecret in my simpler scheme) and obtaining that thing still gives the adversary an offline brute-force opportunity. So, I don’t think SRP provides any benefit here.
Update: I contacted the developers to bring my comment to their attention and it turns out they have already implemented SRP to address this problem (but they haven’t updated their architecture document about it yet).
That’s complicated to do correctly. Normally, for the server to verify the user has the correct password, it needs to know or receive the password, at which point it could decrypt all the user’s files. They’d need to implement something like SRP.
What I proposed is that the server does not know the password (of course), but that it knows a thing derived from it (lets call it the
loginSecret) which the client can send to obtain theencryptedMasterKey. This can be derived in a similar fashion to thekeyEncryptionKey(eg, they could be different outputs of an HKDF). The downside to the server knowing something derived from the passphrase is that it enables the server to do an offline brute force of it, but in any system like this where the server is storing something encrypted using [something derived from] the passphrase the server already has that ability.Is there any downside to what I suggested, vs the current design?
And is there some reason I’m missing which would justify adding the complexity of SRP, vs what I proposed above?
The only reason I can think of would be to protect against a scenario where an attacker has somehow obtained the user’s
loginSecretfrom the server but has not obtained theirencryptedMasterKey: in that case they could use it to request theencryptedMasterKey, and then could make offline guesses at the passphrase using that. But, they could also just use theloginSecretfor their offline brute-force. And, using SRP, the server still must also store something the user has derived from the password (which is equivalent to theloginSecretin my simpler scheme) and obtaining that thing still gives the adversary an offline brute-force opportunity. So, I don’t think SRP provides any benefit here.That sounds kind of like CWE-836.
It is, but in this case I think it isn’t actually a weakness for the reasons I explained.
Update: I contacted the developers to bring my comment to their attention and it turns out they have already implemented SRP to address this problem (but they haven’t updated their architecture document about it yet).