Password encryption, how to protect your users.

“Please reset your password”… the email subject line that makes me cringe.  This morning I received this email from, few months ago from T-MobileHome Depot, Anthem, Staples, Kmart, you get the idea.

Screen Shot 2015-12-24 at 2.12.05 PM

When you’re a large company with thousands of employees (or just hundreds) that have access to your intranet, those employees themselves become the risk to your data.  Now assuming most of these giants have high standards of security (hopefully) e.g. audit logs, complex passwords or keys, controlled environment, etc; you’d think there’s no potential leak anywhere, but it still takes one employee to screw up the process.

With that potential risk, we should assume that our data can be compromised at some point (you must play devil’s advocate).   Some actions we can take:

  • Encrypt data at rest (Huge fan of MongoDB taking advantage of this; EC2 too!)
  • Utilize 2048 bit keys to access system servers with a complex passphrase.
  • Encrypt passwords with SHA2 with complex salt.
  • Encrypt user sessions, similarly to OAuth.  Sessions should be newly generated SHA2 tokens, with a salted+encrypted key in the DB.


How-to store passwords correctly

First off we assume your site is already utilizing HTTPS / SSL, this should be a standard.  Generate a variable with a 12-15 random bytes.  Take the plain-text password (should be also something complex / as a standard) and process it with SHA2 encryption along with the salt.  This newly generated value will be stored to the DB along with the salt.  Good luck to whomever gets this data and tries to decrypt it.  It would take a super computer to decrypt EACH individual user’s password.


Comments are closed.