Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

MD5crypt Password Scrambler Is No Longer Considered Safe

timothy posted more than 2 years ago | from the risky-busy-ness dept.

Security 212

As reported here recently, millions of LinkedIn password hashes have been leaked online. An anonymous reader writes "Now, Poul-Henning Kamp a developer known for work on various projects and the author of the md5crypt password scrambler asks everybody to migrate to a stronger password scrambler without undue delay. From the blog post: 'New research has shown that it can be run at a rate close to 1 million checks per second on COTS GPU hardware, which means that it is as prone to brute-force attacks as the DES based UNIX crypt was back in 1995: Any 8 character password can be found in a couple of days. The default algorithm for storing password hashes in /etc/shadow is MD5. RHEL / CentOS / FreeBSD user can migrate to SHA-512 hashing algorithms.'" Reader Curseyoukhan was one of several to also point out that dating site eHarmony got the same treatment as LinkedIn. Update: 06/07 20:13 GMT by T : An anonymous reader adds a snippet from Help Net Security, too: "Last.fm has piped up to warn about a leak of their own users' passwords. Users who have logged in to the site were greeted today by a warning asking them to change their password while the site investigates a security problem. Following the offered link to learn more, they landed on another page with another warning."

Sorry! There are no comments related to the filter you selected.

In other news (4, Informative)

colin_faber (1083673) | more than 2 years ago | (#40245123)

rot13 isn't safe either.

Re:In other news (5, Funny)

Anonymous Coward | more than 2 years ago | (#40245233)

That's why I use rot26. It's twice as strong.

Re:In other news (0)

Anonymous Coward | more than 2 years ago | (#40245263)

That's why I use rot26!

Re:In other news (0)

Anonymous Coward | more than 2 years ago | (#40246333)

That's why I use rot26!

Don't use that tired old shit! Quad-ROT13 is definitely the way to go!

Dammit! (4, Funny)

ThatsNotPudding (1045640) | more than 2 years ago | (#40246793)

rot13 isn't safe either.

Who told you my password?

Are you sure SHA-1+salt is enough for passwords? (4, Informative)

anared (2599669) | more than 2 years ago | (#40245145)

Good info about storing passwords properly: http://www.f-secure.com/weblog/archives/00002095.html [f-secure.com]

Re:Are you sure SHA-1+salt is enough for passwords (4, Interesting)

Anonymous Coward | more than 2 years ago | (#40245339)

SHA-1 is not sufficient, but the summary refers to SHA-512, which is in the SHA-2 set [wikipedia.org] . Now whether SHA-2 is sufficent, or if developers should be migrating to something like bcrypt [wikipedia.org] or SRP [wikipedia.org] is a bigger conversation.

In any case, while I would never tell someone to use MD5, the lack of a salt is much more egregious and made the leak much worse than it had to be.

Re:Are you sure SHA-1+salt is enough for passwords (5, Informative)

TheLink (130905) | more than 2 years ago | (#40246891)

I think the problem is overhyped. If you're an online site and some hacker already has the hashes and salts of user passwords to bruteforce, you're typically already so pwned it doesn't matter if you are using SHA2048 or whatever.

For the same reason it doesn't matter that much even if I use 8 character passwords for noncritical online sites. I'd be flattered if the attackers are going to DDoS the site just to crack my password via the site's login page! If the site is famous enough I might even have enough warning to switch to a longer password when the DDoS attack hits the news ;).

Whereas if they are bruteforcing my password offline - it means the site has already been compromised. And they are likely to be able to access the rest of my data in that site, possibly do actions using my account and perhaps with a bit more effort get the plaintext of my password the next time I log in.

So use different passwords for different sites, don't use passwords that are too short or obvious that they can be bruteforced online, but don't sweat making them super long unless its important or you're paranoid- since the site is more likely to get pwned before they bruteforce it online.

Getting pwned or compromised isn't a rare thing. I've signed up for different stuff using unique email addresses, and I've noticed spam coming to a few of those addresses. Maybe one day I'll have to create new slashdot/facebook/etc accounts when my current ones get pwned. Big deal.

For "offline" stuff like GPG, truecrypt, yes please do use strong and long passphrases.

Re:Are you sure SHA-1+salt is enough for passwords (3, Interesting)

PhrostyMcByte (589271) | more than 2 years ago | (#40246061)

Algorithms designed to burn CPU, like PBKDF2 recommended in the article, are great if used correctly.

The important thing to remember is that you want to make the client burn CPU, NOT the server. If you let the client trivially initiate 10 http requests that cause a server's CPU to peg for 1 second each, you've created a nice DoS vector.

Are there any existing Javascript crypto libraries that safely offload this work to the client?

Re:Are you sure SHA-1+salt is enough for passwords (5, Informative)

w_dragon (1802458) | more than 2 years ago | (#40246427)

The issue with doing the hash client-side is that now the hash has become the password. If someone steals the list of hashes it's game over, they can just emulate the client sending the hash and the server won't know that they didn't start from the password and perform a hash. The hash must be done server-side.

Re:Are you sure SHA-1+salt is enough for passwords (2)

mlts (1038732) | more than 2 years ago | (#40246571)

I've been playing with a dedicated hash database that is on its own server, so hosts bounce a request off this appliance and get a "yes", "no", or "timeout". Too many "no"s in too short a time make the hash validation appliance refuse to give any answers for a period of time.

If done correctly, for someone to get the hash database, they would have to find a way to physically get access to the appliance, then dump the box. It isn't perfect (which is why a better algorithm like bcrypt should be used to store hashes), but having a layer of security whose sole purpose is to keep the list of hashes out of the hands of the blackhats means that after a breach is rectified, users are not forced to change all their passwords (unless their accounts were directly involved).

Re:Are you sure SHA-1+salt is enough for passwords (1)

Anonymous Coward | more than 2 years ago | (#40246619)

So one could trivially deny service to all of your users by bouncing a bunch of bogus login attempts off your front end?

Re:it is about compute speed, not hash strength (1)

Anonymous Coward | more than 2 years ago | (#40246371)

The argument is that "we can do 1 million hashes in one second on a GPU, thus we can perform a dictionary attack in just a few days." It is an argument about execution speed versus size of the dictionary. The size of the dictionary is limited by the human brain, and is not going to change any time soon. The execution speed is expected to decrease as a function of Moore's law, GPU, etc. The solution cannot be to move to SHA1, or even SHA256, because these algorithms don't take much longer to run than MD-5. They can't, because they are used in scenarios where servers have to process millions of messages.

The solution is probably to do something special for password storage. Use salt of course. But also do something like "run SH-xxx N times" where N is a number that grows larger as Moore's law progresses.

What about Debian? (2, Interesting)

Anonymous Coward | more than 2 years ago | (#40245159)

"... RHEL / CentOS / FreeBSD user can migrate to SHA-512 hashing algorithms."

That's fine and dandy and all, but what about King Shit Debian? Pretty much all of my systems run something Debian-based in one form or another. Is this a simple change for Debian users too?

Re:What about Debian? (5, Informative)

slim (1652) | more than 2 years ago | (#40245277)

The default in Debian is sha512.

Confirm by looking in /etc/pam.d/common-password

password [success=1 default=ignore] pam_unix.so obscure sha512

'obscure' enables those annoying checks on password quality. 'sha512' is the hash type.

Re:What about Debian? (1)

buchner.johannes (1139593) | more than 2 years ago | (#40245615)

pam has always been a mystery to me. Similar to where in Linux the code is that handles switching between TTYs (Ctrl-Alt-Fn).

Re:What about Debian? (0)

Anonymous Coward | more than 2 years ago | (#40245895)

The way sysadmins use things without understanding them is rather horrifying.

Re:What about Debian? (0)

Anonymous Coward | more than 2 years ago | (#40246475)

Welcome to real life, enjoy your stay. Everything you do must be horrifying.

Re:What about Debian? (1)

Vairon (17314) | more than 2 years ago | (#40246261)

pam has always been a mystery to me. Similar to where in Linux the code is that handles switching between TTYs (Ctrl-Alt-Fn).

Looking through the code it appears to be linux/drivers/tty/vt/keyboard.c and linux/drivers/tty/vt/vt.c

Re:What about Debian? (2)

Qzukk (229616) | more than 2 years ago | (#40245327)

My /etc/shadow on Debian 6.0 uses $6$ hashes (SHA-512) by default. Upgrading from an earlier debian will use the newer hash the next time you change your password.

I think it is sufficient. (0)

lixns21 (1887442) | more than 2 years ago | (#40245167)

I have been trying since 1995 and have still not broken in on my Pentium P6

2004 called they want their news back! (0)

godrik (1287354) | more than 2 years ago | (#40245217)

Seriously slashdot?

MD5 has questionned since 1996 and a strong attack on it was realized in 2004. It broke apart since. Nobody serious about security should still be using MD5 now.

Just read the second chapter of wikipedia on MD5 http://en.wikipedia.org/wiki/MD5 [wikipedia.org]

Re:2004 called they want their news back! (0)

reub2000 (705806) | more than 2 years ago | (#40245289)

This isn't an attack on the hash function. This is a dictionary attack which has been known about for even longer than that.

Re:2004 called they want their news back! (4, Insightful)

Anrego (830717) | more than 2 years ago | (#40245373)

Indeed.

The effort to use a more secure hash is generally trivial, but there's still going to be a lot of people who either know and don't, or don't know.

For the first category, nothing you can do about it. Same people running wep on their wifi. They either don't see anyone ever attacking them, are tied in due to old systems, or don't care.

For the second category, stuff like this may help. I think at this point most people know md5 isn't as secure as once considered, but I don't think people realize just how insecure it is becoming. In peoples minds it's still in the "theoretically if someone was really dedicated they could break it" stage.. whereas it's actually entering into the "feasible to do it on large scale" stage. Breaking that perception might speed things along.

Re:2004 called they want their news back! (1)

amicusNYCL (1538833) | more than 2 years ago | (#40246585)

I think at this point most people know md5 isn't as secure as once considered, but I don't think people realize just how insecure it is becoming.

Why not? Are they not paying attention? This is a quote from TFA:

In 2004, researchers revealed a number of weaknesses in regularly-used hash functions. Later in 2005, MD5 was declared “broken” by security expert Bruce Schneier.

I remember reading that back in 2005 (7 years ago!) and not being surprised. I mean, what the hell people? Who in 2012 is using MD5 for new systems thinking that it's "good enough"? It hasn't been "good enough" since SHA-1 came out in 1995. I mean, all other things being equal, MD5 results in a hash that is 128 bits, a SHA-1 hash is 160 bits. The hash space is larger for SHA-1, so why would anyone be using MD5 for anything at all, even CRC checks? Not even SHA-1 is good enough any more, so again, why would anyone think MD5 is fine to use? I just don't get it, if people in 2012 still think that MD5 is appropriate to use in any circumstance then they'll never learn.

Re:2004 called they want their news back! (1)

amicusNYCL (1538833) | more than 2 years ago | (#40246615)

I thought of this just as I hit the post button, but I would LOVE to see PHP deprecate and outright remove the MD5 function. Maybe copy-paste programmers will start paying attention at that point. If it breaks software, well, that software was already broken. PHP is just requiring that you fix it now.

Wishful thinking...

Re:2004 called they want their news back! (2)

buchner.johannes (1139593) | more than 2 years ago | (#40245777)

You have to distinguish two cases:
  a) Collisions of hashes -- two documents have the same hash, and you can alter a document, but it will still have the same hash.
  b) The hashing algorithm is insecure (not one-directional) for passwords, i.e. you can reconstruct the original password.

If the algorithm is susceptible to a), as were the attacks you mention, this does not mean anything for the password security! You don't want to create an alternate password that has the same hash as the password you already have. Additionally, you have length limitations with passwords you do not have for collisions.

Of course, susceptibility of hash algorithms to a) and b) is weakly correlated, but just because people understand the algorithm better.

Specifically, what are the drawbacks of storing md5 hashed password? Except for rainbow tables that can be produced for any algorithm and are evaded by salts.

I wouldn't choose MD5 for designing a new system, but I think understanding the difference is important. This has some similarity to using ridiculous key lengths for public-key encryption.

The article is arguing that MD5 and SHA1 are just to fast to compute rainbow-tables once the attacker has the salt, and algorithms that require more computations should be preferred. Should thus PBKDF2 be chosen for hashing documents? No, because a) and b) are different problems with different requirements.

Re:2004 called they want their news back! (1)

godrik (1287354) | more than 2 years ago | (#40246255)

Once you can solve problem a). Problem b) will follow soon. Notice that for many case, you might not need to recover the password. Any password that generate the same hash will do.

If the MD5 encoded /ec/shadows of your system leaks. Solving problem a) allows me to log onto the system. That is a security problem. A lesser one than leaking the password itself but it is still a problem. Passwords need to be changed.

With a strong hashing function, you'll post your /etc/shadow on the web and still sleep like a baby at night.

Re:2004 called they want their news back! (1)

Junta (36770) | more than 2 years ago | (#40246879)

b) differs from a) in common practice in that you must find data+determined salt=hash. If your collision doesn't end in the salt, it's useless in that application.

Unsalted hashes are worse. (4, Interesting)

mbone (558574) | more than 2 years ago | (#40245221)

It astounds me that Linkedin and eHarmony used unsalted password hashes. That's much worse than using md5 (and, yes, you shouldn't use md5, but, still, first things first).

From the Linkedin Press Release :

The passwords are stored as unsalted SHA-1 hashes,

Come on, guys, get up to at least 1978 [bell-labs.com] in your security policy.

Re:Unsalted hashes are worse. (2)

Atzanteol (99067) | more than 2 years ago | (#40245417)

Salt isn't magic. If they stole your database they likely would get the salt and hash values (unless it is stored elsewhere and the hackers were unlucky). It will stop rainbow table attacks to be sure, but not brute force. At best (the hackers didn't get the salts) it will slow down brute force.

Re:Unsalted hashes are worse. (2)

CanEHdian (1098955) | more than 2 years ago | (#40245533)

Salt isn't magic. If they stole your database they likely would get the salt and hash values (unless it is stored elsewhere and the hackers were unlucky). It will stop rainbow table attacks to be sure, but not brute force. At best (the hackers didn't get the salts) it will slow down brute force.

Without having the salts, it is brute force. With the salts, dictionary-attacks are -as evidenced by the 'weakest/stupidest/etc. LinkedIn passwords' stores- quite effective. It is also true that LeakedIn is having people try out their old passwords; what if they or a site like that keeps a log of all these passwords to add to the existing dictionaries?

Re:Unsalted hashes are worse. (1)

berashith (222128) | more than 2 years ago | (#40245913)

i saw the leaked-in page and my paranoid response went through the roof. Why the hell would I just type my password into that page? I went to a page that could provide a hash of my password in a different browser, made sure I wasnt logged in to anything ( hoping no cookies would link stuff around ) , and then tried the hash in leaked-in. I wasnt on the list. I still made sure that linked-in does not have a password for me that is on anything else.

Re:Unsalted hashes are worse. (5, Informative)

CaptainJeff (731782) | more than 2 years ago | (#40245545)

It will slow down brute force **for a particular password**. That's the key. If you don't use salt, you can brute force all you want and, for each attempt, check to see if that result is there for ANY of the passwords. If you use salt, since you would be using different salt for each password (or...you should be!), then you need to brute force each password individually.

Re:Unsalted hashes are worse. (0)

Anonymous Coward | more than 2 years ago | (#40246243)

Yes, that's what he said. It takes longer, because each password takes longer, because the passwords are longer.

In practice, you just brute force and, yes, check each result for ANY of the passwords. If they're salted, it takes longer, because you'll only find 1 password at a time. Unless they're all salted with the same salt.

Re:Unsalted hashes are worse. (0)

Anonymous Coward | more than 2 years ago | (#40245553)

There is a huge difference between days to crack each password hash, and a few milliseconds to use a pre-computed rainbow table to crack each hash.

Magic? Depends on how you view, 6M passwords cracked within a few hours, or two passwords cracked within a few days.

Hell, *nix has used salted pwords since the 70s. I think only M$ windows, and some crappy webapps allow (essentially) real-time cracking of pwords.

Can't wait for Google to get hacked. If you use directory sync with google apps, you have to use plain-text passwords or unsalted SHA-1. Good times.

Re:Unsalted hashes are worse. (3, Insightful)

bugg (65930) | more than 2 years ago | (#40245683)

Yes, but slowing down a brute force attacker by a factor of the cardinality of the set of unique salts will almost certainly be a huge win, especially if the salts chosen are long enough where salt-collisions are rare to nonexistent. 6.5 million accounts were compromised; requiring someone to have 6.5 million times as much compute resources to compromise all passwords is nothing to sneeze at.

Of course, salts don't help you in the case where a well determined attacker isn't after 6.5 million accounts but rather just one specific account, but that's not what they are intended to help with.

Re:Unsalted hashes are worse. (2)

tlhIngan (30335) | more than 2 years ago | (#40246429)

Yes, but slowing down a brute force attacker by a factor of the cardinality of the set of unique salts will almost certainly be a huge win, especially if the salts chosen are long enough where salt-collisions are rare to nonexistent. 6.5 million accounts were compromised; requiring someone to have 6.5 million times as much compute resources to compromise all passwords is nothing to sneeze at.

Of course, salts don't help you in the case where a well determined attacker isn't after 6.5 million accounts but rather just one specific account, but that's not what they are intended to help with.

I've wondered - would hashing the username and using hte hash as the salt be "good enough"? The other alternative is well, just use a unique identifier for the salt so they're all different... (e.g., a 32-bit counter should be sufficient for most cases as chances are high that you aren't targeting the entire world population with your service...).

Re:Unsalted hashes are worse. (1)

Bengie (1121981) | more than 2 years ago | (#40245849)

We don't care about brute force, only rainbow tables. If your password is bruteforceable, that's your fault.

Re:Unsalted hashes are worse. (0)

Anonymous Coward | more than 2 years ago | (#40246153)

A hardened salt methodology can still be secure.

Salt is magic (1)

Junta (36770) | more than 2 years ago | (#40246907)

Salt means rainbow tables become impractical. Salt also means a collision attack is also mitigated. Salt is not expected to be any more secret than hash, it just changes tho way it works.

Re:Unsalted hashes are worse. (0)

Anonymous Coward | more than 2 years ago | (#40245489)

The thing is that some types of authentication don't work without both sides knowing the plain-text password. In these types of authentication you can actually confirm that the user knows the password without it ever being sent over the network. For example, you could Diffie-Hellman exchange a one-time salt and transmit the hash of the password concatenated with that salt. Even if you could intercept the transmission, you wouldn't be able to get a useful hash from which to decrypt the password.

Re:Unsalted hashes are worse. (1)

Score Whore (32328) | more than 2 years ago | (#40246659)

Of course that means that you have the unencrypted password on the server side in order to compute the one-time salt+word concatenation. Not good practice.

Re:Unsalted hashes are worse. (1)

Artraze (600366) | more than 2 years ago | (#40245563)

Salt is only for preventing dictionary based attacks, while this article is talking about brute force attacks. Now, we if suppose an attacker, for some bizarre reason, couldn't collect the salt value(s) alongside the password hashes the salting might increase the difficulty of brute forcing the passwords, but that situation is highly unrealistic.

Re:Unsalted hashes are worse. (1)

Anonymous Coward | more than 2 years ago | (#40245639)

Yes, but it makes it you have to bruteforce every hash separately. Thus lengthening the time a lot. Without salts, you can bruteforce 1 hash and know all the password that are the same.

Re:Unsalted hashes are worse. (1)

JasterBobaMereel (1102861) | more than 2 years ago | (#40246123)

If someone has been able to steal the hashed passwords, then how long it takes to decrypt them is academic ...

They have access to your server already, customers passwords are the least of your worries ...

Re:Unsalted hashes are worse. (2, Insightful)

Anonymous Coward | more than 2 years ago | (#40246747)

Not really. Password reuse is so ubiquitous that cracking those hashes is still worth something. If someone has the same password on FooBar.com as they have at their bank, or on Facebook, or on $PICK_YOUR_POISON, cracking the hash at FooBar.com just gave the attacker the keys to something a lot more useful.

Hell, it's so widespread that attacking little piss-ant sites is worth it specifically to get a bunch of passwords to try elsewhere. At that point, the fact that your server's been pwnt is the least of anyone's problems...

Brute-force was solved decades ago. (0, Troll)

Beardo the Bearded (321478) | more than 2 years ago | (#40245255)

Brute-force was solved decades ago. The local free-net here had a simple solution:

If you get your password wrong, you can't try again for 1 second. Every failure doubles the time required to try again.

Why doesn't everyone do that?

Re:Brute-force was solved decades ago. (2, Insightful)

Anonymous Coward | more than 2 years ago | (#40245301)

So, if someone steals your database full of hashed passwords, you just call them up and ask them nicely to slow down their brute force?

Re:Brute-force was solved decades ago. (4, Insightful)

slim (1652) | more than 2 years ago | (#40245311)

If you get your password wrong, you can't try again for 1 second. Every failure doubles the time required to try again.

Why doesn't everyone do that?

It doesn't help if your attacker has got hold of the list of hashes.

1. Steal hashes
2. Brute-force on your own system/cloud/botnet/whatever
3. Use password

Re:Brute-force was solved decades ago. (1, Insightful)

Anonymous Coward | more than 2 years ago | (#40245319)

The problem is if the hashed password database is recovered (as in LinkedIn). Then you can run hashes as fast as you want to.

For instance, the SHA-1 hash of "password1" is e38ad214943daad1d64c102faec29de4afe9da3d -- you cannot reverse "e38ad214943daad1d64c102faec29de4afe9da3d" to get "password1", but you can guess things until you get "e38ad214943daad1d64c102faec29de4afe9da3d" and then you know that my password is "password1".

Re:Brute-force was solved decades ago. (0)

BagOBones (574735) | more than 2 years ago | (#40245345)

That is external application brute force, in this case the attacker simply broke in and copied the list of hashes given them unlimited time to try and match them to known passwords.

Re:Brute-force was solved decades ago. (0)

jeffasselin (566598) | more than 2 years ago | (#40245361)

Doesn't help if someone grabs the hash table, like in this case.

Re:Brute-force was solved decades ago. (3, Insightful)

Qzukk (229616) | more than 2 years ago | (#40245365)

Why doesn't everyone do that?

Because whoever downloaded the database of hashes will probably ignore your request that they only check one password per second.

Re:Brute-force was solved decades ago. (-1)

Anonymous Coward | more than 2 years ago | (#40245909)

Because this is about attacking the hash itself and not the machine?

Re:Brute-force was solved decades ago. (4, Interesting)

bussdriver (620565) | more than 2 years ago | (#40246369)

1) server + http is stateless; it is not trivial to delay attempts every second. You would have to maintain a database of accounts and failure timestamps. On occasion, you'd have to scrub that database too. Not difficult to implement but I suspect few do. Busy distributed sites have more complications as this database may need to be in sync between servers; creating a possible bottleneck and another attack vector.

2) An attack on 100s of accounts could rotate between accounts to get around the time limit. So now you are storing a short history in that database; or tracking an IP address but not being too aggressive with the IP due to NAT users... and bot nets do not have as much trouble getting IP addresses.

3) Security holes. Some simple little add on to your website written in PHP just compromised your password database. The server may still be "secure" but the data could leak out and you may never know about it. Your password hashes are now on the internet with ZERO time delay between password attempts and any method known to man can be employed in parallel against those password hashes. Many people use the SAME password for all their accounts so one can be motivated to crack them even everybody later changes their passwords they probably keep the old ones in use elsewhere.

4) Some users have EMAIL ADDRESSES for account names it becomes easy to find that person again. Also, identification information may leak as well. Some sites produce different errors for unknown account names so then you know they have an account - especially if the account name is an email address. Even with a 1 second delay, I can quickly (in parallel) check a huge list of email addresses to see who has accounts with XXX with animals and kids .com. In addition, one has enough to send phishing emails...

5) Lost password questions. These questions are usually pathetic and tolerant of variations on input. This provides an easier password to crack probably without as much protection. 1 second delay will do nothing against "What is your mother's maiden name?"

So:
Learn something from DES, MD5 and soon SHA -- use bcrypt hashing!
Keep a timestamp database to filter out simple attacks and identify accounts under attack and log more data.
Do not use emails for account names. Encrypt identification (emails) in the database; store the keys outside the database's reach.
Forbid stupid passwords. Probably BAD to have secure questions at all.
Do not mindlessly ban the use of autocomplete since it allows many of us to generate long random passwords. Do not limit the length of passwords or the characters used; too many sites are overly restrictive.
Do not output errors that leak information.

Re:Brute-force was solved decades ago. (1)

mlts (1038732) | more than 2 years ago | (#40246701)

It is an easy way to go, but what I saw people do is log in just to make sure a legit user would be locked out.

Some old IBM systems would lock a user account indefinitely after 3-5 wrong guesses. So, what people would do for petty revenge is just type in the user name of someone they don't like, type in some wrong guesses, and that person's account is locked out until the next weekday when the IT staff comes in.

Instead, there needs to be multiple levels of lockout to prevent brute force guessing. The lowest level would be at the hash database server, where it would allow 10-20 wrong guesses before it would block access for 1-2 minutes (good enough to slow down brute force dictionary attacks, but not so long that it means a legit user is locked out forever.) From there, the app server would lock out access via IP ranges, say 15 minutes if there were 3+ guesses wrong. This way, if someone was coming from one IP range to guess passwords, it would not completely lock a legit user out who was coming from somewhere else.

Any 8 character password? (5, Funny)

HermDog (24570) | more than 2 years ago | (#40245269)

Looks like it's time to change my password to "password1".

Re:Any 8 character password? (0)

Anonymous Coward | more than 2 years ago | (#40245381)

That's the kind of combination and idiot would use on his luggage.

Re:Any 8 character password? (0)

Anonymous Coward | more than 2 years ago | (#40245625)

-- That's the kind of combination and idiot would use on his luggage.

That's the kind of comment an idiot would make.

Re:Any 8 character password? (0)

Anonymous Coward | more than 2 years ago | (#40246037)

So is the ROT13 ones that lead off this page. Yet they get modded up. Sometimes, just to make myself feel crazy, I try to anticipate all the posts that a story will get before I go in and read them. That one was high on the list.

Sometimes slashdot posts remind me of that Simpsons episode where they're playing Bingo at the old folks home:

"B-11"..."You Sunk My Battleship!" [Group Laughter]...
"I-23"..."You Sunk My Battleship!" [Group Laughter]...
"G-53"..."You Sunk My Battleship!" [Group Laughter]...

Re:Any 8 character password? (1)

Anonymous Coward | more than 2 years ago | (#40245513)

Looks like it's time to change my password to "password1".

Ahaaa, that's what they're EXPECTING! But they'll never get me! I'm one step ahead of ALL of you!

My new password is "password-1".

Re:Any 8 character password? (1)

room101 (236520) | more than 2 years ago | (#40246001)

Idiot. Password123! is the way to go. I thought everyone knew that.

Re:Any 8 character password? (1)

sociocapitalist (2471722) | more than 2 years ago | (#40246293)

Surely you meant to say "Password1"

Re:Any 8 character password? (1)

dkleinsc (563838) | more than 2 years ago | (#40246587)

That's not 8 characters!

Bad math (1)

Anonymous Coward | more than 2 years ago | (#40245287)

There are 95 ASCII characters, which makes 95**8 = 6,634,204,312,890,625 possible 8 character passwords. At one million checks per second a brute force attack will take 6,634,204,312 seconds (210 years).

There's a fad going around right now to use ridiculously slow password hashing algorithms on the web, which the poster apparently has bought into:

On a state of the art COTS computer, the algorithm should take at the very least 0.1 second (100 milliseconds) when implemented in software, preferably more.

If you do this you're opening your site up to an easy DoS attack - a few 10s of login requests per second will slow your server to a crawl. The place where slow hashing algorithms ought to be used is exactly the opposite of where they're used today: encryption of local files, where the user actually has to remember the password, unlike web passwords where you can just use 32 random characters and let your local browser remember it (preferably with the browser's password file encrypted with a slow hash).

Re:Bad math (0)

Anonymous Coward | more than 2 years ago | (#40245329)

Oops, before someone accuses me of mixing up hashing and encryption: What I mean is using hash(password) as the key for a symmetric crypto algorithm.

Re:Bad math (1)

Bert64 (520050) | more than 2 years ago | (#40245751)

It's also possible (although very rare) to use most control characters in your password, at least on unix boxes. Very few brute force tools would be configured to try these.

Re:Bad math (1)

BlueParrot (965239) | more than 2 years ago | (#40246405)

There are 95 ASCII characters, which makes 95**8 = 6,634,204,312,890,625 possible 8 character passwords

Or you can use 6 random words from the oxford english dictionary, which gives you more combinations that the number of nanoseconds in the estimated lifetime of the universe, while still producing a passphrase that is feasible for a human being to remember.

Re:Bad math (1)

element-o.p. (939033) | more than 2 years ago | (#40246841)

There are 95 ASCII characters, which makes 95**8 = 6,634,204,312,890,625 possible 8 character passwords. At one million checks per second a brute force attack will take 6,634,204,312 seconds (210 years).

If you are trying to brute-force a specific password, then your argument makes sense. However, if you consider that most users are not /. tech geeks*, then some passwords are more likely than others. For example, "password," "secret," "topsecret," "jbond007" (yes, I saw that used in a professional environment once, sigh), and variants or these such as "s3cr3t," "53cr3t," or "53cr3+," etc. are a lot more likely than "mRqe2Ded", "7GNt4adL", etc. (which I generated with a Perl script). If you have access to the password hashes (which the crackers in this story do), then you compute hashes of common passwords and grep for them in the hash file. Voila! You now most likely have access to a boatload of user accounts.

*The assumption is that tech geeks know better and act accordingly. I'm aware that that's not always the case, however.

Use cases (1)

Keruo (771880) | more than 2 years ago | (#40245321)

Password selection depends on the place you're using the password.
For most websites, enter something like abc321, hit reset password and they kindly reset the password to something and email me the new relatively good password.
It doesn't need that much security, so those are stored in my email.

For places that need better passwords, $ md5sum - lot of random text pounded on the keyboard and result is something like 24a53bc05c6f216e340aa8d5dc08b605
That checksum becomes the password.

For places where I actually have to enter the password without copypaste, something generated like xkcd's battery horse staple correct.

Re:Use cases (1)

joostje (126457) | more than 2 years ago | (#40245703)

For places that need better passwords, $ md5sum - lot of random text pounded on the keyboard and result is something like 24a53bc05c6f216e340aa8d5dc08b605 That checksum becomes the password.

that may be a secure password, but many (most?) sites don't allow it as it doesn't have a mix of capitals, puntiation marks, etc.

Re:Use cases (2)

AlXtreme (223728) | more than 2 years ago | (#40246513)

I tend to use 'apg' when generating passwords, neat little tool. Aliased as 'apg -a 1 -m 12 -x 16' though, as the default generator goes for pronounceable passwords that are too short for my taste:

% apg
9&}v3Q/'n5O6UN
]%LE\!TLUt?Z]jjj
$i4&zmOxh-wmfGu
N6.H+i/^rcGo5`p ;a-_)wg}~*Xu~z
rKv4JoC6wO0`\6,j

If someone brute-forces those they have earned it.

Re:Use cases (1)

malloc (30902) | more than 2 years ago | (#40246439)

For places that need better passwords, $ md5sum - lot of random text pounded on the keyboard and result is something like 24a53bc05c6f216e340aa8d5dc08b605

That checksum becomes the password.
 

Using an md5sum greatly reduces your keyspace, so while it may still be strong enough for your needs, it's significantly weaker than you'd expect for a 32-character password.

[0-9a-f] is 15 characters. 15^32 = 4 x 10^37

Using a normal key range:
[0-9a-zA-Z+symbols] 62 + ~32 symbols on a standard US keyboard = ~94 characters. 94^19 = 4 x 10^37

Thus, you are entering in 32 characters but only getting the strength of 19.

md5 for passwords, bad idea (0)

fliptout (9217) | more than 2 years ago | (#40245401)

There was another /. story a few months ago discussing password encryption. What I gleaned was that using md5 for sensitive data on your webserver is insufficient. So I'm a bit surprised (well, maybe not) to see a big site like linkedin cut corners with security. I personally use a Python implementation of Blowfish.

Re:md5 for passwords, bad idea (1)

Anonymous Coward | more than 2 years ago | (#40245555)

Hashes are not cryptos.

Re:md5 for passwords, bad idea (1)

Bert64 (520050) | more than 2 years ago | (#40245723)

Amusing that people rag on about MD5Crypt being weak, when...

It's still much stronger than the unsalted simple hash being used by sites like linkedin.
Both of which are still massively stronger than the unsalted MD4 based algorithm used by windows (which is not only fast to crack, but can also be used as-is without needing to crack anyway), on which virtually all companies in the world are currently reliant.
Solaris still defaults to DES, although it does support MD5/Blowfish if you explicitly enable them.

Incidentally, until a breach like this occurs you have no idea what algorithm a website uses to store your passwords... There are still many sites out there which store them in plain text.

Why do people have weak passwords to begin with? (0)

Anonymous Coward | more than 2 years ago | (#40245425)

Is there any reason whatsoever to NOT just use a random generator for web passwords and store them locally? Do you really need to access your LinkedIn account from someone else's computer?

cat /dev/urandom | base64 | tr +=/ 012 | head -c 20; echo

...should be secure against brute force attacks for another decade at least. When it isn't, just add some more characters.

Re:Why do people have weak passwords to begin with (0)

Anonymous Coward | more than 2 years ago | (#40245855)

KeePass (or similar) + Dropbox (or similar) s the way to go... different password per site, I don't know the password, copy/paste updated everywhere.

I have a question: (2, Funny)

safetyinnumbers (1770570) | more than 2 years ago | (#40245647)

608b2d50a6521a27c12626cedfea0fc3

Re:I have a question: (-1)

Anonymous Coward | more than 2 years ago | (#40245739)

43dca4a56a0b9b16554bc593ea3c3b3f

Re:I have a question: (2, Funny)

Ibiwan (763664) | more than 2 years ago | (#40246131)

Dude. NOT cool; way too soon.

Re:I have a question: (0)

Anonymous Coward | more than 2 years ago | (#40246289)

Hey, uh hi, listen dude... you know the whole 608b2d50a6521a27c12626cedfea0fc3 thing, it's... it's just a little soon you know? I mean he just b7910f260256e5f658d00551b00c08d7 a few weeks ago and it's just not super cool. You gotta leave.

Authentication and Identification servers (3, Insightful)

msobkow (48369) | more than 2 years ago | (#40245695)

Whether MD5 is "secure" or not is irrelevant.

Machines that are accessed by users should not be the same servers storing the account security data. One of the key benefits to domain authentication provided by Kerberos and it's relatives is that the authentication data is isolated on a server that is supposed to be doing nothing but authentication and authorization.

That makes it damn hard to break into the security server to steal the password lists in the first place, regardless of what algorithms are used to hash the passwords. The problem is a poorly designed system, not a poorly equipped algorithm.

Re:Authentication and Identification servers (3, Interesting)

ShanghaiBill (739463) | more than 2 years ago | (#40245981)

Machines that are accessed by users should not be the same servers storing the account security data.

Get real. I run several sites that have user accounts. My infrastructure budget is $10/month for a hostmonster account. There is no way to have a separate server for account info without spending more money, which I am not willing to do. I use SHA-256 to store salted passwords. That is as good as it is going to get for most sites, and it is good enough.

The problem with linkedin, is that they are run by morons. Storing unsalted passwords with weak encryption should be considered criminal negligence even for a hobbyist website. Reasonable security would have cost them nothing.

Re:Authentication and Identification servers (2)

msobkow (48369) | more than 2 years ago | (#40246071)

Remind me to never subscribe to any website you run.

Re:Authentication and Identification servers (0)

Anonymous Coward | more than 2 years ago | (#40246197)

do you seriously spit out all of your personal info on every site you create an account at? a good hash wont solve the problems your going to run into

Re:Authentication and Identification servers (0)

Anonymous Coward | more than 2 years ago | (#40246955)

You already do.

Did ZDNet buy Slashdot? (3, Insightful)

tobiasly (524456) | more than 2 years ago | (#40245877)

First of all, WTF is a "password scrambler"? If you feel the need to dumb down the phrase "hash algorithm", you're probably submitting to the wrong site.

I LOLed at this article[1] on ZDNet this morning for its sensationalist, lowest-common-denominator "OMG computer hackery stuff" reporting, with its implied link between MD5's weakness (which has been known for years) and the LinkedIn breach (even though they use SHA1), and its ridiculous accompanying screen cap (running user-space tools while logged in as root, which no security-minded user would ever do, but hey "root@" at a shell prompt with lots of hackery output looks l33t).

And now here's basically the same thing on Slashdot. Yawn...

[1] http://www.zdnet.com/blog/security/md5-password-scrambler-no-longer-safe/12317 [zdnet.com]

Re:Did ZDNet buy Slashdot? (1)

Anonymous Coward | more than 2 years ago | (#40246765)

Slashdot is a great community inexplicably clustered around a shit website.

List of stolen Linkedin credentials (0)

Anonymous Coward | more than 2 years ago | (#40245929)

So, will someone point to a list of the stolen Linkedin accounts so we can see if our was one of them?

LinkedIN needs security professionals... (5, Funny)

tekrat (242117) | more than 2 years ago | (#40245973)

If only there were a website where they could connect with other security professionals, exchange ideas and maybe even find people to hire....

FreeBSD .... (1)

ltwally (313043) | more than 2 years ago | (#40245983)

"The default algorithm for storing password hashes in /etc/shadow is MD5. RHEL / CentOS / FreeBSD user can migrate to SHA-512 hashing algorithms."

FreeBSD has long (like, 10+ years) had support for Blowfish password hashes. Blowfish was a close second in the AES contest, and is quite strong. Enabling it only requires editing /etc/login.conf [freebsd.org] and afterwards updating any pre-existing passwords.

Collisions (0)

Anonymous Coward | more than 2 years ago | (#40246137)

I seem to recall that a few years ago, people started being able to easily generate MD5 collisions too, so I wouldn't say this is real big news.

Time for CorrectHorseBatteryStaple to catch on (2)

MaerD (954222) | more than 2 years ago | (#40246187)

As the summary notes, 8 character passwords can be cracked pretty quickly. 15 Characters with the crappy password rules we've enforced for minimum 8 character passwords become hard for users. It's time we start demanding correcthorsebatterystaple style random word passwords with maximum lengths of 255 characters (and a minimum > 8 characters).

That and WTF the passwords were unsalted? Salt them and DON'T keep the salt in the database.

Re:Time for CorrectHorseBatteryStaple to catch on (1)

BlueParrot (965239) | more than 2 years ago | (#40246461)

Just generate pass phrases for your users. That way they can't use the same shitty password on every site.

Re:Time for CorrectHorseBatteryStaple to catch on (1)

snemarch (1086057) | more than 2 years ago | (#40246835)

Please do keep the salts in the database, as not keeping salt there kinda implies using a single site-wide hardcoded salt... stored somewhere a hacker would probably get at just as easily as dumping the hashed passwords from the database.

Your salts are NOT a secret, and you DO want per-user salting.

Stop using passwords everywhere!! (2)

Galestar (1473827) | more than 2 years ago | (#40246219)

How many times does this have to be said? Having literally hundreds of thousands of sites on the web that require you to create an account with a password is not a good security model. This should be patently obvious to anyone who spends enough time on the web.

If any of you out there are devs (for consumer-facing web companies) out there - I beg of you to push your company to start supporting OpenID as a reliant party.

A little guide to login security for websites (0)

Anonymous Coward | more than 2 years ago | (#40246361)

- Specify a global salt which is not stored in the database, only in the code (so crackers don't have the full salt even when they own the database)
- Generate a random per user salt which may be stored in the database
- Store the password hashed, not in clear text, as hash(globalSalt + password + perUserSalt)
- Encrypt/Authenticate the connection to the login page over HTTPS
- Do some random stuff that makes your login system different from that of other sites (this is just so your website will not fall victim to automated tools and will require actual skill to crack).

If you do any less, your problem is not whether you use md5 or some other hash. In my experience from old code bases I maintained from prior coders an average of less than 1 of those bullet points is followed (and of course that number was meticulously calculated and not made up).

That said, implementing this should take even a Java programmer less than 200 lines of code.

Not quite right. (0)

Anonymous Coward | more than 2 years ago | (#40246565)

On a decent nvidia box here's the run output against a ... theoretical sha1

hashtable Status.......: Exhausted
Input.Mode...: Mask (?1?1?1?1?1?1?1)
Hash.Type....: SHA1
Time.Running.: 7 hours, 28 mins
Time.Left....: 0 secs
Time.Util....: 26894969.7ms/2475.6ms Real/CPU, 0.0% idle
Speed........: 130.9M c/s Real, 117.4M c/s GPU
Recovered....: 14745/6143150 Digests, 0/1 Salts
Progress.....: 3521614606208/3521614606208 (100.00%)
Rejected.....: 0/3521614606208 (0.00%)
HW.Monitor.#1: 0% GPU, 85c Temp

That's 130M c/s not 1M c/s and Sha1 isn't as fast as Md5 on hashcat.

I could see 1Mc/s on a middle tier single socket/core CPU though, that sounds about right.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?