I am using Scrypt to get a hash for my input and I didn't use SHA3 because I found out that it can be bruteforced with a dictionary attack to find the SHA3 output. Later I was told not to use Scrypt because it's unnecessary and just hash the output of SHA3 a million times, as it would be simpler but also more secure.
Is that true? or is using Scrypt still a fine choice?
No, just hashing the password a million times is not more secure than scrypt.
There are at least two things that are missing:
the use of a salt, which differentiates the hash when users use the same password and prevent rainbow tables;
the memory usage of scrypt which can make it harder to crack passwords using specialized hardware.
What you are trying to re-implement is a password hash or PBKDF (Password Based Key Derivation Function, the same thing but to derive keys instead of hashes). There has been a password hashing competition not too long ago which Argon2 won. Baloon hashing is a later password hash created by a team of cryptographers.
I don't know which of your co-workers or acquaintances think that they could do better, but I think that they should learn about the Dunning-Kruger effect.
This question already has answers here:
Is it possible to decrypt MD5 hashes?
(24 answers)
Closed 5 years ago.
I have MD5-hashed a string.
def hash(s: String) = {
val m = java.security.MessageDigest.getInstance("MD5")
val b = s.getBytes("UTF-8")
m.update(b, 0, b.length)
new java.math.BigInteger(1, m.digest()).toString(16)
}
Now I want the original string back. How can I do this?
MD5 is a cryptographic hash function. Cryptographic hashes are one way functions. You cannot reverse a cryptographic hash value, but you can brute force messages to find one.
Brute forcing means trying all possible input strings and then checking if the hash value is correct. This is possible because cryptographic hashes are also computationally unique. This means that there are endless messages that will result in the same hash value being generated, but it is impossible to two resulting in the same hash. As MD5 is broken, MD5 hashes are not unique for specially constructed messages. It is called a collision if you can find two messages that have the same hash value.
It is also possible to create huge lookup tables called rainbow tables. This can help speedup looking for the right input. That only works for relatively small or guessable data input; i.e. they are mostly used to find weak passwords. Some of these databases can be found online.
You can not decrypt MD5 and this is feature of MD5, if you want encrypt/decrypt data then use other encryption techniques like AES
You couldn't. With MD5 being one-way hash function, it is not possible.
This question already has answers here:
What is the clash rate for md5? [closed]
(2 answers)
Closed 9 years ago.
This question does not need any code, it's just a conceptual thing about MD5 hashing.
My app manages a community of users.
I use MD5 hashing to reduce a user nickname of arbitrary length to a hash. I expect the MD5 of every nick to be different, because this MD5(nick) will be kind of my user ID for every user.
Is this always true? I'm sure I'm missing something and there can be collisions in the long term (millions of users === millions of different nicks with different lengths)
MD5 collisions for random data (eg. usernames) are rare enough that you'd probably never see them. The problem is that MD5 has been broken with respect to collision resistance, so an attacker could easily generate a pair of usernames that have the same hash, with whatever security and/or functionality implications that would have for your design.
The usual way to generate a short identifier in your situation is to simply associate each username with a sequentially-generated number in the account database. The application uses the number internally, and only references the username when it needs to display something to a user.
This question already has answers here:
Decrypt MD5 hash [duplicate]
(5 answers)
Closed 5 years ago.
Does MD5 hashes the string or it encrypt it? If it hashes it, then it's as they say a one-way hash function and original string (or data) are non-recoverable by the hash produced because it's only for authentication. Then how can we explain the online websites for MD5 decryption? I actually tried it, it gets back the original string. And here's a site that does this: http://www.md5decrypter.co.uk/
How is this possible?
MD5 is a hash algorithm, meaning that it maps an arbitrary-length string to a string of some fixed length. The intent is to make it so that it is hard to start with the output of an MD5 hash and to recover some particular input that would hash to that output. Because there are infinitely many strings and finitely many outputs, it is not an encryption function, and given just the output it's impossible to determine which input produced that output.
However, MD5 has many cryptographic weaknesses and has been superseded by a variety of other hash functions (the SHA family). I would strongly suggest not using MD5 if cryptographic security is desired, since there are much better algorithms out there.
Hope this helps!
MD5 is a cryptographic hash function. It maps a variable-length string to a 128-bit hash value. It's one-way but the code can be cracked quickly using Rainbow Tables. Not to mention the site you posted says it has
a total of just over 8.7 billion unique decrypted MD5 hashes...
so it can check against those first before it even needs to try to crack it.
They don't "decrypt", they find a string that matches your hash, which is not the same thing but when you limit yourself to common English words it could very well be.
To understand what's going on you have to consider the count of possible MD5 hashes - 2^128, which is more than the count of words in English (2^16?) but much less than all possible string values 2^(number of bits the internet has and then some)
When you convert from a smaller set into a bigger one (english->MD5) it's likely all values will be different, but the other way around isn't true.
Bottom line: use a password that isn't a string that can be found by google anywhere on the net.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
I've always been curious... Which is better when salting a password for hashing: prefix, or postfix? Why? Or does it matter, so long as you salt?
To explain: We all (hopefully) know by now that we should salt a password before we hash it for storage in the database [Edit: So you can avoid things like what happened to Jeff Atwood recently]. Typically this is done by concatenating the salt with the password before passing it through the hashing algorithm. But the examples vary... Some examples prepend the salt before the password. Some examples add the salt after the password. I've even seen some that try to put the salt in the middle.
So which is the better method, and why? Is there a method that decreases the chance of a hash collision? My Googling hasn't turned up a decent analysis on the subject.
Edit: Great answers folks! I'm sorry I could only pick one answer. :)
Prefix or suffix is irrelevant, it's only about adding some entropy and length to the password.
You should consider those three things:
The salt has to be different for every password you store. (This is quite a common misunderstanding.)
Use a cryptographically secure random number generator.
Choose a long enough salt. Think about the birthday problem.
There's an excellent answer by Dave Sherohman to another question why you should use randomly generated salts instead of a user's name (or other personal data). If you follow those suggestions, it really doesn't matter where you put your salt in.
I think it's all semantics. Putting it before or after doesn't matter except against a very specific threat model.
The fact that it's there is supposed to defeat rainbow tables.
The threat model I alluded to would be the scenario where the adversary can have rainbow tables of common salts appended/prepended to the password. (Say the NSA) You're guessing they either have it appended or prepended but not both. That's silly, and it's a poor guess.
It'd be better to assume that they have the capacity to store these rainbow tables, but not, say, tables with strange salts interspersed in the middle of the password. In that narrow case, I would conjecture that interspersed would be best.
Like I said. It's semantics. Pick a different salt per password, a long salt, and include odd characters in it like symbols and ASCII codes: ©¤¡
The real answer, which nobody seems to have touched upon, is that both are wrong. If you are implementing your own crypto, no matter how trivial a part you think you're doing, you are going to make mistakes.
HMAC is a better approach, but even then if you're using something like SHA-1, you've already picked an algorithm which is unsuitable for password hashing due to its design for speed. Use something like bcrypt or possibly scrypt and take the problem out of your hands entirely.
Oh, and don't even think about comparing the resulting hashes for equality with with your programming language or database string comparison utilities. Those compare character by character and short-circuit as false if a character differs. So now attackers can use statistical methods to try and work out what the hash is, a character at a time.
It shouldn't make any difference. The hash will be no more easily guessable wherever you put the salt. Hash collisions are both rare and unpredictable, by virtue of being intentionally non-linear. If it made a difference to the security, that would suggest a problem with the hashing, not the salting.
If using a cryptographically secure hash, it shouldn't matter whether you pre- or postfix; a point of hashing is that a single bit change in the source data (no matter where) should produce a different hash.
What is important, though, is using long salts, generating them with a proper cryptographic PRNG, and having per-user salts. Storing the per-user salts in your database is not a security issue, using a site-wide hash is.
First of all, the term "rainbow table" is consistently misused. A "rainbow" table is just a particular kind of lookup table, one that allows a particular kind of data compression on the keys. By trading computation for space, a lookup table that would take 1000 TB can be compressed a thousand times so that it can be stored on a smaller drive drive.
You should be worried about hash to password lookup tables, rainbow or otherwise.
#onebyone.livejournal.com:
The attacker has 'rainbow tables' consisting not of the hashes of dictionary words, but of the state of the hash computation just before finalising the hash calculation.
It could then be cheaper to brute-force a password file entry with postfix salt than prefix salt: for each dictionary word in turn you would load the state, add the salt bytes into the hash, and then finalise it. With prefixed salt there would be nothing in common between the calculations for each dictionary word.
For a simple hash function that scans linearly through the input string, such as a simple linear congruential generator, this is a practical attack. But a cryptographically secure hash function is deliberately designed to have multiple rounds, each of which uses all the bits of the input string, so that computing the internal state just prior to the addition of the salt is not meaningful after the first round. For example, SHA-1 has 80 rounds.
Moreover password hashing algorithms like PBKDF compose their hash function multiple times (it is recommended to iterate PBKDF-2 a minimum of 1000 times, each iteration applying SHA-1 twice) making this attack doubly impractical.
BCrypt hash if the platform has a provider. I love how you don't worry about creating the salts and you can make them even stronger if you want.
Inserting the salt an arbitrary number of characters into the password is the least expected case, and therefore the most "secure" socially, but it's really not very significant in the general case as long as you're using long, unique-per-password strings for salts.