What are the standard password authentication protocols in client-server setting where authentication happens at the remote server? Is there any password/pin verification protocol which reveals zero knowledge (or a limited amount of knowledge which can keep on changing in subsequent rounds of login) about client's input password, but the server can still authenticate the client? Also, the server should not store enough data about the client's password to lead to any potential insider attack.

To my understanding, storing password in plain text on the server doesn't help. Storing the salted hash doesn't help if the salt is also stored on the server, the comparison can be bypassed in a privileged attack. Also, storing data on the client side is not ideal in case of a lost device/data on the client's side, which will force us to be completely dependent on identification protocols which, to my understanding, is the same as password verification (except for identification protocols which use trusted third parties, but that's not an ideal choice).

  • What are your limits to protect against "any potential insider attack"? Presumably an insider can change any server-side code normally protecting passwords to store a plaintext copy that they can access. Or if you push hashing to the client they can change client code sent by the server to do the same. Is this insider just someone with database read access and no privileged access to code or server operations?
    – PwdRsch
    Apr 14 '19 at 19:31

A common misconception about salts is that they are a secret. If implemented correctly, it's not very important for the salt to be secret. The point of a salt is to defeat precomputation attacks like rainbow tables, and to make the required time and computational cost of cracking a password as high as possible.

This is an effective mitigation against a malicious privileged insider. If you can make the average time required to break a single password longer than the age of the universe, that will be enough to prevent your insider from cracking a password unless they are astronomically (literally) lucky.

So if your aim is to prevent a malicious privileged insider from accessing any users password, storing a strong salt with the password hash, along with choosing a strong hash, is enough.

  • So a user chose "12345678" as their password. What strength of hashing protects that from being cracked? Normal password choices aren't distributed via luck, but by fairly predictable patterns.
    – PwdRsch
    Apr 14 '19 at 19:28
  • The problem of weak user passwords is orthogonal to the problem of secure password storage, and is solved by other means. If you allow a user's password to be that weak, an attacker has absolutely no need to crack any hashes anyway.
    – Johnny
    Apr 14 '19 at 20:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.