“123456” and “password” as crack standards

I know that when we encrypt, we use standard encryption technologies and to store data it's often stored as a hash.

By encrypting a common password, for example

"password"

using MadeUpHashingTechnology it will always equate to

"awregk;4"

this becomes a standard to use in identifying my hash. Now crackers can look at MadeUpHashingTechnology-Dictionary.com for the most common hashes and see my data more easily.

If I identified n-common or low-strength passwords and simply left them unencrypted (or used a distinctly different encryption) would that help in reducing dictionary attacks? (I'm assuming my password database has been compromised in this scenario)

Would the database need to be compromised for a dictionary attack to be useful?

• en.wikipedia.org/wiki/Salt_%28cryptography%29 – Richie Frame Jul 1 '15 at 6:57
• Yes, but when if comes to large scale breaches, often there are raw hashes clearly visible. Along with password hints! – Patrick Pease Jul 1 '15 at 7:11
• It is not so clear to me what exactly you are asking. Are you asking if storing non-hashed passwords in your database can somehow increase security for low-strength passwords? – Guut Boy Jul 1 '15 at 7:29
• so you are basically asking if security by obscurity is a good idea? – Richie Frame Jul 1 '15 at 8:02
• hashing =/= encryption – user11153 Jul 1 '15 at 11:03

5 Answers

Using several different encryption algorithms, and not disclosing which is used in each particular case would require password verification to try all possible algorithms. Feasible only when using just a few algorithms. Truecrypt does this, for example.

This could strengthen security, when implemented properly - but it is much more difficult to implement.

Proper solution - salt.

• Do not use MadeUpHashingTechnology without salt.
• Do not use MadeUpHashingTechnology ever, use public, verified crypto.
• +1 for Do not use MadeUpHashingTechnology ever, use public, verified crypto. – BlueCacti Jul 1 '15 at 14:24
• As edits have to be >6 chars, I cannot fix the typo's and line breaks in here. – BlueCacti Jul 1 '15 at 14:27
• @GroundZero does that cover it? – trichoplax Jul 1 '15 at 14:54
• TrueCrypt may not be the best resource to cite, since its sourceforge page very boldly states that it's broken... Also, the current best practice is to use BCrypt, an algorithm to salt and stretch the password based on Blowfish. ( en.wikipedia.org/wiki/Bcrypt ) Finally, it should be noted that the salt should be selected from an unpredictable source, not cryptographically random (though that's certainly more than good enough), but at least globally unique within an application to prevent rainbow tables from being useful for at least a subset of passwords. – Ghedipunk Jul 1 '15 at 20:26
• @Ghedipunk : $\:$ Well, either Bcrypt or Scrypt. $\;\;\;\;$ – user991 Jul 2 '15 at 6:33

The best practice for protecting passwords is to first concatenate (public) random salt and then iteratively hash. This prevents constructing a static dictionary like you mention, and also prevents Hellman time-space tradeoffs (and extensions like Rainbow tables).

This approach would constitute security through obscurity, which is not recommended to be relied upon.

Enhancing security by design would be advisable. In this particular case a stricter password policy that requires stronger passwords and possibly making users change password regularly.

Multi-factor authentication would typically enhance security even further, but is not easily achievable in many scenarios.

The easiest passwords to guess will always be vulnerable to guessing attacks.

If you're intending to identify easy passwords, you should tell your user not to use those passwords.

Regarding your comment "Would the database need to be compromised for a dictionary attack to be useful?"

The answer is no.

A dictionary attack would require a username/email (which might either be known or could come from a small dictionary) and then trying words from the dictionary. This is attempting to get in via your normal logic prompt logic. A simple way to defeat a dictionary attack is to introduce an account lockout after a few failed attempts or simply to introduce a delay before replying with a failed login message - the idea being to introduce a sufficient delay to make it unfeasible to try all/many dictionary (and brute force combinations). One caveat about the account lockout, is remember that it it might be the username which is under attack not the password, so an attacker might have a dictionary of email addresses or usernames and be trying a couple of common passwords against each one.

Hashing and salt come in after your password file/database has been compromised. (But that isn't a reason for not doing it - you should, but you know that.)