Follow

Best practices for lost password logic (security issues)

As far as best practices go, rule #1 of password security is that even you (our client) should NOT know the passwords of your users!

We always refer our clients to this document : http://crackstation.net/hashing-security.htm

When you accept a new password from a new user, the password should be “salted” then “hashed” and then that hashed password is what should go in your database. Then your login form repeats the process, and compares the 2 hashes, and accepts the login if they match.

If you do it that way, you won’t know the passwords, making it impossible for all password of your users to leak onto the net if you get their database hacked or anything like that. This is a prime security rule, and will “save your a..” if anyone ever exploits a PHP flaw etc. to steal your database of users.

 

Now, let's say you still store the actual passwords in your database, rule #1 of password security (yes!, that’s 2 x rule #1, they’re both just as critical!) : *NEVER* send  password in an email. Your worry here is the simple fact that email is insecure, mostly sent out unencrypted over the web, stored on usually easy-to-hack webmails, visible to often hundreds of staff members at ISPs, and so on. The worry shouldn’t be “the company you have a contract with and an agreement they won’t use your data”, it’s “everybody else you don’t know about that will have complete access to it if you send it by email”.

Even a password recovery link is potentially stealable that way, so care should be taken to:

  • Let the link work only once
  • Let it work only from the original IP address that asked for the password reset
  • Let it work for only a limited amount of time (if someone initiates a password recovery and takes more than ~1 hour to complete it, force them to start over)

All that is not guaranteed protection but it’s a good start!.

0 Comments

Please sign in to leave a comment.