Another big source of hacks is just trying known email/password pairs at a bunch of different sites. Some company, website, message board, etc. gets hacked, and that place stores passwords in either plain text or as a non-secure hash. Now the hackers have a list of emails and passwords to try at lots of other sites.
It is exactly that kind of hack which password managers can completely shutdown. If no two of your accounts share a password, then a hack at one site only matters at that site. Complex passwords are good, but complexity is not a defense when the attacker already has the clear text password.
I really hope that nobody actually stores passwords in plain text nowadays. I think a bigger risk is “monoculture”, like with farming. Everyone uses an off-the-shelf program library to encrypt and decrypt passwords. Then, if the perp can download the encrypted password database, they can exploit the knowledge of how the data encryption algorithm works, or worst case, create a rainbow table or exploit a flaw in the process. This is essentially the procedure used on Windows and LINUX cracking today.
OTOH, most people who come up with their own password management from scratch, usually are not expert enough to create a secure system. (Recall an analysis of a security process for some parental control software - the reviewer pointed out the program did a simple scramble and math on the password and hoped nobody would figure it out. Any competent hacker could.)
About four or five years ago, I decided to order something from an online store I had used 10 years prior. I didn’t remember my password, so I clicked on the “Forgot Password” link. I was promptly sent an e-mail, with my password in plain text. I decided that meant that I couldn’t trust that company with my credit card information either. (Happily it was a password I wasn’t using anywhere else, so their carelessness shouldn’t impact me when they eventually have a leak.)
Depends. Some items I read say store the salt hash along with the salt+password hash. (Random different salt for each user) Guess then, the question is - what’s the complexity of cracking the salt alone? Make it random and long, and odds are it’s pretty much uncrackable. However, if the code for creating the salt is available and can be decoded, then perhaps -depending on length - the salt can be cracked.
Again, if the site uses a standard available program library that has been vetted, good. If the coder makes up their own process, then they leave themselves open to someone discovering flaws in their logic. The problem with monoculture comes if the coder used an off-the-shelf library that turns out to have flaws. I vaguely recall reading of one popularly-used program that had a computing flaw where an intermediate step led to a result of only 64K possible encryptions. Thus any input that led to the same encrypted output would work as a valid password.
You can’t hash the salt. You can maybe encrypt it, but the usual use case for salt is to just put it in plain text. Which still works for defeating rainbow tables.
Let’s say, for instance, that your salt is something fairly small, like four hexidecimal digits. That’s still 65,536 different possible values, which means that a rainbow table would need to be 65,536 times longer in order to cover all of the salt possibilities. That’s usually going to be enough to take the rainbow table from practical to nearly impossible. And if it’s still not enough, just use a longer salt.
One can only hope, unfortunately it happens. A quick search shows that both Facebook and GoDaddy had plain text password breaches in the last few years.
I think there are a few things being confused here. Encryption is a scrambling of information in a reversible manner. Good encryption requires a key of some sorts to unscramble the encrypted information.
Hashing is a one way transformation. The original data cannot be recovered from just the hash. Passwords are usually hashed. That is why the typical method to decode a list of hashed passwords is to hash a list of possible passwords, and compare the hash values.
For example, I can create a descrypt hash of “Correct Horse Battery Staple” and get pPSXGZACDXMUk. The first two characters pP are a salt. They have been randomly generated and added to the des hash of “Correct Horse Battery Staple”. (Except that descrypt is long broken and out of date) nobody can look at pPSXGZACDXMUk and know the password is “Correct Horse Battery Staple”.
Keeping secret the actual encryption algorithm being used is a very small bit of defense over having the algorithm be secure in the first place.
In all cases, using a tested, vetted, and open method of encrypting or hashing is going to be more secure than using a secret, un-vetted method. That’s different than the attacker simply not knowing what the method is. Here are two encrypted strings (the title of this thread, and one guess at the password) U2FsdGVkX19bc72X5QBtKIFrtClEDhj2SCN15YrnKY+A4+/wNLj6gl5mz99oe5L7 xy28Ub7oooy9Ho691qrr3Q== U2FsdGVkX19QvDFMmcb9HettWJBY1gcLkhRgptrhqHVxct/sLHKb/0TUuJFSAUaY Iqe6xdNCC3AUg6sm9KY3+w==
They look about the same, but one is encrypted with AES-256 and the other with DES-EDE. The one encrypted with DES is not safe, and can probably be brute forced. I’d much, much rather have the attacker know my text was encrypted with AES-256, than have my text secretly encrypted with DES-EDE.
(All of this is a very brief explanation, that is probably simplified to the point of being wrong on important details.)
Strictly speaking, this is true, because in the world of all strings, there will be many, many input strings that all produce the same output hash, and so it’s not possible, in principle, to know which of those input strings it actually was. That said, if one of the possible input strings was “Correct Horse Battery Staple”, and another possible input string that produced the same hash was “A7kjf&JA0k#*”, then it’s much, much more likely that “Correct Horse Battery Staple” was the actual password. This is relevant because of peoples’ tendency to re-use passwords: Even if all sites used the same (good) hashing algorithm, they’ll probably use different salts, so while either “Correct Horse Battery Staple” or “A7kjf&JA0k#*” will get you into the first site, only one of them will get you into other sites as well.
All that said, for a good hashing routine, there’s no practical way of starting with a hash, and generating a list of all of the possible inputs that would produce that hash. The only way to find inputs that would produce a given hash is to have good guesses of what the inputs might be to begin with, and hash all of them.