According to these links:

http://www.zdnet.com/blog/hardware/cheap-gpus-are-rendering-strong-passwords-useless/13125

and

http://www.pcpro.co.uk/blogs/2011/06/01/how-a-cheap-graphics-card-could-crack-your-password-in-under-a-second/



pretty fuckin scary.

[Edited on June 8, 2011 at 1:17 PM. Reason : .]

6/8/2011 1:17:05 PM

wow

6/8/2011 1:25:31 PM

So you can quickly crack an unsalted MD5 hash of a plaintext password. Not that concerned.

6/8/2011 1:39:45 PM

If it's unsalted, I'll certainly need lots of pepper.

6/8/2011 1:42:21 PM

pretty potent stuff.

6/8/2011 1:56:57 PM

salting is the basic answer here - but there are an incredibly huge contingency of dev's who don't bother to salt their password storage. I know for a fact the content management system here (written before I arrived) does not salt - just a straight MD5.

To me people have too much faith in security by obscurity. I'll admit at times I even suffer from it - half my DVD collection is on a simple password protected directory live on the interwebs. But I'm dang sure not storing something important in there.

6/8/2011 1:57:32 PM

That said, the program does support salted, hashed passwords if you supply the salt. But if the salt is known, why do you need the passwords? You probably have sufficient access to change them yourself.

6/8/2011 2:01:25 PM

So I am completely out of the current (and for that matter, past) security know-how...
But wouldn't this be completely voided by systems that only allow a certain number of log in attempts before lockout?
or even systems that might have a built in wait for each password request (and only allow one request at a time)?

6/8/2011 2:28:04 PM

^ yes

6/8/2011 2:30:28 PM

^^ The idea is that they've already compromised your databases and they've stolen the hashed password values which they'll combine with usernames to attack accounts that recycle usernames and passwords on common sites ranging from Facebook to online banking.

I still think this is non-news. Sure, a GPU can crack the hash for a 7 digit password in 7 hours. You deserve it for having a password that short. That said, salt passwords before hashing them and don't use md5. I like the idea of hashing hashes with different hashing algorithms.

6/8/2011 2:43:03 PM

Quote :

"So I am completely out of the current (and for that matter, past) security know-how... But wouldn't this be completely voided by systems that only allow a certain number of log in attempts before lockout? or even systems that might have a built in wait for each password request (and only allow one request at a time)?"

Quote :

"^ yes"

No.

"These tools operate on the file containing the password hashes, which anyone can access. Since they are only making guesses against the hashes, there are no "failed logins". The only login attempt would be the correct login after they retrieve the correct password."

So technically, the hacker is never attempting to actually "log in". So it would never get ";ocked out".

6/8/2011 2:52:14 PM

Quote :

"but there are an incredibly huge contingency of dev's who don't bother to salt their password storage."

there's a huge contingency of devs who don't even know what salting is


that's why it's so dangerous

6/8/2011 10:07:06 PM

How exactly does a salt work?

my understanding is that it throws random bits in there, but some system has to know which bits to remove, which doesn’t seem like it should be too hard to figure out.

6/8/2011 10:13:00 PM

Quote :

"Not that concerned."

Sounds like if you use 10+ character passwords (upper, lower, number and special) you're still safe right?



Also how does this impact sentence passwords? Something like:

"I'm a big fan of Ruckus"

6/8/2011 10:28:31 PM

^^I mean, it's basically a key to unlock the rest of the password from what I understand of it. The thing is, the salt could be anything... so in essence it's a password to unlock the MD5 encrypted password, if that makes sense. Since MD5 is pretty easy to crack if you've got a rainbow table, they add this extra layer of protection by using the salt to make any rainbow table useless.


here's a good writeup on it:

http://net.tutsplus.com/tutorials/php/understanding-hash-functions-and-keeping-passwords-safe/


^ I too, am a big fan of ruckus. But there's no issues for the GPUs to crack that sort of passphrase. They cover that in the second link.

[Edited on June 8, 2011 at 10:33 PM. Reason : .]

6/8/2011 10:32:42 PM

Long example, but I try to explain salt and rainbow tables in an easy manner

Salting is not too complicated. Here's the problem: There are only a handful of schemes to protect passwords (MD5/SHA, etc). So if you wanted to crack, say, a 5 character password with no salting. Yes, it may take a computer 50 years to do it, but you wouldn't get just the single 5 character password you were looking for - you'd get every possible 5 character password. Take all that information and save it and viola - basic brute force attack.

So the fact that it can generate and check every possible 7 character string in a matter of minutes is scary - because every password (without salt) of 7 characters or less is now compromised on any server not using salt. If you know the hash (say from a database glitch/hack/etc.) you simply look up the password like a giant excel sheet (in simple terms.)

This is where salt comes into play. Lets say you're using a simple MD5. You'd run the MD5, but you'd toss in junk data. For instance you could add the characters "asdf" to a password before running the MD5 - arbitrarily increasing the passwords complexity. Then after the MD5 you take the MD5 string, add "fdsa" to the end of it and MD5 the new string.

In the salted scenario a hacker would have to know the final MD5 hash, and ALL the hash steps in between to backtrack - which would normally mean breaking the security of an operating system (in most cases MUCH more difficult than finding a database vulnerability.) But if you have the admin pass you can see what they're salting with, recreate it, then in minutes convert all those hash strings back into credit card numbers (for example). (((This is where it's really crazy. Before even knowing the salt would take some time to decrypt it into useful data. Now if you have the salt you can sell a million lines from it processing overnight)))

Next you have Rainbow tables - which are basically charts explaining weaknesses in the system (where patterns emerge). Just a really simple example lets say your hashing algorithm generates a "1" for every password that starts with the character "a". So if you salt with "asdf" at the beginning of a password, it would be a tell-tale sign for every hash you store to have a 1 at the beginning. Same idea, much more complex.

6/9/2011 1:46:45 AM

Due to the salting and dehashifying of the lunar wainshaft, GPU floating GIPS can easily override non-salted, perpendicular check-marks. Even if you confirm the silent, bivariable conditions of the previous array, it won't translate into increased security of your hash-sums.

On the topic of security of hash-sums Marzel vein reticulation maybe necessary to prevent murder-cyber-crime.

This thread sounds like people are just making shit up. So here's my take on it.

6/9/2011 6:21:22 AM

Quote :

"Next you have Rainbow tables - which are basically charts explaining weaknesses in the system (where patterns emerge). Just a really simple example lets say your hashing algorithm generates a "1" for every password that starts with the character "a". So if you salt with "asdf" at the beginning of a password, it would be a tell-tale sign for every hash you store to have a 1 at the beginning. Same idea, much more complex."

Is it just me or is this completely wrong?

Hashes, by design, are irreversible. You absolutely wouldn't be able to find a string in a hash that consistently reversed to a certain string in the input. If you could do that, the hash would be garbage and rainbow tables wouldn't be necessary.

Also, you seem to be implying that the salt would be the same for each user. It really shouldn't be.

Here is the best explanation of rainbow tables I've found (and I still had to read it several times): http://kestas.kuliukas.com/RainbowTables/

[Edited on June 9, 2011 at 7:44 AM. Reason : not trying to be a dick]

6/9/2011 7:27:59 AM

Lot of misinformation in this thread.

wwwebsurfer said:

Quote :

"Here's the problem: There are only a handful of schemes to protect passwords (MD5/SHA, etc)."

The MD5 and SHA algorithms are not password-protection algorithms. They are hash functions, which are used to generate short strings based on the content of a message. The intent of a hash is to give the recipient of a message a way to verify that the message has not been tampered with. Practical example: You'll often see MD5 hashes of a file provided along with a download link so that people downloading the file can confirm that they downloaded the correct file and that it was not corrupted during transfer.

However, it's fairly common to see applications store hashes of passwords rather than the password values. This is way, way different than just encrypting the password. It's distributed security through obscurity. The actual password putatively exists in one place—the authenticating user's head—and the application compares its stored hash to the hash value generated from the combination of the user's supplied password value and a secret value known to the application, which is called the salt.

This program does fuck-all if you don't know the salt used to generate the password hash. Even if an attacker managed to get his hands on a data set containing usernames and their associated passwords' hashes, he'd still need to get the salt, which isn't typically stored with the data. It'd have to be the target of a separate attack in most cases, since they tend to be stored in a configuration file or hard-coded into an executable or library.

This program is pretty scary if you have passwords out there that are hashed but unsalted. Is this common? Probably. As seen in this thread, a lot of people assume that hashing is the same as encrypting, and it's not. But even so, an attacker would have to get a data set containing the usernames and password hashes first. This is not a magic bullet that an attacker can use indiscriminately against any ol' application.

EuroTitToss said:

Quote :

"Hashes, by design, are irreversible."

This is not true. It's more like hashes in general aren't designed to be reversible, and that's a very important distinction. A simple hash of a short message can absolutely be reversed using brute force. A trivial example: A hash containing every character used in a message followed by a count of each character's occurrences.

Now, to be fair, that's not a very practical hash. That's the Tao of the thing, that a hash that is not one-way is not a true hash. But that brings up another point: The further a hash deviates from the content of the original message, the more likely you are to generate collisions. A collision in this sense is a value that produces the same hash as another value.

Quote :

"You absolutely wouldn't be able to find a string in a hash that consistently reversed to a certain string in the input."

Absolutely speaking, that is wrong. Practically speaking, you are close enough to correct. But when it comes to collisions, the important thing is that you wouldn't need to consistently reverse the hash.

Let's say I got my hands on a set of unsalted password hashes, and your password was in it. It's conceivable that a program like this might find a colliding value. I could conceivably use the colliding value to log in as you even though I wasn't using your password. That's one of the major weaknesses of relying on hashed passwords, even salted ones. Are collisions likely using MD5 and SHA-1? No, but they're not impossible.

6/9/2011 8:36:47 AM

I was responding to these statements:

Quote :

"Just a really simple example lets say your hashing algorithm generates a "1" for every password that starts with the character "a"."

Quote :

"Rainbow tables - which are basically charts explaining weaknesses in the system"

I didn't think we were quite to the level, conceptually, of talking about collisions.... especially since they seem to be irrelevant to the topic of rainbow tables:

Quote :

"Collisions are the only problem with Rainbow Tables. Ironically collisions are seen as a bad thing for hashing algorithms, but in the case of Rainbow Tables a hashing algorithm which generates collisions fairly regularly will be more secure."

Now a question regarding this:

Quote :

"Even if an attacker managed to get his hands on a data set containing usernames and their associated passwords' hashes, he'd still need to get the salt, which isn't typically stored with the data."

The standard advice is to store user specific salts alongside the hash in the database. Are you disputing that practice? (I'd seriously like to know from a practical standpoint... since, admittedly, I'm pretty clueless and I need to know this shit).

[Edited on June 9, 2011 at 8:53 AM. Reason : afsasfdsaf]

6/9/2011 8:48:17 AM

The salt is the only thing that really makes a hash viable for "encryption." I am totally on-board with using distinct salts for each hash, but storing them in the same location as the hashes they're associated with is just reckless. It's like writing the combination on the back of your lock.

6/9/2011 9:03:39 AM

Where the hell else would you store them? If you have millions of users, you're going to do what exactly? Put a few million salts in a config file?

Anyway, what if that is compromised?

My understanding is that the purpose of the salt is to require you to attack each password separately, not to make an individual password harder to attack.

6/9/2011 9:11:08 AM

That's the whole problem. If you store them in a separate table of data, you're increasing the amount of overhead involved in hashing the supplied password for comparison to the stored hash. It's a classic trade-off.

Salting a password prior to hashing it with a value known only to the application makes it harder and maybe impossible to find a value that will produce the hash, mostly because if you don't know the salt, it won't be practical to test each value until you get one that succeeds.

Salting every password with the same salt prior to hashing it means that once your hashing algorithm is compromised and the salt is known, all passwords become much more vulnerable to attack.

Salting every password with a different salt prior to hashing means that all salts and the hashing algorithm and the hashed passwords need to be known before an attack is feasible. But the whole point of the salt is that it should be known only to the legitimate parties involved in the secure exchange of the message. If you're storing the salt right next to the hash, you're leaving the key in the lock.

6/9/2011 9:16:15 AM

Based on that article, it seems like the most secure method is to use Sha1 hash function with unique salts that pull from database specific values that are not just unique, but unique to the application itself as well. Also, with a cost parameter like PHP blowfish, you can drastically increase the time it takes to brute force a hash. This would require the hacker to create separate and individual rainbow tables for each hash in order to crack anything, which is a waste of time.

6/9/2011 10:00:43 AM

Quote :

"But the whole point of the salt is that it should be known only to the legitimate parties involved in the secure exchange of the message. If you're storing the salt right next to the hash, you're leaving the key in the lock."

The casual observer should note that this is not a typical view. Every single thing I've read on salts says they are not meant to be secret. You may very well have a hidden insight into this issue, but I'm not quite getting your point.

Having distinct but known salts means you still need to do a brute force attack (the salt has already made an attack with a rainbow table of any feasible size impossible). So let's say you've brute forced your way into the plaintext.

What difference does it make if the salt happens to be secret? If the I find the plain text to be "passwordsalt", I know some subset of that is the actual password. It's not going to take a miracle to figure it out.

6/9/2011 10:03:12 AM

If the salt is secret—if you don't even know whether there is a salt, let alone its length, let alone its value—it's that much harder to plan and execute your attack.

To use your example, let's say you map the hashed password to the plaintext "passwordsalt." If you know the salt was "salt," then you know the password is "password." But what if the salt were actually "rdsa"?

[Edited on June 9, 2011 at 10:14 AM. Reason : subjunctive]

6/9/2011 10:14:02 AM

Maybe I wasn't clear. In my example, all the lengths and values are unknown. Let's take your example of "rdsa."

I've found a plaintext of abcdefgrsda. I'm just 5 attempts away from figuring out the password by actually trying to log in with it. Hell, if it was an english phrase, the actual password would be immediately obvious.

And unless your salt lengths are random too, once I figure out one password, the length presents no further difficulty.

[Edited on June 9, 2011 at 10:24 AM. Reason : asdfasdf]

6/9/2011 10:23:08 AM

geez this thread blew up this morning.

First, "protect passwords" is not the same as "password-protect". Everyone I know uses hashing functions so we're not storing passwords as plain text. Encryption, well honestly, would take more code that doesn't really provide appreciable benefit.

Also, I've never heard of someone trying to use individual salt for every user. That's a crazy amount of overhead

good thread though

6/9/2011 10:38:27 AM

Forgive my probably simplistic view of this issue. But it seems like a single value salt is useless if you've brute forced the plaintext, as noted above. So if no one uses individual salts per user, due to overhead--and if it is uncommon to obscure the salt/store it separately from the hashes, due to (3. ??? 4. Profit)--what good does the salt actually do? Sure, it makes the password longer, so you have to generate more values to find the match (or a collision). But it seems like the whole point of these articles is that password length is providing diminishing returns, even on strong passwords, with the advent of these GPU-based crackers.

Or perhaps I'm missing something entirely. I mean, I took a Network Security course once, but I notably did not pass it.

6/9/2011 11:20:32 AM

Quote :

"Also, I've never heard of someone trying to use individual salt for every user. That's a crazy amount of overhead "

Individual salts is talked about and demonstrated in this link that kiljadn posted.

http://net.tutsplus.com/tutorials/php/understanding-hash-functions-and-keeping-passwords-safe/

I'm sensing a lot of misinformation in this thread too.

This is how I understand it after reading the above link:

A Rainbow table is a table of hashed known passwords used to find collisions between unknown hashed passwords.

If you straight hash your passwords, and the hacker knows the hash you used, then they can use a fast computer and program to create a rainbow table from a dictionary using your single hash and then look for matches with the unknown password hashes.

If you use a salt, then the rainbow table is basically invalid because they are comparing hashed passwords to hashed passwords plus a salt. However, if you use the same salt for every password and the hacker discovers what the salt is, then all they have to do is recreate the rainbow table with the salt and then compare.

If you use a unique salt for each password, then the hacker would have to create a rainbow table for each password using that password's salt. This means that an individual password is not any more secure using a random salt as using a regular salt, or even using no salt, because the rainbow table would still have the same number of entries for that one password. However, using a unique salt per password makes your database as a whole more secure than if you used a single salt because the hacker can not use a single rainbow table against all the passwords anymore. With a single salt, they can take the time to generate one rainbow table and then use that one table to find many passwords. With unique salts, they have to take the time to generate a new rainbow table per password.

If you are thinking like a hacker, they are usually looking for breaking a large amount of passwords either for sale or for using to test against other sites. If they come across your data and find they can spend X time to get Y passwords, then they might go for it (no salt or single salt), but if they have to spend X*Y time to get Y passwords (unique salts), they will probably skip this data and move on to another site.

The idea is that you actually want some overhead of unique salts to prevent brute force attacks on your site, or rainbow tables if they just have your list of data. This goes along with having overhead when a user logs in, but you aren't necessarily verifying the password on every request. So on your site, you have the overhead once per session, but an attacker would have that overhead for every brute force attempt, which will slow them down and make them move on.

[Edited on June 9, 2011 at 11:31 AM. Reason : .]

6/9/2011 11:27:59 AM

^I think the point being made is not just to the users, but more to the programmers. We/They need to make sure we're taking adequate steps to store this information safely.

In the case of individual salts (if I was to implement it) I would store the salt information on a different server, and program the firewall to only allow access to and fro to the separate server over an encrypted connection. That would at least reduce the probability of everything being stolen.

In every system I've seen the salt is programmed directly into a process. So you just pass the password to the process and it regurgitates a hash - the hundreds/thousands/however many steps in the process are all contained within the process. To get them you'd either need the source code (only on a dev machine) or get an accurate enough decompile of the process to see whats going on.

Most hashing functions have some kind of reducing function already or can be pretty easily written. You just loop hashing, reducing, and salting until you're satisfied it's at least extremely hard to crack.

6/9/2011 11:40:10 AM

lots of sense and good info ITT. I think I have learned a lot about MD5.

6/9/2011 12:01:21 PM

EuroTitToss said:

Quote :

"And unless your salt lengths are random too, once I figure out one password, the length presents no further difficulty."

That's a good idea. Salt lengths could easily be random. You could procedurally generate a nearly unique salt for every actual password value supplied by a user based on the password itself. You wouldn't even need to store them shits!

6/9/2011 12:58:51 PM

Just like with any "secure" technology, we can make our system's secure enough to be more difficult than another target, hence making it "relatively secure" in an every changing hacker's paradise. If someone wants to take 7 years to bust in, they may be able to even with the previous scenario I outlined, but by that time, the tech will have moved on, making your system... not impossible to penetrate, but undesirable, and thus secure by current standards. Any attempt to make a technology secure, consequently opens the doorway to reverse engineer it to be penetrated.

[Edited on June 9, 2011 at 1:16 PM. Reason : -]

6/9/2011 1:13:31 PM

I really suggest ya'll read this: http://kestas.kuliukas.com/RainbowTables/

I keep hearing people ITT suggest that, if you were forced to, you would generate a rainbow table per password. I really don't think this makes any sense.

You only generate a rainbow table because you think you'll be able to use it multiple times. Generating a table once offers no advantage that I can see over a simple brute force attack. And in fact, the table isn't guaranteed to contain all plaintexts. If you were trying to break just one password, you would probably just brute force it.

Also, unique salts per user aren't a lot of overhead... they're probably smaller than the resulting hash. It's my understanding that unique salts are a widespread practice.

[Edited on June 9, 2011 at 6:46 PM. Reason : asfasdfasdf]

6/9/2011 6:43:39 PM

Quote :

"I keep hearing people ITT suggest that, if you were forced to, you would generate a rainbow table per password. I really don't think this makes any sense. You only generate a rainbow table because you think you'll be able to use it multiple times. Generating a table once offers no advantage that I can see over a simple brute force attack. And in fact, the table isn't guaranteed to contain all plaintexts. If you were trying to break just one password, you would probably just brute force it."

That's my point above. If you use random salts, then a hacker would have to use a rainbow table per password, which they aren't going to do. They are going to find another method.

Another method is brute force. Using an algorithm, like blowfish in PHP with a cost factor, you can slow down the brute force attack in the application and make it an unfeasible method as well.

Basically what I said above is that if you just hash or hash with a single salt, then rainbow tables can be used against your data. Unique salts makes rainbow tables unreasonable for a hacker to use.

Oh, and that link you posted made rainbow tables more confusing. It seems like that page is trying to explain a way to use rainbow tables to obscure passwords rather than using rainbow tables to crack passwords.

This link was much more to the point about hashing in general and explains the reasoning behind a simple MD5 hash all the way up to PHP blowfish with a cost factor and random salts
http://net.tutsplus.com/tutorials/php/understanding-hash-functions-and-keeping-passwords-safe/

[Edited on June 9, 2011 at 8:08 PM. Reason : .]

6/9/2011 8:06:38 PM

Quote :

"Oh, and that link you posted made rainbow tables more confusing. It seems like that page is trying to explain a way to use rainbow tables to obscure passwords rather than using rainbow tables to crack passwords."

Then you missed the point. The article is the absolute best and simplest explanation I've seen of what a rainbow table actually is. Everyone else just keeps saying it's a table with all possible hashes for a certain password space.... which is just not true.

I think the link you posted is probably plenty of info from a practical viewpoint. Realistically you don't need to know the inner workings of an attack to prevent against it. But what frustrates me is blindly following something without knowing why it works.

[Edited on June 9, 2011 at 8:33 PM. Reason : ps]

6/9/2011 8:29:24 PM

Btw, another option for enhanced security is to let the user set their own salt.

IE: User, at account creation time creates a password, but also sets a pin number. The password is hashed and salted with the pin number. Now there's no way to ever figure out the hash since the salt is secret and unstored.

You'll find some financial institutions using this today.

Another option is to use an algorithm of subsets of a user's information as the salt. IE: Their first name, signup date, address, sex etc. Using pieces of multiple bits of personal data would generate randomized and unique salts for every user.

Then to unwind the salts, a hacker would have to compromise the codebase and reverse engineer the code itself, then rebuild the entire user profile db, then write their own code to unwind the hash.

6/9/2011 11:11:37 PM

Quote :

"Another option is to use an algorithm of subsets of a user's information as the salt. IE: Their first name, signup date, address, sex etc. Using pieces of multiple bits of personal data would generate randomized and unique salts for every user."

This is sort of what I do in order to generate a dynamic salt, for pretty much the reasons you listed right below it.

In order to do anything outside of brute forcing, the hacker would have to get into my database and the code, which is (theoretically) a whole lot tougher than just getting access to the database.

6/10/2011 12:10:03 AM

I may not have the strongest password in the world, but it is safe from chinese hackers. it's just a series of 8 L's.

[Edited on June 10, 2011 at 7:23 AM. Reason : .]

6/10/2011 7:23:23 AM

That's Japan.

6/10/2011 9:02:24 AM

I'd argue it's both(watch the end of A Christmas Story --chinese restaurant scene for example).

[Edited on June 10, 2011 at 9:40 AM. Reason : my chinese coworkers can't do Ls either. ]

[Edited on June 10, 2011 at 10:04 AM. Reason : http://youtu.be/xTq20prt0K8]

6/10/2011 9:40:05 AM

I think we both know I'm not watching A Christmas Story

6/10/2011 9:48:39 AM

So does this have anything to do with these stories ya think?

Codemasters hacked: http://games.ign.com/articles/117/1175310p1.html

Epic games hacked: http://pc.ign.com/articles/117/1175351p1.html

two major gaming companies hacked the same day, soon after this info came out.

6/10/2011 9:15:50 PM

wonder why they're targeting video game entities...

6/11/2011 1:34:30 AM

for the lulz

Or corporate espionage

Or china

Big companies have been getting hit hard lately...lockheed martin was assaulted recently, though nothing was gotten out

6/11/2011 9:45:31 AM

so they say publicly anyway

6/11/2011 10:52:25 PM

Shouldn't they have a time limit put in place after a wrong password? It should double in time after each incorrect entry. It'll eliminate cracking.

6/18/2011 4:46:25 PM

1. all that would do is frustrate users who mistype their passwords


2. people cracking passwords generally don't brute force attempts on the login. which was discussed in this very thread if you had bothered to read it

6/18/2011 4:50:17 PM

set 'em up

6/18/2011 6:58:14 PM