E-mailing Passwords - Practice What You Preach

Monday, November 19, 2012

Bill Mathews


I have a few pet peeves (okay maybe a lot more than a few) but some of them really do have a basis in reality and aren’t just blind rage. This one falls into the “based in reality” category and really enrages me. Every once in awhile I register for some security training because, well, I’m curious as to what else is out there and because I want to learn things I don’t already know...crazy right?

So I decided to take some online training while I’m on vacation this week (yes I know, not much of a vacation but that’s me). I did some research and decided to register for a course provided by a well-known training vendor (I won’t mention which as I’ve sent this problem to them and they should have some time to respond) and I dutifully registered through their online store and paid for the training. Sounds great, right? Not so fast - they informed me that I would receive a “registration” email which, if one follows modern site design, you would assume there would be a link to verify my email address, etc. So what did I get? That’s right, an email with my username and password listed right there. That probably doesn’t anger normal people (let alone drive them to write an article about it) but gentle readers, I have never been accused of being normal so I’m pretty annoyed. Here, in no particular order, are my reasons for the anger and frustration:

1) My password was right there in clear text. I’m not really concerned about it passing through my network unencrypted so much because SSL, despite its flaws, is pretty good at preventing snooping. No, my problem is that clearly they are not encrypting my password at all. Now I suppose they could be encrypting in their database and then decrypting it for the email but... well let’s just say if they were that well thought-out I’m pretty sure they wouldn’t have sent the email with my password in it in the first place.

2) During the registration process I was asked to save my credit card number for convenience while making later purchases. Now there is nothing out of the ordinary about this and I’ve personally never opted to do it, but they’re asking for a lot of trust for a company that clearly doesn’t even encrypt my password. This is both arrogance and bad form - this is how severe breaches start.

3) This is a security training company! They’re supposed to be teaching people not to do stupid things like this, it makes my head hurt. Stop me if you’ve heard this before: “But Enterprise XYZ does it that way, why can’t we?” I hear this all the time and it is sound logic... until XYZ accidentally has a SQL injection. Boom - not only your password but now your credit card numbers are at risk. Security companies must start leading by example and not “do as I say not as I do.”

4) You have to wonder about the quality of the advice/training you’re getting from them if they build their registration/checkout software this way. When I take the course I plan to ask - not just to be a typical security jerk - but rather to point out the obvious problem with passing yourself off as an expert while violating the basic tenets of security. Violations like this should be pointed out and corrected by the offending party.

5) I’ve probably said enough, but according to every SEO article I read I have to have at least five points so here’s my last one. If this company isn’t bothering to encrypt the password, what are the odds that they’re encrypting your stored credit card number? You know, the one that thing that makes it “convenient” for you to checkout later. I just lose all trust in a company when they do things this way and I simply cannot believe they’re handling the credit card numbers properly.

So there you have it - maybe now you understand why things like this make me Hulk out with rage. Happy Thanksgiving everyone and enjoy your online shopping, I know I won’t :-)

Possibly Related Articles:
General HIPAA PCI DSS General General Security Awareness
Information Security
Email Passwords Authentication Access Control
Post Rating I Like this!
Steve Parker Nice article, but a little concerned / confused by the HUGE assumption you make in point 1.

We run a password policy where a user sets their password and, at the point it is set two things happen simultaneously:
1. Email confirmation of password in plain text as you type it as an aide-memoir
2. Password is encrypted against your account NEVER TO BE DECRYPTED

So, the password is entered over HTTPS and sent once plain. From then on, when a user logs in (again over HTTPS) the data they post in the login form is encrypted and this compared to the encrypted password stored on the database.

There is no need for decryption using this method. A user cannot request their password from us, but instead if they forget it, has to undergo a forgotten password process.

This is contrary to the assumption you have made here where you state that the site must not be encrypting your password so it is equally likely as it is unlikely that they are doing exactly the same thing.

Also your point re storing of a credit card. There is a facility (used by the likes of Amazon) where you can store a token, not the card details itself, that can only be used for purchases with a given website; they may not be storing your card number at all.
Bill Mathews Well the entire article is based on assumption so that is completely fair, I have no idea how their stuff is actually set up, just basing it my experience. Based on your reply I decided to try to request my password from them and yep, totally worked, they emailed my username and password to me in the clear same as the confirmation. That data is not encrypted.Again, entirely my assumption but I sincerely doubt that a site that does that is probably not using the same sort of tokenization that Amazon uses. My general point was that they (I'm not sure what site you work at but I never mentioned the site in my post) are supposed to be teaching security and are not following even the most basic best practices.
Steve Parker Thanks for your reply Bill. My general point was that, whilst your assumption may be sound (I don't know their set-up either), it is still a huge assumption. There are many ways to tackle security and we simply dont know without asking them what methods they have used.

Taking your reply, there is a method of encryption you can do in MySQL (can't comment on other databases but something similar will undoubtedly exist) called AES encryption. Here, you can add your own salt string (its possible to store this above web root) and then store data on the database in binary format, encrypted by that salt at 256 bit.

Even if you gave that data to someone else, without the salt is not readable i.e. it can only be read and decrypted in the code where the salt is used. This is a method that could be used to send you the password in plain text whilst a DBA (for example) would not be able to access the database and see your password directly without the code to interpret this. I personally wouldnt ask a developer to do this, but it is an example of how it could be done securely and conforming to high security standards such as ISO27001.

Again, thanks for the thought provoking article and for your reply.
Bill Mathews Yes AES is lovely but I guess I fail to understand why a site would go through the trouble of using AES in the first place then send the username and password combo to someone in clear text email. I guess I'm just too cynical sometimes.
Kathleen Jungck How difficult would it be simply to send a link in the e-mail to obtain the credentials and set the password in a secure session, which you access by already provided semi-confidential information to the vendor or to send an SMS or confirmation code to your e-mail during the sign-up process? If free public services can provide this minimal level of security, I'd expect a SECURITY TRAINING VENDOR to do so at a minimum.

Sending the credentials in clear text definitely didn't inspire much faith in the vendor's training.
Bill Mathews Kathleen,

Thanks, that was my bigger point. If they aren't doing the little things I doubt they're doing the bigger things.
The views expressed in this post are the opinions of the Infosec Island member that posted this content. Infosec Island is not responsible for the content or messaging of this post.

Unauthorized reproduction of this article (in part or in whole) is prohibited without the express written permission of Infosec Island and the Infosec Island member that posted this content--this includes using our RSS feed for any purpose other than personal use.