I recently made a purchase on MacUpdate and as part of the purchase I was required to setup an account with them (username, password, etc.). Annoying, but all well and good until I received both my username AND PASSWORD in the clear from them in the same confirmation email.
For most people, the reasons that this is very bad should be obvious, but for those for whom it’s not, here are a couple reasons why this is not good.
First, both my username and password were sent unencrypted across unsecured mail relays. At the very least, they should never be included in the same email as this would require a potential attacker to put together several pieces of communication to get all information needed. Regardless, user created passwords should NEVER be sent to a user, as they very well could be used for other things. If you must send the user a password, it should only be a randomly generated password to which the account has been reset. It would be best if this randomly generated password had an automatic expiration if the user did not go in and change it to something personal in the site.
The second, and perhaps less obvious implication, is that the fact that you can send me my own password tells me that you are either storing my password in your database unencrypted or with reversible encryption. Again, this is a bad idea. (I confirmed that they didn’t just send the password from the initial form by requesting my password be sent to me after the initial registration.) You should always store a password using one-way encryption (a hash) and then validate login attempts by taking the supplied password applying the same encryption to it, and comparing the result to the stored, encrypted password. This has the benefit of preventing an attacker from obtaining the actual passwords from your system in the event that you are compromised.
This isn’t even getting in to more advanced ideas for securing pages (not having the username/password fields on the same page for example), but rather just the very basics of not throwing sensitive information out into the network.
Anyway, needless to say, I was very annoyed at all this and sent them an email criticizing their security practices. I also asked them to remove my information from their systems as this is likely an indication of their security practices in general. Anyone who has done business with them in the past may wish to consider doing the same thing.
Tags: passwords
yes, one-way encryption is the way to go. no user db should ever hold a raw password. however, at what point should the one-way encryption occur? …i mean, the user is on a page, and that page could use javascript to do the one-way encryption so the server-code only ever sees an encrypted password (to store in the db). is this up-front encryption (in client-side js) considered overkill? i hope not, because it sounds cool.
Ha, no I don’t think we need to encrypt the passwords on the client side in JavaScript. The web session was secured using SSL, and I’d rather not see someone roll their own encryption libraries in JavaScript, that’s just asking for cryptographic weakness (JavaScript random isn’t even considered truly random).