MD5crypt Password Scrambler Is No Longer Considered Safe
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."
That's why I use rot26. It's twice as strong.
Looks like it's time to change my password to "password1".
JADBP
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.
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.
If only there were a website where they could connect with other security professionals, exchange ideas and maybe even find people to hire....
If telephones are outlawed, then only outlaws will have telephones.
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.
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.