Recommended Posts

  On 18/07/2013 at 13:36, Mike said:

You do realise that the md5 hashes have a small number of characters and a fixed length. The original MD5 (the hash of the password) is trivial to find because you know its exact length and what characters are in it!

Yeah, 32 characters long and it contains 36 possible letters per character, that's 6.334028666?10?? combinations.

Assuming you can check 1 million hashes per second, that's 6.334028666?10?? seconds or 1.055671444?10?? minutes or 1.759452407?10?? hours or 7.331051697?10?? days or 2.008507314?10?? years, etc. to check every possible combination.

So, the double MD5 is still up on the other page if anyone's able to prove that double hashing is weak.

Wow guys - seems like there are lots of mixed opinions on this one!

 

I've never looked into Salting passwords before, so start implementing salts now.

 

From what I understand, a Salt is a 'unique' phrase appended onto the end of a password, e.g.

sha1($password+$salt)

So what if I still multiple hashed that?

(md5(sha1($password+$salt))

Or what if I added a different salt everytime?

md5(sha1($password+$salt)+$salt2)
  On 18/07/2013 at 17:52, Tjcrazy said:

Wow guys - seems like there are lots of mixed opinions on this one!

 

I've never looked into Salting passwords before, so start implementing salts now.

 

From what I understand, a Salt is a 'unique' phrase appended onto the end of a password, e.g.

sha1($password+$salt)

So what if I still multiple hashed that?

(md5(sha1($password+$salt))

Or what if I added a different salt everytime?

md5(sha1($password+$salt)+$salt2)

 

To be honest you're better off just using an algorithm that implements a salt, key stretching and adjustable iterations at its core (e.g. bcrypt or scrypt).

 

Using a salt, sha1($password . $salt), will prevent people looking up the hashes in any existing rainbow tables, but if your server has been compromised the attacker will probably obtain your salt(s) too, meaning they can still brute force most of the passwords. A single modern GPU can generate 3 billion SHA1 hashes per second, in less than a week you could brute force all 8-character passwords (character set: 0-9A-Za-z!$%&*+,-.:;^_`~<>?@) unless you use a different salt per-password, multiple hashing won't prevent this either. 

 

BCrypt on the other hand is arbitrarily slow, giving you a compromise between security and speed (you can adjust the iteration count). Even a modern GPU (or CPU) will only be able to calculate around 20 hashes per second making brute-forcing non-dictionary words effectively useless, unless the attacker has unlimited funds. 

 

SHA1 (and other quick hashing algorithms) are good for verifying data integrity, but less than ideal for storing passwords. The relative calculation speed of SHA1/MD5 make them a perfect target for brute forcing.

  • Like 1
  On 18/07/2013 at 05:11, theblazingangel said:

Your assumption that such hashes have to be cracked one layer at a time MUST be based on an presumption that an attacker will have no knowledge of your algorithm (your choice of which hash functions are used and how they are chained, etc) and will be unable to determine it. In theory and based on this presumption: In terms of an attacker using lookup tables, when they lookup a hash they would find that the result is a string that's not the password itself but instead the hash from the parent hashing function. They would then need to look that up, and so on until they eventually get to the actual password. There is an inefficiency of having to do multiple lookups, but more crucially for this to actually work in practice, in order to actually be able to perform these lookups, the attacker would require lookup tables that cover the hashes of all possible hashes. Such tables cannot exist because they would require a vast amount of disk space to store. Only two chained hash functions could therefore actually suffice here to block lookup attacks.

You cannot rely upon this presumption though. If we assume that an attacker does somehow know the algorithm, then with a lookup table based attack, the attacker can compile lookup tables based on your specific algorithm prior to then attempting an attack on the stolen hashes. Understand that hashing algorithms are designed to be quick, so throwing in a few extra function calls isn't really going to significantly impact an attacker generating them. Furthermore in relation to brute-force/dictionary based attacks against an offline copy of the hashes, the impact of your algorithm in terms of speed of execution is going to be negligible.

Xinox and Asik also raised some excellent additional points earlier.

Just want to correct myself on a point I made here in regards to hashes of hashes in lookup tables and iterative lookups. MD5 produces a 128-bit output so there are 2^128 (3.40282366920938463463374607431768211456 ? 10^38) possible permutations, which would obviously require a vast amount of storage. However obviously you don't actually need a lookup table containing ever single possible hash of a hash. Underlying an attack you've got a much smaller set of password guesses and you'd only need hashes derived from these. So if for example you have one million possible passwords in your lookup table, and you're attacking a set of hashed passwords that have been put through three chained executions of md5() i.e. md5(md5(md5(password))), then for each password guess entry you'd also need to include in the lookup table the result of md5(md5(guess)) and md5(md5(md5(guess))) in order to do the complete iterative lookup, i.e. just three million entries. This requires far less disk space than I was originally considering and therefore makes an iterative lookup approach much more viable.

Though obviously as originally described, the attacker will most likely know your algorithm and so could instead create new lookup tables specific to it, trading some degree of processing time for a lower storage requirement.

 

  On 18/07/2013 at 05:24, The_Decryptor said:

I don't see the multiple hashes making it less secure, but it doesn't really make it more secure either since while you're running multiple iterations of the hash function, they're "fast hashes", so you're not increasing the cost by a large extent. Something like bcrypt follows a similar design (where it iterates over the input multiple times), but it does it to increase the computational complexity of the entire hash computation (That is, it's designed to take a certain amount of time per hash, not a certain amount of iterations)

Precisely, there is merit to the basic principle of iterative hashing because it increases the time required to perform an attack. However as you mention, hashing functions are designed to be fast and so chaining a few together is going to make little difference. PBKDF2 and bcrypt perform iterative hashing in a similar fashion, however, the algorithm is designed to be significantly slower, thousands of iterations are usually done, and the algorithm by which hashing is chained has been designed by experts in the field of cryptography. Use of one of these two hashing functions can have a significant impact on an attacker.

 

  On 18/07/2013 at 05:24, The_Decryptor said:

Regarding salts, instead of using just one salt for all accounts (I've seen that suggested/used before), use a random salt per user (like their username). Even without something like bcrypt that would defeat rainbow tables in the case where the attacker is trying multiple accounts (While if the attacker is just targeting one account, like an admin, it won't help at all, that's where bcrypt comes in)

Per-user salts is indeed the right way to use them. A single salt for all users invalidates basic lookup/rainbow tables requiring an attacker to generate a new set that incorporates the salt within the computation, with which hashes for all users can then be attacked. A per-user salt requires an attacker to generate new lookup/rainbow tables for each user individually, which further increases time and data storage requirements. Furthermore per-user salts help ensure that all hashes are unique, therefore if two users shared the same password the attacker would be unaware of this. Similarly if performing a brute-force/dictionary attack on an offline copy of hashes, each computation of a guess will only be valid for a single user record with per-user salts, which is particularly significant when combined with PBKDF2/bcrypt.

To be clear, salting does NOT "defeat" rainbow tables in any case, it simply requires new ones be generated that incorporate the salt in the computation.

Using usernames for salts isn't a great idea. Usernames are reused and may be publicly known, reducing lookup-table storage requirements for an attacker and allowing them to pre-compute lookup tables in advance of breaching a database. With random salts, which an attacker should presumably only gain access to at the same time as the hashes, i.e. upon breaching the database, lookup-tables must be generated at that point and passwords cracked before the breach is discovered and passwords changed. Using the username as a salt isn't terrible, but its not as good as a proper random salt.

I disagree with the "good rule of thumb" in the article some people are pointing to that suggests that salts should be as long as the output of the hash function. As they describe under the heading 'short salt', with a very short salt an attacker may have no problem generating lookup/rainbow tables covering all possible permutations of the salt, which I agree with, however recommending a salt length of 128bits in the case of md5 is just ridiculous in my opinion. It should be assumed of course that salts are available to the attacker.

 

  On 18/07/2013 at 11:59, n_K said:

So for anyone that says that double or triple or n+ hashing doesn't make it secure, put your money where your mouth is;

342a404105b959b98bf4c52af0732e6b

MD5 hash of an MD5 hash of a simple password.

And if in 7 days you can't produce either the original MD5 nor the original text, we'll just assume like previously predicted; you're wrong.

I personally do follow your train of thought, you are assuming that an attacker would have to lookup the hash in a table that contains all hashes of hashes, repeating this as many times as necessary (depending on how many times hashing functions were chained), eventually ending up at the first hash, at which point they would be trying to lookup the actual password that resulted in that first hash. You are also assuming that the lookup table needs to include all possible hashes of hashes and therefore arguing that this would be impossible because the lookup tables would be too vast to exist. However, you are completely misunderstanding how someone would go about attacking such a hashed password, as others are trying to explain to you. An attacker, knowing your hashing method - two chained executions of md5() - would simply generate a new lookup table of password guesses in which would be stored the resulting hash from your hashing mechanism against each possible password. The attacker would then lookup your hashes in this new lookup table.

To be really clear, let's say that an attacker wants to have 'hello' as an option in their lookup table and they are attacking a set of hashed passwords that have been hashed with two chained executions of md5(), i.e. md5(md5(password)). md5('hello') = 5d41402abc4b2a76b9719d911017c592 and md5(md5('hello')) = 69a329523ce1ec88bf63061863d9cb14. Based on your logic the attacker would use a lookup table based on single executions of md5() which would need to include the following entries:

5d41402abc4b2a76b9719d911017c592 -> hello

69a329523ce1ec88bf63061863d9cb14 -> 5d41402abc4b2a76b9719d911017c592

In actuality the attacker would build a new lookup table based on md5(md5(password) which does not need any hashes of hashes:

69a329523ce1ec88bf63061863d9cb14 -> hello

Furthermore I've explained at the top of this post why you don't actually need ALL hashes of hashes but just a subset.

 

  On 18/07/2013 at 12:38, n_K said:

Why don't you learn to ****ing read?

Using a salt means the salt is known, include salt in the cracking system.

Salts do not slow down cracking or stop dictionary/bruteforce attacks from working, all they do is stop rainbow tables.

An md5 hash of an md5 hash also stops rainbow table attacks because THERE ARE NO RAINBOW TABLES OF THE MD5 HASHES, WILL YOU PLEASE RE-READ UNTIL YOU FINALLY UNDERSTAND?

tldr; MD5'ing an MD5 stops rainbow table attacks like salting does, neither method stops or slows down dictionary/bruteforce attacks.

Salting does NOT stop lookup/rainbow tables, it simply requires new ones be generated that incorporate the salt in the computation.

Chained hashing also does NOT stop lookup/rainbow table type attacks, it simply requires that new tables be generated where hashes are computed using the same algorithm as used on the hashes to be attacked. Tables containing hashes of hashes are not necessary.

 

  On 18/07/2013 at 12:53, Phouchg said:

Perhaps it'd also help if you'd turn down the rage dial a little.

Agreed!

 

  On 18/07/2013 at 13:36, Mike said:

You do realise that the md5 hashes have a small number of characters and a fixed length. The original MD5 (the hash of the password) is trivial to find because you know its exact length and what characters are in it!

Err, no.

 

  On 18/07/2013 at 13:49, threetonesun said:

Right, sha1(md5(password)) is... well, it's silly.

 

Adding salt prevents the generation of rainbow tables, adding iterations prevents (or at least, makes less feasible) brute force attacks. Both of these ideas have been used in modern encryption algorithms, there's not a good reason to try and cobble together something using md5 hashes.

 

The real concern is, if someone gets access to your entire database, what information to they now have? That's what often gets overlooked by sites.

Again, salting does NOT stop lookup/rainbow tables, it simply requires new ones be generated that incorporate the salt in the computation.

Adding iterations does NOT prevent brute force attacks, it only slows them down to some degree.

 

  On 18/07/2013 at 15:26, n_K said:

Yeah, 32 characters long and it contains 36 possible letters per character, that's 6.334028666?10?? combinations.

Assuming you can check 1 million hashes per second, that's 6.334028666?10?? seconds or 1.055671444?10?? minutes or 1.759452407?10?? hours or 7.331051697?10?? days or 2.008507314?10?? years, etc. to check every possible combination.

So, the double MD5 is still up on the other page if anyone's able to prove that double hashing is weak.

I don't know where you're getting 36 characters from. An MD5 hash is hexadecimal, i.e. it consists of characters 0-9 and a-f, in other words 16 possible characters. That's 16^32 = 3.40282366920938463463374607431768211456 ? 10^38 possible permutations. I'm not going to bother going into the rest of it, check the first thing I wrote in this post for an explanation of why you don't need to iterate through all hashes of hashes.

 

  On 18/07/2013 at 17:52, Tjcrazy said:

Wow guys - seems like there are lots of mixed opinions on this one!

I've never looked into Salting passwords before, so start implementing salts now.

From what I understand, a Salt is a 'unique' phrase appended onto the end of a password, e.g.

sha1($password+$salt)
So what if I still multiple hashed that?

(md5(sha1($password+$salt))
Or what if I added a different salt everytime?

md5(sha1($password+$salt)+$salt2)
Replace the word 'phrase' with 'string', and it doesn't have to be appended, you can prepend it or even chop it and the password up and mash them together in some way. You should always assume that an attacker has access to your code though, so doing something fancy i.e. mashing the two together in some way is pointless. Just append/prepend it, your choice as to which.

Both of your suggested hash-chaining options are useless, they offer no real benefit whatsoever over simply adding a single salt to a single use of a hash function. Multiple salts make no difference, you need to assume the attacker has them along with the hash after all.

My advice:

  • Stop trying to come up with odd hashing algorithms like this, they're not going to help you at all.
  • Stop using md5/sha1, at least use sha256 or preferably in some cases PBKDF2/bcrypt.
  • Do use a salt and use a different one for each user.
  On 18/07/2013 at 05:11, theblazingangel said:

I disagree with your simple notion that the key to encryption is to not rely one thing on another; in cryptography this seems to me to be prevalent. Most if not all crypto relies on the discreet logarithm problem for instance. HTTPS relies on both public-key (asymmetric) and symmetric crypto. I could go on, but I'm just nit-picking :p

 

The more secure things are, the more obfuscated they are. Thats really what crypto is. obfuscation.

Just as a matter of interest, the idea of password generating is that every time the password is entered, it generates the same hash. With a "random"  salt as random as a preset salt, just random to those that don't know it.

So how would one have a fully random salt which generates a different hash each time that can actually be used?

Or this in the trend of hash(password+salt+password/username) ? Cause I cant see it working if it isn't easily reproduceable.

 

I personally made my own hashing function using a little used encryption method Whirlpool together with from what I think is a lesser used sha, as it  usually seems sha1, 256 or 512 and im going with 384 as I'm hoping it helps being a bit unpredictable in the hashes you use.

  On 18/07/2013 at 21:45, Shadowzz said:

Just as a matter of interest, the idea of password generating is that every time the password is entered, it generates the same hash. With a "random"  salt as random as a preset salt, just random to those that don't know it.

So how would one have a fully random salt which generates a different hash each time that can actually be used?

Or this in the trend of hash(password+salt+password/username) ? Cause I cant see it working if it isn't easily reproduceable.

 

I personally made my own hashing function using a little used encryption method Whirlpool together with from what I think is a lesser used sha, as it  usually seems sha1, 256 or 512 and im going with 384 as I'm hoping it helps being a bit unpredictable in the hashes you use.

I'm finding it a little hard to follow you, but I'll try and respond...

When a user registers a new account on your web application, they provide their desired username and password. You should use a secure CSPRNG (Cryptographically Secure Pseudo-Random Number Generator) in the generation of a salt. You hash the password and the salt together to encrypt the provided password. This could be done something like the following:

$salt = bin2hex(mcrypt_create_iv(20, MCRYPT_DEV_URANDOM));
$passwordHash = hash('sha256', $password . $salt);
You would then store the salt and the hash in the database. A good suggestion made here is that you might like to store the hash method too (and if using PBKDF2/bcrypt the number of iterations also), which will help in getting your application to cleanly handle migration to a different hash function (and/or alternate number of iterations) at a future date. You could concatenate these pieces of data together as a string in the form of HashMethod:Salt:Hash and store it in a single field in the database table if you wished.

The salt above has been generated with a cryptographically secure random generator and it is unique to that user. If the user's password is ever changed, you can generate a new salt for them.

Your own hashing algorithm involving chaining of whirlpool and sha384 is precisely the same kind of thing this entire thread has been discussing. It is doing very little to nothing at all to enhance your security. Furthermore the idea of hiding behind the "lesser used" sha384 in the hope of being "unpredictable" is frankly ridiculous, I'm sorry but it is :/

I'm interested in N_K's challenge. So usually, it's to be assumed that the rules of passwords are known. If passwords are limited to something like alphanumerics of 8 characters or less, then it's not too hard...

 

52 possible characters (upper and lower), 10 possible digits, and length of 0 to 8 means there are at most 62^8 tasks to carry out (basically the comparison, MD5(MD5(PasswordGuess)) == KnownHash). Sure, 200 trillion of those sounds like a lot, but

MD5 is popular because it is not slow. Fast implementations take advantage of SSE or even better, CUDA, which means you can generate hundreds of millions keys per second. Some rough math shows that (depending on your hardware), it is possible to go through all 200 trillion in less than a week.

 

Still I wouldn't trust my own coding skills to create a program that's really that fast :P

  On 19/07/2013 at 01:27, Salutary7 said:

I'm interested in N_K's challenge. So usually, it's to be assumed that the rules of passwords are known. If passwords are limited to something like alphanumerics of 8 characters or less, then it's not too hard...

 

52 possible characters (upper and lower), 10 possible digits, and length of 0 to 8 means there are at most 62^8 tasks to carry out (basically the comparison, MD5(MD5(PasswordGuess)) == KnownHash). Sure, 200 trillion of those sounds like a lot, but

MD5 is popular because it is not slow. Fast implementations take advantage of SSE or even better, CUDA, which means you can generate hundreds of millions keys per second. Some rough math shows that (depending on your hardware), it is possible to go through all 200 trillion in less than a week.

 

Still I wouldn't trust my own coding skills to create a program that's really that fast :p

 

Indeed, a single high-end GPU (7970) can generate/compare around 6 billion MD5 hashes per second, worst case 3 billion of md5(md5(text)) per secondif you were to assume the password was alpha-numeric of only 8 characters it would only take (62^8 + 62^7 + 62^6 + 62^5 + 62^4 + 62^3 + 62^2 + 62) / (3 * 10^9) seconds ? 20.5 hours. So yeah, if it was 8 alpha-numeric characters or less you could definitely crack it in less than a week (or a day even).

 

Also, since services like Amazon EC2 offer on-demand access to servers with high-end GPUs priced at only $2/hour you could do it much quicker too by simply spinning up a few instances for an hour or two. 

  On 19/07/2013 at 01:27, Salutary7 said:

52 possible characters (upper and lower), 10 possible digits, and length of 0 to 8 means there are at most 62^8 tasks to carry out (basically the comparison, MD5(MD5(PasswordGuess)) == KnownHash). Sure, 200 trillion of those sounds like a lot, but

MD5 is popular because it is not slow. Fast implementations take advantage of SSE or even better, CUDA, which means you can generate hundreds of millions keys per second. Some rough math shows that (depending on your hardware), it is possible to go through all 200 trillion in less than a week.

 

Out of curiosity, I just checked what rate my 5yo computer can compute md5(md5()) at with hashcat, and it was 3GHash/sec. With a newer GPU, I imagine you could compute them at least 2x faster.

Even worse than that, you guys just calculated the full compute time.

 

Most attacks begin with dictionaries that will obtain 70% or so of passwords and take about an hour to run. On top of that, chances of your password laying at the very end of the that 20.5 hour run are (on average) nearly 0.

 

MD5 is a fast password hash. It's not something you should be using for storing passwords. The same is true of SHA1. If you are looking to hash passwords, you should be using bcrypt or one of the other slow chain hash methodologies.

 

Also, salting doesn't note-worthily increase the compute time for a single password. The benefit of hashing is that you need to recalculate the hashes for every single user name (due to their differing salts).

 

Running MD5 repeatedly, or chaining multiple algorithms only helps you in increasing the compute time, in which case there are better ways to do it >.< When I was starting Crypto at uni, I wondered that myself. The simple answer is that you must at all times assume that an attack is aware of how the encryption scheme works. Security through obscurity (that is hiding how the scheme works) is not security at all. You need it to be publicly known and computationally impractical to attack.

 

Yep..


  On 19/07/2013 at 03:54, jkenn99 said:

Out of curiosity, I just checked what rate my 5yo computer can compute md5(md5()) at with hashcat, and it was 3GHash/sec. With a newer GPU, I imagine you could compute them at least 2x faster.

So much worse than that if you have a dedicated chip. There's a dedicated MD5 hashing chip that will scream through them about 200 times faster than that >.<

Yeah, I was playing around with hashcat last night and I was getting around 1.6 billion MD5 hashes a second on my GTX 570, and that was probably with bad settings.

With the double MD5 case I was only getting 600 million hashes a second.

  On 18/07/2013 at 19:39, theblazingangel said:

...

To be clear, salting does NOT "defeat" rainbow tables in any case, it simply requires new ones be generated that incorporate the salt in the computation.

Using usernames for salts isn't a great idea. Usernames are reused and may be publicly known, reducing lookup-table storage requirements for an attacker and allowing them to pre-compute lookup tables in advance of breaching a database. With random salts, which an attacker should presumably only gain access to at the same time as the hashes, i.e. upon breaching the database, lookup-tables must be generated at that point and passwords cracked before the breach is discovered and passwords changed. Using the username as a salt isn't terrible, but its not as good as a proper random salt.

...

What I meant by "defeating" rainbow tables, was that you'd have to re-generate the table for each user (and only that user), so you're spending a lot of time pre-generating a single use dataset, when you could just compare the hashes as you're generating them against the hash you have instead (So if you hit a match, you don't waste time by generating the rest of the table)

Although with my earlier comment about GPU based hash computation, maybe that isn't such a big deal.

Question though, what makes a random per user salt stronger than salting with the username? Is it just that the username would contain "less randomness" compared to a random salt? You're storing them both in the database so I don't see that as the weakness.

  On 19/07/2013 at 11:35, The_Decryptor said:

Question though, what makes a random per user salt stronger than salting with the username? Is it just that the username would contain "less randomness" compared to a random salt? You're storing them both in the database so I don't see that as the weakness.

 

I don't think there is any significant difference. They accomplish the same goal of having a unique salt per user account.

  On 18/07/2013 at 21:28, srbeen said:

The more secure things are, the more obfuscated they are. Thats really what crypto is. obfuscation.

uh... what? guess you've never heard of one-time pads...

 

  On 19/07/2013 at 12:45, Salutary7 said:

I don't think there is any significant difference. They accomplish the same goal of having a unique salt per user account.

does length or entropy matter for a salt given that it's known anyway?

  On 19/07/2013 at 14:26, primexx said:

does length or entropy matter for a salt given that it's known anyway?

 

One of the desirable traits of hash algorithms is that small changes to the input will result in seemingly unpredictable changes to the output. The two hashes for "abc" and "abc1" will look just as different from each other as the hashes for "abc" and "abc2". So the 'randomness', length, or any other quality of the salt shouldn't make a difference, so long as the same salt isn't repeatedly used. Obviously, though, in other cryptographic scenarios, entropy and length of keys does play a big part in security.

  On 19/07/2013 at 07:37, Mike said:

<snip - palm-face image a bit large...>

Let me give you a better reply :p (Though I'm just going to be repeating myself a bit and I'm not sure you're actually after one...)

...>

  On 18/07/2013 at 13:36, Mike said:

You do realise that the md5 hashes have a small number of characters and a fixed length. The original MD5 (the hash of the password) is trivial to find because you know its exact length and what characters are in it!

Yes, we know that an md5 hash is exactly 32 characters long and made up of hexadecimal digits only (case in-sensitive), i.e. it's 128-bits long. Knowing this does not help us at all though in doing a reverse iterative lookup with lookup/rainbow tables to get to the first hash, as I've already pointed out. There are 2^128 (3.40282366920938463463374607431768211456 ? 10^38) possible permutations (unique md5 hashes). In order to *guarantee* being able to do such an iterative reverse lookup, for absolutely any password string imaginable, you would need every single one of these hashes in a lookup table and beside each the corresponding output hash of hashing them. Never mind the time required to compile it and later search it, without any overhead (or compression), you would need 128bits * 2 * (2^128) = 8.7112285931760246646623899502532662132736 ? 10^40 bits = 9.903520314283042199192993792 ? 10^27 TERABYTES of storage. You can reduce this requirement significantly if you instead have a much smaller set of passwords that you're wanting to be able to crack, in which case you only need all of the intermediate and final hashes of chain-hashing those for as many iterations as the algorithm used. But then this trade off makes it much less certain that you're going to be successful.

 

  On 19/07/2013 at 11:35, The_Decryptor said:

What I meant by "defeating" rainbow tables, was that you'd have to re-generate the table for each user (and only that user), so you're spending a lot of time pre-generating a single use dataset, when you could just compare the hashes as you're generating them against the hash you have instead (So if you hit a match, you don't waste time by generating the rest of the table)

Although with my earlier comment about GPU based hash computation, maybe that isn't such a big deal.

Sure, it may very well be more efficient to compare as you go along in such a case, therefore turning it into a brute-force type attack. So now I'm just being pedantic about lookup/rainbow tables being "defeated" when they're still perfectly viable, just not necessarily the best option. (Y)

 

  On 19/07/2013 at 11:35, The_Decryptor said:

Question though, what makes a random per user salt stronger than salting with the username? Is it just that the username would contain "less randomness" compared to a random salt? You're storing them both in the database so I don't see that as the weakness.

  On 19/07/2013 at 12:45, Salutary7 said:

I don't think there is any significant difference. They accomplish the same goal of having a unique salt per user account.

  On 19/07/2013 at 14:26, primexx said:

does length or entropy matter for a salt given that it's known anyway?

  On 19/07/2013 at 17:17, Salutary7 said:

One of the desirable traits of hash algorithms is that small changes to the input will result in seemingly unpredictable changes to the output. The two hashes for "abc" and "abc1" will look just as different from each other as the hashes for "abc" and "abc2". So the 'randomness', length, or any other quality of the salt shouldn't make a difference, so long as the same salt isn't repeatedly used. Obviously, though, in other cryptographic scenarios, entropy and length of keys does play a big part in security.

If usernames were acceptable salts here then surely the output of any random number generator would also suffice. So why then is it that articles such as this one recommend that a CSPRNG must be used? (Admittedly I don't believe that article to have been written by an "expert" cryptographer, and it itself doesn't give an explanation). The only logical explanation that comes to my mind is that the use of a decently unpredictable method of salt generation makes it much more difficult for an attacker, *PRIOR* to breaching your system and obtaining the actual salts, to create pre-computed lookup/rainbow tables incorporating salts actually in use in your system. An attacker is at an advantage if he can generate such tables in advance of breaching your security.
  On 19/07/2013 at 17:17, Salutary7 said:

One of the desirable traits of hash algorithms is that small changes to the input will result in seemingly unpredictable changes to the output. The two hashes for "abc" and "abc1" will look just as different from each other as the hashes for "abc" and "abc2". So the 'randomness', length, or any other quality of the salt shouldn't make a difference, so long as the same salt isn't repeatedly used. Obviously, though, in other cryptographic scenarios, entropy and length of keys does play a big part in security.

I understand what you're saying and don't necessarily disagree with you, but in most cases, there simply isn't any good reason to compromise on security. It often comes down to laziness or incompetence. When a web service stores user passwords without salt (or even worse, as plain text), it makes you question the quality of their service as a whole.

 

In the end, it really is best to stick to standard cryptographic protocols rather than making up your own. Do a little research into the encryption used by MEGA to understand why; you'll find that security researchers quickly pointed out several issues with it.

Just another tip, hiding your password creation and verification routines isn't a bad idea.

 

I like to use used an encrypted stored procedure in the database server for logins(In my case MSSQL). You feed it the user name and password, it returns true or false. You can, of course, get more complex, but the design rule was that all logins are validated through the one procedure. You can call it from another proc, from the web server or from any other front end, but that SP was the only way to validate a login.

From what I can tell: Multiple hashing a password DOES make it more secure, but only marginally.

 

It's MORE efficient and secure to use more complex hashing methods, like bcrypt and salts.

 

Am I correct?

  On 21/07/2013 at 23:42, Tjcrazy said:

From what I can tell: Multiple hashing a password DOES make it more secure, but only marginally.

 

It's MORE efficient and secure to use more complex hashing methods, like bcrypt and salts.

 

Am I correct?

You should be using salts no matter what you do. But yes, something like bcrypt or a PBKDF solution would be better than using regular hashing methods.

  On 21/07/2013 at 23:42, Tjcrazy said:

From what I can tell: Multiple hashing a password DOES make it more secure, but only marginally.

 

It's MORE efficient and secure to use more complex hashing methods, like bcrypt and salts.

 

Am I correct?

"Multiple hashing" being more secure - a little bit, yes.

More efficient and secure to use methods like bcrypt and salts - yes and no. Yes, salts absolutely enhance security. Yes, bcrypt (or PBKDF2) is going to be a more secure choice. No, bcrypt (or PBKDF2) are not going to be more efficient, it will require more processing power (on the part of both yourself and an attacker).

My advice again:

  On 18/07/2013 at 19:39, theblazingangel said:
  • Stop trying to come up with odd hashing algorithms like this, they're not going to help you at all.
  • Stop using md5/sha1, at least use sha256 or preferably in some cases PBKDF2/bcrypt.
  • Do use a salt and use a different one for each user.
This topic is now closed to further replies.
  • Posts

    • we also turn off the printer thesee days, because we print something like once a month we were printing several times a week in the past, so printer was kept on, but we don’t print much right now, so we turn it off… btw, it’s a laser printer
    • It's more of snark and rhetorical question, I highly doubt KDE will have this for a while.
    • Interesting for sure, I'd like to see 3rd party benchmarks in due time. I just hope Intel can do more in the dGPU space as well.
    • Not going to connect my PC to MS just for a few months extra support,
    • Microsoft Weekly: Windows 11 version 25H2 is official, free updates for Windows 10, and more by Taras Buria This week's news recap is here, and it is full of interesting and important stories. We have Windows 11 version 25H2 announcement, free extended security updates for Windows 10, redesigned BSOD, non-security updates with new features, and more. Quick links: Windows 10 and 11 Windows Insider Program Updates are available Reviews are in Gaming news Great deals to check Windows 11 and Windows 10 Here, we talk about everything happening around Microsoft's latest operating system in the Stable channel and preview builds: new features, removed features, controversies, bugs, interesting findings, and more. And, of course, you may find a word or two about older versions. The biggest Windows story of this week was undoubtedly the launch of the Extended Security Update program for Windows 10, which will soon be out of support (governments are now issuing warnings to Windows 10 users). What is interesting is that Microsoft is giving away free security updates—all users need to do is back up their PCs with the Windows Backup tool. Other options include paying with 1,000 Microsoft Rewards points or $30, so pick your poison. If you are thinking about staying on Windows 10, perhaps this article will convince you to switch. Microsoft published a few reasons why Windows 11 is a better choice than the outgoing Windows 10. Another post compares the performance of the two operating systems in another attempt to make you ditch Windows 10. There is also a new ESU guide for office PCs that do not support Windows 11. Another major story is about the Blue Screen of Death, which will soon become the Black Screen of Death and lose its iconic smiley face. Microsoft revealed that the redesign is coming later this summer, alongside Quick Machine Recovery. This new tool can fix PCs that cannot boot due to outages, malware, or other software nastiness. We are not done with big news just yet. Microsoft confirmed that Windows 11 version 25H2 is coming later this year. This year's feature update is coming soon, and the first officially marked preview builds are now available for testing. Microsoft also released the June 2025 non-security updates for Windows 10 and 11 users. It all started with Windows 10, which received KB5061087 with build number 19045.6036. Windows 11 version 24H2 received KB5060829, and Windows 11 versions 22H2 and 23H2 received KB5060826. Also, Windows 11 received a new configuration update to resolve the stuck Windows Update (and new setup updates), Windows Server 2025 got a new security baseline, and the Media Creation Tool now downloads the latest Windows 11 images with the June 2025 Patch Tuesday fixes. Another important story is about Secure Boot, one of Windows 11's hardware requirements. Microsoft published a lengthy blog post warning that its first certificates will soon expire, and users should prepare to update them if they want their PCs to be secure and compatible with third-party apps going forward. No week goes by without some Windows issues. This time, Dell acknowledged a problem with Night Light on certain Windows on ARM PCs. The bug breaks Night Light on the secondary display, but Dell says you should blame Qualcomm and its Oryon chipset. Microsoft, on the other hand, confirmed more issues with Chrome on Windows. This week's Windows trivia includes an interesting story from Microsoft veteran Raymond Chen. He published a new blog post where he recalled how PC manufacturers used to trick BIOS copyright strings to get full editions of trial versions of various apps. To finish this week's Windows section, here is a small tip for those who want to make Windows 11 feel a little snappier. A hidden accessibility feature can make the user interface much more responsive and fast, so check it out here. Windows Insider Program Here is what Microsoft released for Windows Insiders this week: Builds Canary Channel Nothing in Canary this week Dev Channel Build 26200.5661 This build introduced a new home page for Recall, a single place where you can access your recent snapshots, recommended documents, and other useful information. The update also lets you change where system indicators appear on the screen. Build 26200.5670 This build introduces 1Password integration for Passkeys, Settings improvements, version 25H2 marking, and more. It also fixes the Windows Vista startup sound after the previously failed attempt. Beta Channel Build 26120.4452 This is the same build as 26120.4452 Build 26120.4520 This build is the same as 26200.5670 from the Dev Channel, minus the version 25H2 part. Release Preview Channel Nothing in Release Preview this week Additionally, Microsoft released new screen-recording capabilities for the Snipping Tool app for more Windows Insiders (Beta and Release Preview). Updates are available This section covers software, firmware, and other notable updates (released and coming soon) delivering new features, security fixes, improvements, patches, and more from Microsoft and third parties. This week's browser updates include some major releases and plenty of Firefox updates. Mozilla released Firefox 140 with custom search engine support, a new ESR release, and more changes. Shortly after, it released version 140.0.1 with fixes for dark theme issues and crashes and version 140.0.2 with fixes for crashes on certain Windows devices. Microsoft released Edge 138 with AI-powered history search and a warning for IT admins, and Google released Chrome 138. Office updates include the new Outlook for Windows coming to Microsoft 365 Education in early next year. Speaking of the new Outlook, Microsoft also published a story that explained why the app is actually great and why haters are wrong. Oh, Microsoft... Teams is getting a new health dashboard feature, PowerPoint can generate presentations from PDFs or text files, and Modern Page Templates are coming to SharePoint. Microsoft also published detailed guides about fixing Office 2024 activation issues. Finally, here is this week's recap of the new features coming soon to the Microsoft 365 productivity suite and a recap of everything new in Excel in June 2025. Here are other updates and releases you may find interesting: Microsoft announced Mu, an on-device small language model for Windows 11. The Comet AI browser is coming to Windows, now in private beta. Discord for Windows on ARM is now in development. Surface Copilot+ PCs are coming to classrooms on July 22. Raycast for Windows is now in closed beta; here is the first look. Visual Studio is now even smarter, thanks to more AI models and billing updates. France's third-largest city is ditching Windows and Office in favor of Linux and FOSS. Here are five things that people want in Microsoft Teams. Here are the latest drivers and firmware updates released this week: Intel 32.0.101.6913 WHQL graphics driver with Mecha BREAK support and more. Reviews are in Here is the hardware and software we reviewed this week Steven Parker reviewed the TerraMaster F4 SSD, an extremely lightweight and quiet all-SSD NAS with some good connectivity, a decent price tag, and good design. It is not flawless, but it still managed to score 8.5 out of 10 on Steven's NAS scale. Robbie Khan reviewed the Keychron Lemokey G2 8K Wireless mouse. It is lightweight, has onboard memory, supports Keychron Launcher, and includes a good cable and an adapter. However, with an 8/10 rating at Robbie's scale, it has some cons that you should consider before buying. On the gaming side Learn about upcoming game releases, Xbox rumors, new hardware, software updates, freebies, deals, discounts, and more. Microsoft finally announced the long-rumored Xbox app launcher for Windows PCs and handhelds. The Xbox app will soon work as a single place for all your games, regardless of their origin, be it Steam, Epic Games Store, Origin, or something else. As of right now, the updated app is being tested in the Xbox Insider Program. Also, Microsoft announced the June 2025 update for Xbox, bringing users unsynced save management, the ability to browse games by publishers, the option to hide system apps on the Dashboard on Xbox consoles, and more. Microsoft finally has its official Xbox-branded VR helmet. However, it is not an entirely Xbox VR per se. It was made in collaboration with Meta, and its stocks are "extremely limited." Sadly, not all Xbox news was positive this week. A new report hit out of the blue, revealing Microsoft's plans to lay off a lot of workers in the Xbox division. Microsoft Flight Simulator received a new city update with upgraded visuals of New York, New Jersey, Massachusetts, and other parts of the state to give you a more realistic experience when flying the sim. City Update 11 is now available on consoles and PCs. Deals and freebies The Epic Games Store is giving away Sable, an interesting-looking exploration game with an open world and a unique art style. If that is not enough, be sure to check out the Steam Summer Sale 2025, which is now in full swing, offering gamers a horde of discounts on various games. More deals are available in this week's edition of Weekend PC Game Deals. Other gaming news includes the following: Senua's Saga: Hellblade II is getting 60 FPS mode, dev commentary, and more. DayZ is getting a desert map with the new Badlands expansion, set to be its biggest yet. Great deals to check Every week, we cover many deals on different hardware and software. The following discounts are still available, so check them out. You might find something you want or need. ASUS NUC 14 Pro+ Core Ultra 9 185H, 32GB RAM, 1TB SSD - $799.99 | 27% off 75" Hisense U7 Series Google Smart TV - $799.99 | 11% off Sony BRAVIA Theater System 6 - $668 | 13% off 6TB WD Blue PC Internal HDD - $99.99 | 17% off 14TB WD Elements Desktop External HDD - $199.99 | 31% off Corsair iCUE 4000D RGB Airflow Mid-Tower Case - $89.99 | 40% off Samsung Galaxy S25+ 512GB - $899 | 20% off This link will take you to other issues of the Microsoft Weekly series. You can also support Neowin by registering a free member account or subscribing for extra member benefits, along with an ad-free tier option. Microsoft Weekly image background by jhenning on Pixabay
  • Recent Achievements

    • Week One Done
      Hartej earned a badge
      Week One Done
    • One Year In
      TsunadeMama earned a badge
      One Year In
    • Week One Done
      shaheen earned a badge
      Week One Done
    • Dedicated
      Cole Multipass earned a badge
      Dedicated
    • Week One Done
      Alexander 001 earned a badge
      Week One Done
  • Popular Contributors

    1. 1
      +primortal
      551
    2. 2
      +FloatingFatMan
      182
    3. 3
      ATLien_0
      169
    4. 4
      Skyfrog
      108
    5. 5
      Som
      106
  • Tell a friend

    Love Neowin? Tell a friend!