eResources and Google fail to secure user passwords

Failed Password Security on the Server

It never ceases to amaze me how many sites completely ignore generally accepted password safety practices.

A few weeks ago, I applied for the Google Computer Science Summer Institute. Google outsourced the online application to eResources, who claims to be “Your Trusted Technology Partner.”

Earlier in the year, I had created an account on this site and filled out some basic information. For some reason, the password wasn’t saved in my password manager of choice, and I couldn’t remember it. After a few guesses, I hit the “Forgot Password” link, typed in my E-Mail address, and was sent the message shown below.

Google and eResources failing to store passwords securely.

Google and eResources failing to store passwords securely.

Yes. That’s right. They sent me my password. In plaintext. In an E-Mail.

Mind you, I’m not particularly upset that they sent me my password in an E-Mail (although it isn’t particularly secure). I don’t really care how they sent it to me. They could have sent twelve angry weasels each bearing one of the twelve keys necessary to open a secret underground fortress that contained my plaintext password deep in one of its seventeen dungeons. I would still be pissed. The issue isn’t that they gave me my password, the issue is that they had my password to give to me.

Passwords should never be in plaintext on the server.

There’s a common misconception with this. Just because it’s encrypted on your server doesn’t mean that it isn’t in plaintext. If I could somehow extract my password based on the information stored on your server, then as far as I’m concerned, you’re storing my password in plaintext. And that is not okay.

Why is this important? Well, it’s very simple. Your server might be compromised. The contents of your database might be released. Many internet users use the same password on multiple websites, and if you accidentally leak their password in plaintext, all of their other accounts are in immediate jeopardy. Plenty of high-profile sites have been compromised. It can happen to you!

What’s the alternative? Hash the passwords, and with a unique salt for each user. When a user submits their password to you, concatenate the salt and hash the combination. You may then store this hash (and the salt, separately) in your database and perform the same hashing routine each time a user tries to log in. Their passwords are never written to the database, and their passwords can’t be extracted from the hashes. Better yet, even if two users have the same password, their hashes are completely different (thanks to the salt).

More information on safely hashing passwords is readily available, you just have to look. For example, ensure you are using a suitable hashing algorithm.

Shortly after I noticed this basic password security violation, I notified both Google and eResources of the issue. I carefully selected a subject line likely to grab attention: “Password Security Concern”. A representative from eResources sent me back the following email promptly:

Eric –

Thanks for expressing your concern. I will pass it on to the administrators of this program.

While I recognize that this isn’t as secure as a reset password link, your password is stored in an encrypted format and then decrypted before it is emailed to you.

Best regards,

[Name Redacted]

While, yes, encrypting the passwords is more secure, it’s roughly the equivalent of preventing intruders from entering your house by simply closing the door. If I’ve somehow gained access to your database, I likely have the ability to access your code as well, which means I can just decrypt everything. Passwords need to be non-reversibly hashed.

Don’t get me wrong. eResources is not alone in their blatant disregard for even the most basic levels of password security. There are, unfortunately, thousands of other incompetent or uninformed companies on the web making the same mistakes. This, however, does not make the offense excusable.

Google certainly knows better than this, and has a direct responsibility to ensure that their users’ data remains safe. They have yet to respond to my email.

eResources is not Google, but by using them, Google endorses their product. Google is putting their scholarship applicants’ passwords on the line, and this is simply not acceptable.

Eric Jeney is a Java aficionado with a number of projects under his belt. He enjoys programming for the web, and writing about his experiences. He currently studies Computer Science at the University of Maryland.

View all posts by Eric →

  • Chan Matthewd

    Eric, very good article and information
    sharing with everyone.

    The key point is that we should assume
    any and all parts of the servers are compromise, user’s plain-text
    passwords are still not able to be retrieved or computed.

    Password should be only stored in
    persistent storage after one-way hash is applied to the password.
    Password should never use any symmetric-key algorithm to encrypt and
    decrypt for comparison. DBA could not know the password of any users
    because he will not know the hash algorithm and the key use to
    generate the hash result.

    System secret keys of the hash algorithm can be
    stored in keystone (with required password to access), so even Java
    developer who develops the hash logarithm will not know how to
    compute the hash result.

    The hash algorithm can add the key
    before hash like (
    to avoid dictionary table
    lookup attack. Also, sometimes Java developer will combine the user unique key (username or other user information) with the password to form the “new password” before hash so that
    common-used password will not generate the same hash result.

    MC 🙂

    • Sam

      I once took over development of a site where the previous developer stored the users password in a plaintext cookie along with their email, and compared this to plaintext copies on each request to keep the user logged in. Sadly commisioning clients are totally naive and unaware of these clueless developers. Or perhaps the developer knows better, but isnt being paid enough for that project to implement best practice, all at the end users expense.

      There should be a standard ‘license’ or registered developer agency like with doctors, to protect clients from this.