ColdFusion Summit Notes: Please Pass the Salt: Serve Up Passwords With a Side of Entropy, Brad Wood

October 08, 2019

Hackers may not even care about your business
But they saw a security flaw on your site and exploited it because they can

Need multiple layers of security

What if they get access to your db? your source code? both?

It’s yr job to mitigate the fallout if things are compromised

80% of users reuse the same password across multiple accounts

Cypher - output of an encryption algorithm
Digest - output of a hash algorithm
Encryption - a reversible mechanism to secure info
Hash - a NON reversible mechanism where output is determined by input
Symmetric key encryption - the same secret key is used to encrypt and decrypt
Asymmetric key encryption - pubic and private keys (how ssh and ssl works)
Salt - extra data added to input to increase the randomness
Rainbow tables - form of lookup table used to brute force hashed passwords
Plain text - the worst way in the world to store your passwords!

Plain text = bad
More common than you’d think
Makes hackers lives SO much easier!
Any sort of highly sensitive info should be a candidate for encryption
passwords, ssn’s, etc

Prevent against SQL injection

Lock down DB user to not see schema
Hackers used Yahoo data to break into unrelated accounts of the same users
System allowed users to use very weak passwords
Don’t store passwords in plain text

Symmetric Encryption

  • Reversible process
  • Uses secret key for both encryption / decryption
  • Only suitable for info that you NEED back in plain text
  • You don’t ever NEED a password in plain text

Your legacy systems are still a liability until they go offline
System allowed users to use very weak passwords
Password hints are abused and often just give password away. Instead use secure password reset process
Reversible encryption used, but luckily symmetric key was not stolen
Lack of salt made it possible for lookup tables to be applied to all users since ciphers were identical
Hackers used Adobe data to break into unrelated accounts of the same users
Don’t use unsalted reversible encryption!

Hashing

  • Irreversible (plain text can’t be retrieved from the digest)
  • Deterministic - same input always provides same digest
  • No 2 inputs produce the same digest
  • Loses original info, but is repeatable for later verification
  • If user forgets password, you can’t look it up for them!

Lack of salt means all the same passwords have the same hash digest
MD5 is a very fast algorithm that makes it faster to brute force
MD5 is considered “broken” due to found hash collisions
Extensive lookup tables already exist for MD5 hashes
Large numbers of passwords were likely converted to plain text

You want your algorithm to be slow on purpose, to slow down brute force attacks on collections of passwords

Dictionary Attack

Most passwords aren’t random, but based on dictionary words
Focus on common words or phrases can eliminate billions of unlikely passwords

Entropy

  • The measurement of how unpredictable a password is
  • Measured in “bits” representing all the Log(2) of the possible variations that could be presented
  • All possible passwords are calculated as: “character set” to the “length” power
  • A password with a length of 5 using only lowercase has 26^5 or 11.8 million possible combos and therefor is about 23.5 bits of entropy
  • You can add entropy by increasing the length OR adding more unique characters
  • Unless forced otherwise, users will typically use alphanumeric chars only
  • A few million “guesses” is nothing of it’s automated
  • Common password requirement is min 8 chars, w/ upper, lower, numbers, and a special char

56 alphabetic chars
10 numeric digits
~15 punctuation chars
total 81^8 or 1.8 quadrillion passwords
50.7 bits of entropy
At 1 billion guesses/sec, would take 21 days to generated all possible combinations of 8-character passwords
Longer passwords have more entropy than complex ones w/ fewer characters

Rainbow Tables

  • Readily available on the internet
  • A form of lookup table that maps pre-computed hashes back to the plain text input
  • Contain optimized lookups to brute force billions and billions of hashes to plain text
  • Are pre-computed and current hardware limitations on the number of combinations
  • Pre-made tables ineffective against salted passwords
  • If all your passwords use the same salt, a rainbow table can be generated custom for your app

Salting

  • Additional data you add to the original text to add to the entropy / randomness
  • Salts push the length of the hashed string well past the threshold of chars in a pre-computed rainbow table
  • Salts should be different for every user so a new rainbow table would be req’d for each digest
  • Salts are generally stored alongside the digest
  • Salts should be changed (rotated) any time the password changes
  • Salt is recommended to be at least the length of the digest
  • A 30 character salt turns an 8 char password into a 38 char password from a brute force perspective
  • “Salted Password Hashing - Doing it Right”

Key Stretching

  • Slows down how many hashes can be performed every second
  • This makes brute force so slow it’s not feasible
  • Purposefully choose slow algorithms
  • Algorithms like BCrypt allow you to dial in a custom work factor for current CPUs
  • Can include iterations

It’s recommended to take at least 1/2 a second for a single hash. Fast enough for a user not to notice, but slow enough to completely slow down a brute force.
1 quadrillion passwords at .5 seconds each is a LONG time!

Best Practices

  • No plain text passwords!
  • Hash, don’t encrypt
  • Always salt
  • Use a different highly random salt per user w/ a length at least as large as the digest
  • Use a lib like BCrypt that incorporate a “work factor” so your hashes are not quick!
  • If you do use any symmetric key encryption, store the key outside of the codebase
  • Run DB users w/ limited permissions to cut down on SQL injection attacks, 1 of the primary ways DB’S get exposed
  • Don’t use “sa” perms on your database connection
  • If someone DOES find a way to talk to the database, there should be a very limited set of things they can do/access
  • Retrofit legacy systems, they are part of your attack surface area

As long as legacy systems are on line, they are a liability

“A crypto-system should be secure even if everything about the system, except the key, is public knowledge”
- Auguste Kerckhoffs

“Security by obscurity” is not security
People knowing HOW you encrypt the passwords, should not make it less secure

Extra tools

2FA - 2 factor authentication
DumbPassword module on forgebox.io - verify the user provided password is not 1 of the top 10,000 worse passwords
Haveibeenpwned.com - look up your email addy and see if it’s been exposed in a hack
Lastpass.com - browser plugin to generate secure passwords and store them for each site
Passwordmeter.com - implement similar on your site to help users generate secure passwords

Brad on Twitter - @bdw429s
www.codersrevotion.com
pi.bradwood.com