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.
