Is MD5 still considered secure for single-user authentication?

Question

Every day removes MD5 for its problems in the context of password storage. But what about usage, when I just want to add an authentication level to what is likely to be used once?

This is just a hypothetical example, but let me say that I have a function that allows the user to reset their password. I email the user a link that they can click to set a new (randomly generated) password.

My real thinking is that I will create an MD5 hash using the value of the private salt and a pair of identifying variables, and use this to create the link.

Let's say the salt for this function is "8b769a378411b705" (I use the same salt for all reset password requests). Other identifying pieces of data are the user identifier and the database identifier of the password hashes already generated.

salt = "8b769a378411b705" (private) user_id = 123 pw_id = 456 code = md5(salt + " " + user_id + " " + pw_id) 

which becomes

 code = "692a71cd7da194145be209e40fcd3e92" 

link example: confirm_reset_password.php? user_id = 123 & pw_id = 456 & code = 692a71cd7da194145be209e40fcd3e92

Is this considered safe in light of problems with MD5? Is there any other one-way hash I should use, like SHA-1?

I use PBKDF2 with SHA1 to store passwords, and I understand that part of its benefit lies in its “sluggishness” and how long it takes to generate hashes. I could generate these better hashes for purposes like this, but I think this can have unpleasant consequences, as you can easily put the server on its knees, bombarding it with requests (incorrect), since each of them leads to a significant CPU task to generate a hash (especially since I use a lot of iterations). It seems that having a “fast” algorithm is suitable for single-use, but I wonder if MD5 remains the best choice.

Thanks!

Answer 1

First of all, MD5 is considered unsafe for many reasons, first of all, rainbow tables for md5 are huge now and probably cover most of the hash space. Secondly, there are well-known attacks that allow you to create hash collisions (in order to mask other data in such a way that they produce the same md5 output). Thirdly, its 128 bit, today its short.

Now, back to your question, if you do not host any security-critical application, you do not store any personal data, medical data or any other data controlled by the laws of the country, you are well versed in md5. Entering your algorithm, it is unsafe, but it is not too safe, it is your choice. The only thing you have to add is freshness, this is a kind of time stamp indicating the validity of your message. Secondly, your algorithm does not offer playback protection :) if the user uses this link once and leaves it in the browser, the attacker can again use this link to reset this password. This is a pretty serious mistake. Therefore, you can fix it.

But I want to tell you something else. DO NOT USE CRYPTO IF IT IS NOT ABSOLUTELY NECESSARY! My humble request. Your password reset scheme can be easily implemented without cryptography and protection against repetition, as well as much greater security. All you have to do is add additional columns to the pw_reset_hash and reset_validity tables and fill them with the RANDOM number and a valid date. Call the user a random number and clear the fields after using it, check their validity in advance. And voila :) Since it is random, it is probably more secure than any hashing algorithm. But use secure PRNG.

Answer 2

Why make a password link? This will make it less secure (as it is based on some known data that may leak)! In this case, randomly generated code is much better.