4

Im new at coding so Maybe I've missed the point of what md5 is about. But from what' i've experienced MD5 encryption is "static" for each word. By static i mean you will always find the same result for example md5("hello"). And this makes me think that is is highly reversible using a library.

What if md5("hello") was assigned a number (example 5), and the string for example

xbuIdSjsdsjsd44s64sd was its encryption. and was equal to 5 but what if sfoiefef465f4ze4f6fe was also its encryption. and was also equal to 5

Because both for a mathematical calculation ends to the same result. That would be dynamic encryption?

I think, but I tell you I'm a newb at all this, so those are just questions that bother me, I think that people who have access to the database md5's password, can reverse them easily by testing words and stocking them as a library.

what do you think guys? and is there an alternative to md5?

thank for any help or enlightnment

james
  • 413
  • 4
  • 7
  • 12
  • 2
    When you say "static", the correct word is "deterministic" - the same input always produces the same output. – Troy Hunt Jul 21 '11 at 22:48
  • 1
    As addition to the other comments, it is pretty unlikely that anyone will be able to find collisions for rather short messages. What is very simple to do though is to create some data that calculates to an MD5 hash, and at the same time generate other data that also calculates to that hash. We are talking seconds (at most) here to calculate. This is why MD5 is so broken, especially for e.g. certificates. E.g. you could let a CA create a certificate for iwannabemaninmiddle.com and then use it for Google com. – Maarten Bodewes Jul 22 '11 at 16:22

3 Answers3

8

For storing passwords no fast hash function which include md5 and SHA1/2 (even when salted) is acceptable. You need to use a slow hash, typically in the form of a Key-Derivation-Function to slow down brute-force. PBKDF2 and bcrypt are popular choices. You should also use a random per user salt.

CodesInChaos
  • 106,488
  • 23
  • 218
  • 262
  • the speed really doesn't matter. All hashing functions are faster than someones harddirsk can write whatsoever – Toskan Jul 17 '16 at 05:52
  • @Toskan How is the speed of a harddisk relevant to password hashing? Password hashing is made deliberately expensive to slow down attacks where the attacker guesses a password and compares the hash to verify that guess. – CodesInChaos Jul 17 '16 at 14:52
  • it is to give you an idea. The hash function is so quickly, that a HD is unable to write out all the codes. You say it is "slow" well no it is not slow at all. YOu can create so many passwords that the slowness of the algorithm does not matter _at all_ – Toskan Jul 19 '16 at 22:19
  • @Toskan I don't understand the point. If you used a fast hash, like MD5 or SHA-1/2, a single GPU can hash billions of passwords per second, which will allow a attacker who has obtained your password hashes to recover most of your passwords. Which is why you should use deliberately slow hashes, like bcrypt to protect passwords. These can be made as slow as you want using a tunable work-factor. See [How to securely hash passwords?](https://security.stackexchange.com/questions/211/how-to-securely-hash-passwords) on security.se. – CodesInChaos Jul 20 '16 at 07:04
  • I might have had a wrong understanding then. – Toskan Jul 20 '16 at 16:38
5

These are indeed legitimate concerns. You might find the following articles interesting:

But MD5 is considered "broken" by security professionals. It depends on exactly what your requirements are: MD5 might be suitable, but more secure hashes like the SHA-2 family would probably be a wiser choice, or even key-strengthening techniques such as PBKDF2 (as CodeInChaos suggests).

Note that your choice of hash algorithm alone can't be considered either secure or insecure in isolation. It's important to use the hash algorithm in a proven, tried-and-tested way.

Community
  • 1
  • 1
LukeH
  • 263,068
  • 57
  • 365
  • 409
  • Thanks everyone I will read through Salt, Rainbow table and check NSA's encryption system – james Jul 21 '11 at 10:17
2

Whether MD5 is safe to use depends on what you use it for, and how.

For message integrity, MD5 is not suitable any more because there exists an attack for finding an alternate message with the same hash.

For storing passwords in a database, MD5 is acceptable, supposed you salt it properly. For this usage, the known attack is entirely unimportant.
If you are in paranoia mode, you can use a more complicated scheme like bcrypt too, but for most people, storing a salted password is just good enough. It prevents the easiest, most obvious attack, is easy to implement, hard to do wrong, and has low overhead.

Note that two different passwords having the same hash value is not really a problem under normal conditions. This happens, so what.

Having said that, using SHA instead of MD5 does not really cost anything extra. It has more bits, no known attack, and is supported by every half decent library.

Damon
  • 67,688
  • 20
  • 135
  • 185
  • 4
    IMO using a slow hash like bcrypt is at least as important as using a salt. Using plain md5/sha1/sha2 even with salt is unacceptable IMO. – CodesInChaos Jul 21 '11 at 10:09
  • 1
    Yeah well, it depends how important the passwords are and/or how high your paranoia threshold is, and what you are willing to pay on the other hand. Sure enough, bcrypt adds some considerable overhead to a prospective attacker, but it also adds _considerable_ load to your server. It's hard to tell what's right and what's wrong. I've had servers on the internet for 16 years, and never had one intrusion (not one that anyone noticed, anyway). In that light, having every login take half a second because the server must crunch numbers seems a bit overdone. But of course your mileage can vary. – Damon Jul 21 '11 at 10:18
  • 3
    @LukeH: If you put the hashing load onto the client, however, then you effectively replace the password with another password (the final hash is nothing but a "password" too), which has no real bearing. The reason why one would use bcrypt is that after an intrusion with db theft, in addition to to a rainbow table attack on all passwords (which salt prevents), an attacker might attempt to brute force passwords _one by one_. For that reason, the hash is made complicated in a silly way, so it takes inacceptably long to crack even one pass. If the client does the hashing, that isn't the case. – Damon Jul 21 '11 at 10:28
  • 1
    For bcrypt to _work_, it is really important that the server does the many-time-hashing. Otherwise it's at best preventing a manual brute force or DoS attack (person entering passwords manually and hitting the send button), which is kind of pointless anyway. – Damon Jul 21 '11 at 10:29
  • Nobody said anything about half a second per login. But even if you configure the iteration number so it takes the server 50ms of crunching it will slow down an attacker considerable without slowing down the server by much. – CodesInChaos Jul 21 '11 at 10:50
  • Making the hashing last about a second is not noticeable in most cases, and pretty much prevents brute forcing. – Cat Plus Plus Jul 21 '11 at 11:10
  • @Cat I think one second is a bit long for server side hashing. But on the other hand it's perfectly fine for applications like true-crypt. – CodesInChaos Jul 21 '11 at 11:15
  • @CodeInChaos: Naw. Logging in is at most once per user session, one second is acceptable. Well, twice if you have double auth on things like password changing or whatnot, but it's still rare. – Cat Plus Plus Jul 21 '11 at 11:25
  • @Cat Plus Plus: And if your app has hundreds of users trying to login simultaneously? (Obviously you can scale up the hardware to allow this, but most finance departments would balk at having to buy lots of extra hardware purely for securing the login process.) – LukeH Jul 21 '11 at 12:39
  • 2
    Well, it depends on the usage scenario. A server can handle one-user-once-per-hour login, or 50-users-per-second login. If it's the once-per-hour case, a login can take one or several seconds no problem. DoS left aside, if 50 users per second could (possibly) log in and you don't want to spend big $$$ on load balancing _just for logging in_, then anything that takes much longer than 10-20 ms is no option, especially since the problem becomes a feedback loop at some point (users that notice that login takes longer than they expect assume that something is wrong, and hit the button again!). – Damon Jul 21 '11 at 12:47