MD5crypt Password Scrambler Is No Longer Considered Safe 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."
In other news (Score:4, Informative)
Re:In other news (Score:5, Funny)
That's why I use rot26. It's twice as strong.
Dammit! (Score:5, Funny)
Who told you my password?
Re: (Score:2)
rot13 isn't safe either.
Do these young'uns even know what rot13 is?
Are you sure SHA-1+salt is enough for passwords? (Score:4, Informative)
Re:Are you sure SHA-1+salt is enough for passwords (Score:4, Interesting)
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 (Score:5, Informative)
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 (Score:5, Informative)
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.
Re: (Score:2)
Re: (Score:2)
Re:Are you sure SHA-1+salt is enough for passwords (Score:4, Interesting)
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 (Score:5, Informative)
Re: (Score:3)
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
Re: (Score:2)
That is what one tries to avoid. The best is to have multiple blocking mechanisms. First is by IP address, so if someone is hacking user Alice's account, the site trying to hack in as Alice gets blocked on the IP level.
The hashing appliance is a work in progress. Either a delay between handing out replies for the same user or an outright lockout serve the same purpose. The trick is to slow down a dictionary attack, as well as make it difficult for an attacker to grab the list of user password hashes.
Re: (Score:3)
Spoofed source IPs would defeat this method easily.
It's useless for an actual online brute-force attack, since the attacker clearly wants to receive a reply from his password attempts, but if the aim is just to DoS the authentication server, that's not a problem. You should send the client a token and wait to get it back before you start blowing CPU cycles on determining whether their password hash is legit.
Re: (Score:2, Informative)
You cannot spoof an IP in this case. You are establishing a TCP connection and sending login info over HTTP. The TCP connection starts with a 3 way handshake, which is not possible in the case of spoofed IPs. IP based throttling, and dedicate hash processor (may be someone could build a co-processor card for this) sounds great actually.
Re: (Score:2)
Re: (Score:2)
Ever logged in to a mail server before? You logged in with that method.
How it works:
1. Make standard hash of user's password.
2. Make random 'challenge'. Give to user.
3. User sends back HASH(HASH(password) + challenge)
4. Server computes HASH(Stored hash + challenge)
5. Authentication with no password sent or stored in cleartext.
Re:Are you sure SHA-1+salt is enough for passwords (Score:4, Interesting)
And the hash is the password again...
If I have stolen $hash from server, I won't need to break that hash to emulate the user.
I just need to get challenge and return hash($stolen_hash + challenge) to the server. Congratulations, you re-invented saving "plaintext" passwords! ;)
Re: (Score:3)
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.
Re:it is about compute speed, not hash strength (Score:4, Interesting)
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.
True, all true, but entirely missing the point. Never store any customer data at all unencrypted, even password hashes. There are many ways to have your data pwnt, but bulk copy of the data at rest is the easiest and most common. That data (bulk data at rest) should never be unencrypted, ever.
Re: (Score:2)
If the server can decrypt it, an attacker can as well.
Its just a minor speed bump along the way.
Re: (Score:3)
All of security is just speedbumps along the attackers way. That's what security does, whether physical or IT: it delays the attacker by some amount.
If all of your customer data is plaintext at rest, then the attacker just needs to pwn any server anywhere that can see that data, and bulk-copy it off. That might not even raise any internal alarms, since it's justa file copy.
If all of your customer data is encrypted at rest, then the attacker needs to pwn each machine thatknows how to decrypt each part of t
Re: (Score:2)
Does "run SH-xxx N times" actually grow in computational complexity as proportionally to O(N)? I don't happen to know enough about SHA-x to answer this, but I do remember that triple-DES did not actually increase complexity proportional to a tripled key length.
http://en.wikipedia.org/wiki/Meet-in-the-middle_attack [wikipedia.org]
What about Debian? (Score:2, Interesting)
"... 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? (Score:5, Informative)
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: (Score:2)
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: (Score:2)
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: (Score:3)
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.
Re: (Score:2)
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.
Re: (Score:3)
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.
Unsalted hashes are worse. (Score:5, Interesting)
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: (Score:3)
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: (Score:3)
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: (Score:2)
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: (Score:2)
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.
Re: (Score:2)
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
Re:Unsalted hashes are worse. (Score:5, Informative)
Re:Unsalted hashes are worse. (Score:4, Insightful)
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: (Score:3)
Re: (Score:2)
Re: (Score:3)
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 is magic (Score:2)
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: (Score:2, Funny)
That's why people should use Pepper instead of Salt, plus Salt is bad for the heart.
Re: (Score:2)
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: (Score:2)
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)
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
Re: (Score:2)
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.
Any 8 character password? (Score:5, Funny)
Re: (Score:2)
Idiot. Password123! is the way to go. I thought everyone knew that.
Re: (Score:2)
Surely you meant to say "Password1"
Re: (Score:2)
That's not 8 characters!
Re: (Score:2)
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
Re: (Score:3)
Is this enough to convince you otherwise???
$ sha1 password1
e38ad214943daad1d64c102faec29de4afe9da3d
$ cat combo_not.txt | grep 214943daad1d64c102faec29de4afe9da3d
00000214943daad1d64c102faec29de4afe9da3d
Use cases (Score:2)
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
Re: (Score:2)
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: (Score:3)
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 ;a-_)wg}~*Xu~z
9&}v3Q/'n5O6UN
]%LE\!TLUt?Z]jjj
$i4&zmOxh-wmfGu
N6.H+i/^rcGo5`p
rKv4JoC6wO0`\6,j
If someone brute-forces those they have earned it.
Re: (Score:2)
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.
Re: (Score:2)
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....
I have a question: (Score:3, Funny)
Re: (Score:3, Funny)
Authentication and Identification servers (Score:4, Insightful)
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 (Score:4, Interesting)
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: (Score:3)
Remind me to never subscribe to any website you run.
Re: (Score:3)
I guess you are right that
Did ZDNet buy Slashdot? (Score:4, Insightful)
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]
LinkedIN needs security professionals... (Score:5, Funny)
If only there were a website where they could connect with other security professionals, exchange ideas and maybe even find people to hire....
FreeBSD .... (Score:2)
"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.
Re: (Score:2)
Time for CorrectHorseBatteryStaple to catch on (Score:3)
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: (Score:2)
Just generate pass phrases for your users. That way they can't use the same shitty password on every site.
Re: (Score:2)
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.
Re: (Score:2)
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
Stop using passwords everywhere!! (Score:3)
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.
Re: (Score:3)
What happens when openid is broke? Oh....
If there is a vulnerability in OpenID I'd love to hear about it.
Choice of identity providers is of course important, but this is decidable by each user. Unlike Facebook/Twitter/LinkedIn federated login - if the identity provider for the specific protocol you have chosen is compromised, it exposes all users everywhere to the vulnerability as this LinkedIn compromise has shown - I pity the fool that is using LinkedIn federated login.
23 depressing passwords on Linkedin (Score:3)
http://www.buzzfeed.com/jwherrman/the-23-most-depressing-leaked-linkedin-passwords [buzzfeed.com]
Re: (Score:2, Insightful)
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. (Score:5, Insightful)
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. (Score:4, Insightful)
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. (Score:5, Interesting)
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: (Score: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.
You are aware that such large-scale attacks are pretty rare? The vast majority involve one or two hosts. (You can tell this by looking at logs and overall net traffic levels.) They also tend to try all sorts of obvious things first; it's really easy to spot what's going on, and it usually reads like a litany of all that's wrong with IIS and PHP... but I digress. While theoretically, a botnet could be used to get past techniques like denyhosts, most botnets work on far more valuable things than breaking into
Re: (Score:2)
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 lowe
Re: (Score:2)
That doesn't mean that you don't also do defense in depth such as account lockouts, increased response times for consecutive failures and limiting the number of tries. But at the end of the day you must make the assumption that the attacker can bypass those and make as many attempts per second as they have the money/resources for.
Then there's the
Re:2004 called they want their news back! (Score:5, Insightful)
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: (Score:2)
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
Re: (Score:2)
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: (Score:2)
I've never used RoR, I prefer to write correct PHP code. What exactly do you use MD5 for where SHA-1 would not be more appropriate (less prone to collisions, due to a larger hash space)?
Re: (Score:2)
Also, I'm not sure HMAC MD5 is considered weak at all.
Maybe not, but would it be better to use HMAC MD5 or HMAC SHA-1? Or HMAC SHA-512? What is the argument for using a weaker alternative?
Firstly, a bad tool becoming so popular to the point where it's nearly impossible to convince people not to use it is not an uncommon effect.
Right, that's why I'd love to see PHP remove the MD5 function. It would force people to wonder why and look for alternatives.
Re: (Score:3)
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
Re: (Score:2)
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 b
Re: (Score:2)
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.
Re: (Score:2)
With a strong hashing function, you'll post your /etc/shadow on the web and still sleep like a baby at night.
That's going a bit far... if the hashing function is known and a password in the list is known, the rest of the variables can usually be filled in pretty quickly. At that point, a brute force attack against the rest of the hashes will only be limited by the speed at which the attack can be performed -- which is the point of what's being argued in the original article (not just that md5crypt is bad, but that any replacement should be system-configurable (so that it's harder to guess the algorithm and algori
Re: (Score:2)
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.
Inc
Re: (Score:2)
md5 is definitely more collisionable than sha1!
GP was ragging on md5, not MD5Crypt, whatever that is.
Re: (Score:2)
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: (Score:2)
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: (Score:3)
There are 600K words in the Oxford dictionary. That gives, by your formula, a formidable 46,656,000,000,000,000,000,000,000,000,000,000 possible passwords to crunch into the rainbow table.
But most Americans have a lexicon of about 8K - 10K words! 9000^6 is only 531,441,000,000,000,000,000,000.
As you are aware, "correct horse battery staple" is only four words: 9000^4 = 6,561,000,000,000,000. Not an improvement in complexity, but considerably more memorable. God, passwords are so shitty, they do my head
Re: (Score:2)
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",
Re: (Score:2)
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:
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).
While the gist of your argument is true, the argument about 210 years to complete a brute force attack is fairly obviously false. It will take 210 years for a brute force attack to traverse the entire set of options on a single hash.
However, when you scale up to millions of hashes and add some limited intelligence to the brute force method, you'll likely find thousands of passwords within minutes. With more computationally difficult algorithms, this "minutes" timeframe can become "days" or "weeks" or even
Re: (Score:2)
Great... so instead of one password per site, someone just needs to log into your DropBox account [sophos.com] and crack your (hopefully fairly strong) KeePass password, and they get everything -- not just all your passwords, but what sites they're for and what the associated usernames are. All sitting out there on a public server 24x7.
How strong is your KeePass password?