-1

So from what I have seen it is impossible to decrypt any hashing algorithm such as MD5 or SHA-1 without brute forcing it or using rainbow tables. This seemed to confuse me on a few aspects of using hashes. These confusing points are:

  1. What would be the point of hashing in the first place if they cant be decrypted?

  2. How would hashed passwords be able to be used in a database?

  3. Also since people say it is like the modulo operation, what, if anything, is preventing multiple inputs to equate to the same hash?

PsyCode
  • 644
  • 5
  • 14
  • 1
    Storing plaintext passwords is bad for obvious reasons. When storing hashed passwords when a user logs in you don't decrypt the hash and compare... you encrypt the password and compare the hashed values. Yes this means that technically more than one password can work but they're mathematically far enough apart that it doesn't matter. [Here's a more complete explanation](http://stackoverflow.com/a/287738/119477) – Conrad Frix Feb 25 '16 at 22:37
  • Possible duplicate of [Fundamental difference between Hashing and Encryption algorithms](http://stackoverflow.com/questions/4948322/fundamental-difference-between-hashing-and-encryption-algorithms) – Artjom B. Feb 25 '16 at 23:06

3 Answers3

1

If somebody simply does SHA1 or MD5 on a password, then they get almost no protection.

That's why it's important to understand the right way to handle "password hashing". Please read Our password hashing has no clothes

To answer your questions:

  1. You can verify the user without "decrypting the hash": you simply "hash" the user entered password (along with salt and other parameters) upon login and verify that it matches the expected result that is stored in the database.

  2. See 1 and the Troy Hunt link

  3. People who say it is like a modulo operation are making a bad analogy: they are non-experts on this subject. Anyway, the properties of the "hash" function make it hard to find collisions, and the salt prevents two users with the same password from having the same password "hashes" in the database.

Other resources:

TheGreatContini
  • 6,429
  • 2
  • 27
  • 37
  • Good as far as it goes without following the links But a good disclaimer is not to use SHA-1 or MD5—ever, if you need a hash use SHA-256 or perhaps SHA-512. For "hashing" a password don't even use an HMAC, use a key derivation function such as [PBKDF2](https://en.wikipedia.org/wiki/PBKDF2) or [bcrypt](https://en.wikipedia.org/wiki/Bcrypt). – zaph Feb 26 '16 at 00:06
0

It's not like a modulo. A hash is reasonably guaranteed to be unique based on the input. If you enter your passwords in a database as hashes, then all you need to do is to hash the password entry and check it against what you have stored in the database. This way, you are not storing readable passwords in the database which are openly visible to others. Normally, you would have a private key, some salt and something unique like a timestamp included in your hashing algorithm to ensure that it cannot be easily spoofed.

This may help you further: http://searchsqlserver.techtarget.com/definition/hashing

ManoDestra
  • 6,325
  • 6
  • 26
  • 50
  • Note, this is WRT cryptographic hashes, there are other types such as used for dictionary methods which do not need to avoid collisions but just be fast, that is probably where the modulo operation reference coes from. – zaph Feb 26 '16 at 00:04
0

Even if the process of hashing is basically non decryptable, the problem as pointed before is that each hash is nearly unique, so that means using websites like md5decrypt which contains a lot of different words and their encrypted hashes, one may find the password he is looking for.

That is if the password isn't strong enough in the first place. Obviously one shouldn't use the password "password" for instance because it will probably be found in most of the websites like md5decrypt.

What you should do to protect passwords on your website is actually simple. First, don't use old hashes like md5 or sha1. Use at least sha256, and if you've enough sql storage, sha384 or sha512. You should know that most of the online hashes database are only about the most commonly used hashes (let's say md5,sha1,sha256 in most cases). So you should find a hash type that isn't very represented on online database.

Then you should (you have actually to) use salt when encrypt users passwords, that is add some word, letters, whatever, to the password before you encrypt it, then store that salt somewhere so you can still allow people to log in. You could also add a pepper to the salt to make the all thing stronger.

While using the salt, try to find a way that hackers won't think about, for instance double the salt, or triple it, or try different ways to concat the salt and the actual password, etc. You could also make a double encryption with double salt, like sha512(sha384()), which would be almost impossible to find.

But, please, do not store unencrypted passwords !

James
  • 21
  • 3