Just a couple of points on the above, because it confuses hashing and encryption, which are entirely different concepts:
- Hashing is one way. It produces a different output for (hopefully) every different input. There is no way to “decrypt” a hash. It isn’t just difficult or time consuming to do so, it inherently impossible.
- Encryption is two way. You can decrypt an encrypted message to get the original back.
- Obviously, while hashing is one way, and cannot be reversed mathematically, you can guess, brute force, or look up hashes to get the original back.
This leads to the following conclusions:
- When storing passwords hash them (don’t encrypt: you never want to be able to get the original back).
- In order to “reverse” a hash you have the following options (assuming there is no vulnerability in your hashing algorithm):
- Brute force it. This means you try every possible password combination, until you have reached the one that produces the same hash. That (and only that) is where those “x quadrillion years” estimates come from. Password hashing algorithms are specifically designed to be slow (which, incidentally is part of the reason why you shouldn’t use SHA512 for passwords)
- Look up tables that list hashes of known strings for the hashing algorithm. Much faster, and more efficient.
Nowadays, password cracking isn’t usually done using pure brute force, randomly trying all possible passwords. Rather it’s done using massive “dictionaries” of commonly used password as well as English words (or whatever the target language of the site is), as this massively speeds things up. As an example: If you have an entirely random 10 character password such as “8LDJLGQB2O” it may take while to crack it (if hashed properly, i.e. NOT sha512). If, however, your 10 character password is a dictionary word with simple substituitons (e.g. “4PPL3J4CKS”) it may SEEM to take just as long, but because it’s a dictionary word it will be one that any password cracker will try early on, and it will thus be cracked much quicker, despite being seemingly of the same strength.
Thus, your “Longer passwords are more secure” is not universally true. “Longer, entirely random and unique passwords are more secure”.
However, and that’s the crux of the argument, you cannot force people to use entirely random and unique passwords. You can make rules such as “your password must contain at least 2 letters and 2 numbers, and be 10 characters or more”, but that forces neither uniqueness nor randomness. Most people will just use minor variations of their favourite passwords to just about fit the rules. A longer password that is not entirely random, or that has been used (and cracked) before is often LESS secure than a shorter, entirely random and unique password (obviously within limits).
Thus, when creating passwords you should (in order of descending importance)
- Use a unique password each and every time. NEVER reuse passwords
- Generate random passwords, choosing from as large a character set as is available to you.
- Make them reasonably long