How does password hashing and salting make an application secure?

Question

As I understand it, it is a good idea to keep passwords secret from the site administrator himself, because he can try to get the user's email and enter his mailbox using the same password (since many users use the same password everywhere).

Other than that, I don't see the point. I know this makes it difficult to attack the dictionary, but ... if someone is unauthorized to enter the database, is it not too late to worry about passwords? The guy now has access to all the tables in the database and can take all the data and do whatever he wants.

Or am I missing something?

Answer 1

The big problem is that people tend to use the same password all over the world . Therefore, if you get a database with usernames and unsalted passwords, there is a chance that they can work elsewhere, such as hotmail, gmail, etc.

Answer 2

The guy may be able to do whatever your system wants, but you should not let him / her do anything with other systems (using user passwords)).

Password is the property of your users. You must keep it safe.

Answer 3

Many of your users use the same credentials (usernames / passwords) on your site as they do in their bank. If someone can get a credential table, they can get instant access to a bunch of bank accounts. Failure.

Unless you actually store passwords, attackers cannot steal their users' bank accounts simply by grabbing a credential table.

Answer 4

It relies on the fact that a hash is a one-way function. In other words, it is very easy to convert the password to a hash, but it is very difficult to do the opposite.

Therefore, when the user registers, you convert your chosen password into a hash and save it. At a later time, they use their password and convert the password to their hash and compare it, because to a high level of probability, if (passwordhashA == passwordhashB), then passwordA = passwordB.

Salting is a solution to a related problem. If you know that someones passwordhash is, say, ABCDEF, then you can try to calculate hashes for all possible passwords. Sooner or later, you can find this hash ("dog") = ABCDEF so you know your password. It takes a lot of time, but the process can be accelerated using pre-created "dictionaries", where for this hash you can find the corresponding password. Salting, however, means that the text that hashed is not a simple English word or a simple combination of words. For example, the case I gave above, the text to be hashed is not a “dog”, but a “somecrazymadeuptextdog”. This means that any easily accessible dictionary is useless, since the probability that it contains a hash for this text is much less than the probability that it contains a hash for a "dog". This probability becomes even lower if the salt is a random alphanumeric string.

Answer 5

This article details the positive aspects of hashing and using your passwords:

http://www.developerfusion.com/article/4679/you-want-salt-with-that/

Answer 6

The site administrator may not be the only one who gets access to your password. There is always the possibility of dumping the entire database, which falls into the total share by chance. In this case, anyone with access to the Internet can download it and read the password, which was so conveniently stored in the clear.

Yes it did. With credit card details too.

Yes, it is very likely that this will happen again.

Answer 7

"if someone is unauthorized to enter the database, isn't it too late to worry about passwords?"

You assume a poor database design in which authorization data is collected with application data.

The principle of "separation of problems" and the principle of "Least Access" suggest that user credentials should be stored separately from everything else.

For example, save user credentials on an LDAP server.

Also, your question suggests that database credentials are the only credentials. Again, the principle of least access assumes that you have application credentials that are separate from the database credentials.

The username and password of your web application are NOT the username and password of the database. Similarly for a desktop application. Application authentication may not necessarily be database authentication.

In addition, good security assumes that access to usernames and passwords is stored separately from application data. In a large organization with a large number of database users, one administrator must be a “security officer” and handle authentication and authorization. No other users can change the authorization, and the security officer does not have access to the application data.

This is a quick audit to ensure that a security officer never accesses data. It's a little trickier, but another audit can be sure that people with data authorization are real people, not pseudonyms for a security officer.

Hashed passwords are part of a working security policy.

Answer 8

Of course, saving password hashes instead of plain text does not make your application secure. But this is one of the measures that improves security. As you mentioned, if your server is turned on, this measure will not save you, but it limits the damage.

The chain is only strong, like its weak link

Password hashing only strengthens one link in the chain. Therefore, you will need to do more.

Answer 9

In addition to what has already been said regarding salting, another problem of salting arises:

If you use the same salt all over the world (or you don’t have salt at all), you can simply say by looking at the database that user foo and user panel have the same password (even if you don’t know what the password is).

Then, if you achieve getting the password foo (for example, using social engineering), the password is also known.

In addition, if the salt is the same everywhere, you can create a dictionary dedicated to that particular salt, and then launch a brute force attack using this “salt” dictionary.

Answer 10

It may be a little off topic, but from time to time I notice that some websites do not use hashing (for example, when I click the forgotten password button, they send me my password in clear text and do not allow me to choose another one).

I usually just unsubscribe because I don’t think I can trust a website designed by people who don’t take basic precautions for hashed passwords.

This is another reason for salting :)

Answer 11

People seem too smug about this! The threat is not some guy with access to the shell of your system or backup media, it can be any script kiddie that can see the unprotected (but dynamic) part of your site (*) and one missed SQL injection threat, One request and it can log in as any user or even as an administrator. Password hashing makes it less likely that an attacker can log in as any specific user using his password or update the record with his own password.

(*) "unprotected" includes any part of the site that can be accessed as an independent registered user. Compare this to a bank site, for example, where you must have an existing bank account to access most of the site. An attacker could still open a bank account to gain access to the site, but it was much easier to send big guys with big guns after him when he tried to hack the system.