Tag Archives: passwords

Proposed Secure Password Hashing API in PHP 5.5

PHP 5.5 will be gaining a simpler and more newbie-friendly way to securely hash passwords. As those who are active in the PHP community are all to well aware of, it is quite a trial to educate everyone on properly securing passwords in their applications. Even large web companies are routinely outed for their lax measures. Sometimes they’re stored in plain text and sometimes they might as well be, like when weak MD5 or SHA1 hashes are used. Remember the big scandal when Gawker Media’s database of user passwords was leaked, and the weak hashes were solved within days? Or more recently, when it was discovered that Pandora not only stored your password in cleartext, but transmitted it that way as well? It seems that at least two well-known websites have a similar “facepalm” moment every year.

The PHP contributors want to help combat this problem—at least among companies using PHP, obviously the issue is by no means limited to PHP developers—with the new API. A couple of simple functions that even the most novice of developers can use will automatically take care of the hashing using bcrypt with a reasonable work factor.

The proposed syntax is something like this:

//hashing a new password
$hash = password_hash($password_entered);

//Checking a password
if (password_verify($password_entered, $hash_from_database)) {
    //password is valid if password_verify() returns true
}

For compatibility with versions of PHP prior to 5.5, you can even download a PHP implementation that will automatically be disabled in a PHP 5.5 environment.

The new Secure Password Hashing API in PHP 5.5 [GitHub]

Pandora Password Debacle

There’s a post going around on Google Plus that shows off a glaring security hole in the popular internet radio site Pandora. If you use FireBug (or the HTML inspection tool in your browser of choice), you can see that the Password field on the account settings page clearly shows your password in the value attribute. It displays bullets because it’s a password type form field instead of a plain input, but the password is still right there.

That’s not good, however you look at it. While updates to the post explain that it’s not necessarily indicative that Pandora is storing passwords in their database in plaintext—they could just be caching them client-side—it’s definitely in the realm of possibility. Not using a slow one-way hash and this sort of thing tend to go hand in hand.

Given that I was able to see my password, on a new computer I had yet to use Pandora on, with a browser that I had recently cleared of cookies and other local storage, Pandora is most likely storing passwords in plaintext and transmitting them over the internet. (Or, at best, using a two-way encryption scheme, which is little better.)

Pandora doesn’t one-way hash their passwords [Google Plus]

6 Articles You Should Read Before Storing Users’ Passwords

It’s 2012 and there are still an awful lot of high-profile websites leaking users’ passwords. Someone manages to snatch the database table, and then they crack the passwords, which are more often than not encrypted with weak MD5 or SHA1 hashes. It’s not enough…and the beginner tutorials encouraging this behavior aren’t helping.

If you are going to store passwords, you need to be using a slower hashing algorithm with salting, the preferred option being bcrypt. An modern, run-of-the-mill computer can generate an MD5 hash in well under 1/1000 of a second. That means a script can try over 1000 guesses at a password per second. In contrast, bcrypt with a cost of 12 takes a second and a half. (This informal test was conducted on my aging Core 2 Duo machine.) It would take exponentially longer to guess a password at that rate.

A modern server can calculate the MD5 hash of about 330MB every second. If your users have passwords which are lowercase, alphanumeric, and 6 characters long, you can try every single possible password of that size in around 40 seconds. — Coda Hale

If an attacker wanted to get fancy, they could use GPUs to crack passwords an order of magnitude faster than current CPUs, or buy a bunch of instances on Amazon EC2 and parallelize it that way. Those fast hashes don’t seem to secure now, do they?

Here are a few articles on the subject that are well worth reading if you’re going to build a web application that requires user registration:

What Everyone Missed About the Gawker Password Scandal

A few weeks ago the internet exploded with news about the servers that host the Gawker blogs (Gizmodo, Lifehacker, Jezebel, etc.) being compromised by a distributed group of crackers known as Gnosis. Though the attack itself was covered fairly well by various tech publications (and less so by the traditional media, as usual), there was a recurring theme that just seems wrong

Many people commenting on the subject, whether in editorials, podcasts or discussion forums, would bring up the subject of how strong the users’ cracked passwords were. There were a large percentage of users with weak passwords like qwerty, password, 123456, or monkey. Yes, they are obviously weak passwords. However, I think it’s wrong to use them as an example of bad user-end security practices.

I, for one, would never use one of my more secure passwords for an account on a blog or discussion forum. I would be likely to come up with a throwaway that I would never use on a site where I would care if it were compromised. Considering that Gawker’s readers are probably a little more tech-savvy than your grandparents, why assume that they wouldn’t take the same approach? Given Gawker’s security breach, I think it’s a well-justified method to use.

How Does Netvibes Store Our Email Passwords?

The popular start page Netvibes features a widget that automatically checks your email for new messages. For it to do this, you must supply your email address and it’s password (as well as your mailserver, if you use POP or IMAP).

Here’s what I want to know: How are they storing our passwords? We’re giving them the login details to our email accounts, and they haven’t told us how they’re storing them!

I assume they aren’t in plain text (they’d better not be!), but how does their widget work, then? They can’t just decrypt an md5 hash when they need to access your account (or can they, somehow?). If they’re encrypting the passwords, how are they going about it? Are they using a salt? Are they using md5 or sha1? How secure is the server these passwords are sitting on?

Obviously they can’t tell us everything, as that would be a security risk. However, I think we should know a few things about how are email login details are being stored.