Replacing a plain text password for an application

Question

Currently we save simple text passwords for the web application that we have.

I continue to defend the transition to a password hash, but another developer said that it would be less secure - more passwords could correspond to a hash, and a dictionary / hash attack would be faster.

Is there any truth to this argument?

Answer 1

Absolutely nothing. But it does not matter. I sent a similar answer earlier:

It's sad, but people, even programmers, are too emotional to easily give in to the argument. Once he has invested in his position (and if you publish here, he is), you are unlikely to convince him of the facts alone. What you need to do is switch the burden of proof. You need to get him to look for data that he hopes will convince you and, thus, find out the truth. Unfortunately, it has the advantage of the status quo, so you have a difficult road there.

Answer 2

From Wikipedia

Some computer systems store user passwords, for comparing attempts to enter the user's system as open. If an attacker gains access to such an internal password, all passwords and therefore all user accounts will be compromised. If some users use the same password for accounts of different systems, this will be compromised.

More secure systems store each password in a cryptographic secure form, so access to the actual password will still be difficult for snooper, who is gaining internal access to the system, while checking user access attempts remains possible.

In a general approach, only the "hashed" form of the plaintext password is stored. When a user enters a password on such a system, the software for processing passwords through a cryptographic hash algorithm works, and if the hash value generated from the user record matches the hash stored in the password database, the user is allowed access. A hash value created by applying a cryptographic hash function to a string consisting of the password provided and, usually, another value known as table salt. Salt prevents attackers from creating a list of hash values ​​for shared passwords. MD5 and SHA1 are a commonly used cryptographic hash function.

There is much more that you can read on this subject on this page. In my opinion, and in everything that I read and worked, hashing is the best scenario unless you use a very small (<256-bit) algorithm.

Answer 3

There is absolutely no excuse for storing plaintext passwords in a web application. Use the standard hash algorithm (SHA-1, not MD5!) With a salt value, so rainbow attacks are not possible.

Answer 4

If you didn’t salt your password, you suspect a Rainbow Table attack (pre-compiled dictionaries that have valid inputs for a given hash)

Another developer should stop talking about security if you store passwords in clear text and start reading about security.

Conflicts are possible, but not a big problem for applications with passwords (they are mainly a problem in areas where hashes are used to check file integrity).

So: Salt your passwords (by adding salt to the right side of the password *) and use a good hashing algorithm, for example SHA-1 or preferably SHA-256 or SHA-512.

PS: A bit more about hashes here .

* I doubt a little whether the Salt should be at the beginning or at the end of the line. The problem is that if you have collisions (two inputs with the same hash), adding Salt to the "wrong" side will not change the resulting hash. In any case, you will not have big problems with Rainbow Tables, only in a collision

Answer 5

I don’t understand how other passwords of your other developer can match the hash.

There is an argument that the "hash attack will be faster", but only if you do not hijack passwords, as they are hashed. Usually hashing functions provide a salt that makes using a known hash table a waste of time.

Personally, I would say no. Based on the foregoing, as well as the fact that if you somehow get clear textual information, useful hashed value is of little value to someone who is trying to penetrate. Hashing also makes it possible to make all passwords look the same length.

those. if hashing any string always leads to a 20-character hash, then if you only have a hash, then you cannot determine if the original password was eight characters or sixteen, for example.

Answer 6

I faced the same problem in my workplace. What I did to convince him that hashing was safer was to write an SQL injection that returned a list of users and passwords from the public section of our site. This was immediately caused by a serious security issue :)

To prevent dictionary / hash attacks, remember to make a hash against the token, unique for each user and static (username / join date / userguid works well)

Answer 7

There is an old saying about programmers claiming to be cryptographers :)

Jeff Atwood has a good post on: You probably don't store passwords correctly

To answer in more detail, I agree with all of the above, the hash makes it theoretically easier to get the user's password, since several passwords correspond to the same hash. However, it is much less likely that someone will gain access to your database.

Answer 8

It is true that if you do something, yes, there will be collisions, so it would be possible for two different passwords to unlock the same account.

From a practical point of view, however, that is a bad argument. A good hash function (md5 or sha1 will be fine) can pretty much guarantee that there will be no conflicts for all significant lines, especially short ones. Even if it were, if two password matches for the same account are not a huge problem - if someone is able to randomly guess passwords quickly enough so that they can be entered, you have big problems.

I would say that storing passwords in text form poses a much greater security risk than hash collisions in password matching.

Answer 9

I am not a security expert, but I have the feeling that if plain text is more secure, hashing will not exist in the first place.

Answer 10

In theory, yes. Passwords can be longer (more information) than a hash, so there is a chance of hash collisions. However, most attacks are word-based, and the chance of collisions is infinitely less than a successful direct match.

Answer 11

It depends on what you defend against. If an attacker dumps your database (or tricks your application into displaying a database), then plaintext passwords are useless. There are many attacks that rely on convincing the application that it robs it of private data - SQL injection, session capture, etc. Often it’s better not to store the data at all, but to keep the hash version so bad that guys can't use it easily.

As your colleague suggests, this can be trivially defeated by running the same hashing algorithm against a dictionary and using rainbow tables to pull out information. A common solution is to use secret salt plus additional user information to make hashed results unique: for example,

String hashedPass=CryptUtils.MD5("alsdl;ksahglhkjfsdkjhkjhkfsdlsdf" + user.getCreateDate().toString() + user.getPassword); 

As long as your salt is secret, or your attacker does not know the exact date the user record was created, a dictionary attack will fail even if they can display the password field.

Answer 12

Nothing is less secure than storing clear-text passwords. If you use a decent hash algorithm (at least SHA-256, but even SHA-1 is better than nothing), then yes, collisions are possible, but that doesn’t matter, because given the hash, it’s impossible * to calculate that hash strings to him. If you have a username with a password, this feature also exits from the window.

* - technically not impossible, but "computationally impracticable"

If the username is "graeme" and the password is "stackoverflow", then create the line "graeme-stackoverflow-1234", where 1234 is a random number, then the hash memory and store "hashoutput1234" in the database. When it comes to password verification, take the username, password and number from the end of the stored value (the hash has a fixed length, so you can always do this) and combine them together and compare the part of the stored value with the hash.

Answer 13

more passwords could match the hash, and the dictionary / hash attack would be faster.

Yes and no. Use a modern hashing algorithm as an SHA option, and this argument gets a very, very week. Do you really need to worry if this brute-force attack takes just 352 years instead of 467 years? (An anecdotal joke is there.) The value you need to get (without having a password stored in text form in the system) is far ahead of your colleague’s anxiety.

Answer 14

I hope you will forgive me for connecting the solution that I wrote on this using client-side JavaScript to hash the password before passing it: http://blog.asgeirnilsen.com/2005/11/password-authentication-without.html