Another option: http://forum.dlang.org/post/lts93o$2fr0$1@digitalmars.com

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".

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

-- 
It is of the new things that men tire --- of fashions and proposals and improvements and change. It is the old things that startle and intoxicate. It is the old things that are young. -- G.K. Chesterton

On Friday, 27 November 2015 at 16:14:06 UTC, H. S. Teoh wrote:
> True, so you'd store hash(password01) in the database, and compute
> hash(X + hash(password)) during authentication.
>
>
> T

Another option is SCRAM: https://en.wikipedia.org/wiki/Salted_Challenge_Response_Authentication_Mechanism

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.

On Friday, 27 November 2015 at 00:17:34 UTC, brian wrote:
> 3) pre- or post-pend the salt to the password entered (apparently there is a difference??)
Sorry to revive an old thread, but I wrote a blog post about this question:
https://theartofmachinery.com/2016/01/03/What%20Difference%20Can%20Order%20Make%20When%20Hashing.html