Forgot your password?
typodupeerror
Security Encryption Unix IT Technology

MD5crypt Password Scrambler Is No Longer Considered Safe 212

Posted by timothy
from the risky-busy-ness dept.
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."
This discussion has been archived. No new comments can be posted.

MD5crypt Password Scrambler Is No Longer Considered Safe

Comments Filter:
  • In other news (Score:4, Informative)

    by colin_faber (1083673) on Thursday June 07, 2012 @11:33AM (#40245123)
    rot13 isn't safe either.
  • by anared (2599669) on Thursday June 07, 2012 @11:34AM (#40245145)
    Good info about storing passwords properly: http://www.f-secure.com/weblog/archives/00002095.html [f-secure.com]
    • by Anonymous Coward on Thursday June 07, 2012 @11:49AM (#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.

      • by TheLink (130905) on Thursday June 07, 2012 @01:41PM (#40246891) Journal
        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.
        • by Firehed (942385) on Thursday June 07, 2012 @05:01PM (#40249571) Homepage

          The hashing algorithm is far more important in offline attacks than in online attacks. Please don't suggest otherwise, as you don't appear to have a background in security (this isn't a personal attack, but people without security backgrounds should never give security advice).

          If the table containing password hashes is compromised and leaked, the only thing preventing the plaintext being bruteforced is the strength of the algorithm. Salting prevents using a rainbow table, but you have to assume the salt is also compromised. If there's a global salt, it's just a matter of building a new rainbow table with the known shared salt: this is time consuming, but not that bad especially for weaker passwords IF THE ALGORITHM WAS CHOSEN POORLY. When each password has its own salt, an attacker must go one at a time, slowing the entire process down by a factor of [number of users in the compromised system].

          The algorithm's speed comes into play here. MD5 and SHA1 are meant to be used as checksums and are designed run as fast as possible - hundreds of thousands of times per second on password-length strings with modern hardware. This of course disregards the fact that they are not cryptographically secure. SHA256, same situation: it's a bit slower and while it's currently still considered crytographically secure, it's designed for speed. I can compute a rainbow table for a dictionary attack in about two seconds (or two seconds per row, assuming unique per-row salts). Compare to something like bcrypt or PBKDF2* which include a number of rounds specifically to slow things down: with even a relatively low number of rounds ($08$ to $09$ in bcrypt, for example) modern hardware caps at about ten hashes per second. Now going down /usr/share/dict/words takes 25,000 seconds - seven hours - instead of 1-2 seconds. That timeframe is going to get exponentially longer when you consider variations, substitutions, mixed case, and multi-word passwords, assuming the password being attacked is dictionary-based at all.

          You do raise a valid point about the other damage a data breach may cause, but aside from encrypted data (such as financial information), the password is the most damaging thing an attacker could retrieve since that probably grants access to a whole host of other sites since so many people re-use passwords. If you're OK with that, fine - go ahead and re-use crappy passwords everywhere. But for the love of security, please don't give advice on how people/companies should hash passwords.

          *PBKDF2 is meant to be used as a key derivation function to convert a password into a cryptographically-secure encryption key. It's not the best choice for password digests, although because it includes a work factor like bcrypt is still relevant to the discussion, and is certainly a better choice than MD5 or SHA-family alone.

      • Lack of a salt makes no difference. Salting is designed to defeat rainbow table attacks. However no actual criminals who are cracking passwords are using rainbow tables. It's all done using GPUs, which don't care about salts. Also the summary of TFA is wildly misleading. 1 million attempts per second? Uh, no. Last I checked oclhashcat-plus was capable of about 50 billion attempts per second on a 4xATI5970 rig. You can break most "normal" passwords in under one second with such hardware.
    • 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?

      • by w_dragon (1802458) on Thursday June 07, 2012 @01:10PM (#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.
        • by mlts (1038732) *

          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

        • by suutar (1860506)
          There's ways to keep the data passed back and forth from being constant. A challenge-response system, where the server sends a random blob and requires the client to manipulate it using the password in a fashion that it can verify using the database-stored hash, without actually transmitting either the password or hash. Of course, now we're well beyond the simple "hash this and see if it matches" and into automatic handshaking protocols...
    • by schwit1 (797399)

      Storing is meaningless if companies ** cough ** virgin-mobile ** cough** send you your passwords or PINs in an email every time you change it. And they include your phone number and name in the same email. And when asked to stop it they claim to adhere to industry standard security standards.

  • What about Debian? (Score:2, Interesting)

    by Anonymous Coward

    "... 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?

    • by slim (1652) <john.hartnup@net> on Thursday June 07, 2012 @11:44AM (#40245277) Homepage

      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.

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

        • by Vairon (17314)

          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

        • by SQLGuru (980662)

          HAK5 (HAK5.org) has been doing a series recently on how all of this works and it's been informative. I'd link directly to the episodes, but HAK5 is blocked......for some reason that think knowledge about hacking constitutes actual hacking.......when really, knowledge allows you to defend against it as well.

      • by AdamWill (604569)

        Note that the default in Fedora is also SHA-512. It seems the summary's claim that md5crypt is 'the default' is somewhat too sweeping.

    • by Qzukk (229616)

      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.

  • by mbone (558574) on Thursday June 07, 2012 @11:40AM (#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.

    • by Atzanteol (99067)

      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.

      • 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?

        • by berashith (222128)

          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.

          • by SQLGuru (980662)

            Put your hash in here and let me know how fast it comes back with the original password.......my 9 character passsword came back way to quick to my liking......needless to say, it's no longer my 9 character password.

            • You guys, every time you hash a string online, it goes into the rainbow tables. You must install openssl and hash locally for these tests:

              $ echo -n "password123" | openssl sha1
              cbfdac6008f9cab4083784cbd1874f76618d2a97
              $ history -c

      • by CaptainJeff (731782) on Thursday June 07, 2012 @12:02PM (#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.
      • by bugg (65930) * on Thursday June 07, 2012 @12:13PM (#40245683) Homepage

        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.

        • by tlhIngan (30335)

          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 rat

      • by Bengie (1121981)
        We don't care about brute force, only rainbow tables. If your password is bruteforceable, that's your fault.
        • every password hash is bruteforceable -- it's only a matter of time.

          Notice I didn't say every _password_ -- as nobody really cares* about your original password; they just care about being able to enter a password that will generate your hash. I recently ran a test and discovered that one of my passwords generates the same md5crypt as "swordfish" -- even though the password was a decently long string of random characters.

          So the short story here is that your password is only as strong as the verification me

      • 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.

    • by Artraze (600366)

      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.

    • 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: (Score:2, Insightful)

        by Anonymous Coward

        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 an

  • by HermDog (24570) on Thursday June 07, 2012 @11:44AM (#40245269)
    Looks like it's time to change my password to "password1".
    • by room101 (236520)

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

    • Surely you meant to say "Password1"

    • by dkleinsc (563838)

      That's not 8 characters!

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

      I know this is just a joke, but we really need to stop propagating the idea that memorable passwords are weak.

      The brute force search space of "password1" is 486 times larger than "password" (36^9 versus 26^8). Increasing the length of a password is one of the best ways to strengthen it. Intuitively, a randomized string is better than a structured one. This is correct, but only when the strings have equal length. Humans cannot remember long randomi

      • we really need to stop propagating the idea that memorable passwords are weak.

        Is this enough to convince you otherwise???

        $ sha1 password1
        e38ad214943daad1d64c102faec29de4afe9da3d
        $ cat combo_not.txt | grep 214943daad1d64c102faec29de4afe9da3d
        00000214943daad1d64c102faec29de4afe9da3d

  • 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 ac
    • by joostje (126457)

      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.

      • by AlXtreme (223728)

        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.

    • by malloc (30902)

      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.

      • Back in the day I used to use crypt to generate my passwords (with salt, of course). I figured anyone cracking my passwd files would at least get a chuckle out of it :D

        Plus, it does wonders for confusing people who are looking at a database of plaintext passwords that are all in crypt format ;)

        Oh, those were the days....

  • by safetyinnumbers (1770570) on Thursday June 07, 2012 @12:10PM (#40245647)
    608b2d50a6521a27c12626cedfea0fc3
  • by msobkow (48369) on Thursday June 07, 2012 @12:14PM (#40245695) Homepage Journal

    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.

    • by ShanghaiBill (739463) on Thursday June 07, 2012 @12:36PM (#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.

      • by msobkow (48369)

        Remind me to never subscribe to any website you run.

      • by utkonos (2104836)
        Hi there! I am very real. You can run a dedicated Kerberos box on a pre-packaged Debian VPS here [virpus.com]. That will cost you $4 per month, or $3 per month if you are willing to pay for a year at a time. If you are paranoid like me, you can run that dedicated Kerberos box on a VPS that you self-install with whatever OS and configuration you feel like using (I prefer FreeBSD because Heimdal kerberos is included in the base OS). That can be done here [nqhost.com], and will cost you $6.95 per month.

        I guess you are right that
  • by tobiasly (524456) on Thursday June 07, 2012 @12:28PM (#40245877) Homepage

    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]

  • by tekrat (242117) on Thursday June 07, 2012 @12:35PM (#40245973) Homepage Journal

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

  • "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.

    • by utkonos (2104836)
      Yes, according to CVS/SVN logs here [freebsd.org] FreeBSD has had support for blowfish password hashes for 11 years and 2 months. Don't you love dispelling anti-FreeBSD FUD?
  • by MaerD (954222) on Thursday June 07, 2012 @12:52PM (#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.

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

    • by snemarch (1086057)

      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.

      • by MaerD (954222)

        Wait... what?

        So I have my per user unique salt right there in the database (possibly in a different table) as the password? So the person who compromised the DB now has the salt and the password?

        I'd argue that getting at the tables in a database (miss a SQL injection for instance) than getting at the general code for a site. Keeping them at least on two physically separated machines (and you can still do a hard-coded salt + some form of per user salt combination) is more secure.

        Now all this being said, if t

  • by Galestar (1473827) on Thursday June 07, 2012 @12:55PM (#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.

It's a poor workman who blames his tools.

Working...