Password Storage

[Chris Wright via Digitalmars-d-learn]

On Fri, 27 Nov 2015 08:09:49 -0800, H. S. Teoh via Digitalmars-d-learn
wrote:

> On Fri, Nov 27, 2015 at 02:51:30PM +0000, Adam D. Ruppe via
> Digitalmars-d-learn wrote:
>> On Friday, 27 November 2015 at 07:46:33 UTC, H. S. Teoh wrote:
>> >1) The server stores password01 in the user database.
>> 
>> I still wouldn't actually store this, hash it anyway and use that as
>> the new "password".
> 
> True, so you'd store hash(password01) in the database, and compute
> hash(X + hash(password)) during authentication.
> 
> 
> T

Alternatively, you could do what's industry standard for non-sensitive 
sites:

* Always use TLS.
* Send passwords to the server. Memory regurgitation attacks can reveal 
these passwords, which allows attackers to reuse those credentials on 
other sites to impersonate people.
* Store salted hashes of passwords rather than the passwords themselves.
* Hope that your certificate authority is secure. Actually, hope that 
*every* certificate authority is secure. Otherwise, MITM attack.

Or you can take a slightly more paranoid approach:
* Use certificate pinning to prevent MITM attacks.
* The client sends a salted hash of their password. You store a salted 
hash of that. This saves users from their password reuse habits if 
someone finds an arbitrary code execution flaw or memory regurgitation 
attack in your server.

This approach is at least marginally more secure than yours (if your 
server randomly generates the same nonce twice for the same person, I can 
use a replay attack, for instance) and is better vetted.

Security is hard.