Salting, Hashing, and PBKDF2
Passwords are very private information, and you don’t want to be responsible for a data breach. You should take the highest precautions if you have to handle them in your application, and hash them properly.
Most of the security problems with passwords occur after an attacker has gained access to your server, and is able to view the database where you store passwords. While it’s definitely a good idea to lock down your server to prevent unauthorized access in the first place, you should still implement damage control for the worst case scenario…
Instead, use PBKDF2. It’s meant specifically for passwords, meaning it’s relatively slow to calculate for the average length password. It takes much longer to bruteforce, and it’s practically impossible to crack longer passwords stored with it. You can use the JavaScript implementation, or use a server side implementation.
While SHA256 is a secure hash, it’s also designed to be a general-purpose hash. This means it has to be fast, because it’s also used for creating checksums (which must process gigabytes of data). Speed directly decreases bruteforcing time, and even with salted passwords, it’s still relatively easy to crack individual short strings. Salts only protect against rainbow tables.
To make full use of PBKDF2, you’ll want to implement some sort of password standard for your site. You don’t need to require everyone to have dollar signs and numbers in there; length matters much more than anything else. Try to enforce 8-12 character passwords at a minimum…”
