PRWeb Stores Passwords In Clear Text

It is 2012 and with the growing web threats you would expect to see increased measures to protect user credentials. We hope that in the wake of events with LinkedIn and eHarmony others realize the importance of an increased security posture.

Consider the recent LinkedIn, e-Harmony or similar breaches in the past to see how important this topic has become.

Back to the topic at hand…

For some crazy reason I was looking at PRweb today and forgot to
save the password I had chosen. As we all do, I clicked on the forgot password link and
got this pretty email from them:

Dear XX,

Here is your login information for PRWeb.

UserName: my@email.com
Password: MYPASSWORD
Log In URL: https://app.prweb.com/Login.aspx?LanguageID=1033&SkinID=-1

Sincerely,

PRWeb, a Vocus, Inc. Company

Oh no…they didn’t… Yes, they do!!! Do you see the problem?

They are storing your password in clear text and sending it in the clear as well, via email. At no point did I have the requirement to change, I could go on about my day using the same credentials as if nothing.

Now, go back to the recent breaches. At least the password were hashed making it much harder to identify and break all the accounts (specially the ones with good passwords). On PRWeb, there would be no work for anyone to do, other than gaining access.

It also means that anyone with access to their database can easily see the password for all the users. This is an example of what you should not do if you’re storing credentials for your users.

17 comments
  1. How do you know that they are storing it in clear text on their own servers?

    This is just an email you received with your password in it.

    1. Passwords that are stored correctly are encrypted and the website never knows what the actual password is. So by them sending an unencrypted password through email it shows they are storing the password in clear text which is a bad thing. Most websites send the user an email with a link to change the password to something new which is the correct way of doing things.

      1. Passwords that are stored correctly are “hashed” and not “encrypted”.

        When you hash (using the proper algorithms of course), the website never knows what the actual password is. When you encrypt, the website can get the password back.

        By them sending an unencrypted password it means they’re either in clear text or encrypted; but most probably in clear text since they didn’t care about sending the password via email (which is totally insecure).

        Sometimes you have to encrypt passwords because you need to fetch them back for something else (like storing SMTP credentials to send emails from the website). But for user passwords, you should always hash.

  2. I would hope the password your using on PRweb is a disposable anyways.

    Many sites store passwords with 2 way encryption. This at least requires access to the database and access to the encryption key(which better not be in the database). For things like forums, or anything that the information is not critical I see no problem with this. Allows a much easier process for users to regain access to their account.
    How do you think your credit card numbers are stored on many sites that remember them? Using the same 2-way encryption that is storing the password most likely.

    Of course there’s the debate about e-mailing passwords in the clear as well…….

    1. I personally see no reason as to why a website would need to know my password or have an encryption key to access it at a later date. If I forget my password its just as easy to reset it to something new.

    2. Credit card numbers are not stored at the site. The e-commerce site sends the encrypted CC information to the payment processor the first time you enter it, and the processor sends back a token. The token, and the last four digits of the card number, is stored by the e-commerce company. On future purchases the e-commerce company sends the token to charge the associated card. If there is a security breach, the tokens are deactivated and become useless to the attacker.

  3. Interesting conversation here in the comments — I can see some don’t think it’s as important.  For what it’s worth, David, I shared your post with the Vocus/PRWeb product management team and they’ve decided to implement changes immediately. So well, done and thanks for the advice.  

  4. We store our passwords encrypted in the database so your headline is incorrect.  That being said,  I agree sending passwords in emails is not good practice and hashing is much more secure.   On Monday we changed PRWeb to send reset password links that can be used one time and expire in 24 hours.   Also, prior to this blog post, we were working on switching to hashing and salting the passwords.   This will be released in the next couple weeks.

    Mark Heys
    CTO, Vocus Inc.

  5. Seriously its called encryption MD5 or something the email should read XXXXXXXXX for password, are these folks novices or what?  I am available for hire.

Comments are closed.

You May Also Like