August 05, 2009

Dear Valued Mozilla Customer:

It has been brought to our attention that the Mozilla Store www.store.mozilla.org has had a security breach. We take all security breaches very seriously, and are working hard to determine the extent of the violation. In the meantime, the site has been taken down as a protective measure.

At this time we do not believe any credit card information has been compromised. However, some Mozilla Store customers’ user names and passwords have been exposed. It is our strong recommendation that all Mozilla Store customers proactively change their user name and passwords for their Mozilla Store account and all other accounts that use the same information. We will not bring the site back up until we are confident that we have addressed all security issues. A notification will be sent to you when the site goes back up.

GatewayCDI apologizes for any inconvenience this may cause. We value our customers and their online security is a top priority to our organization.

Sincerely,

Conrad Franey
Chief Marketing Officer
GatewayCDI

There are 3 major things I’d like to discuss about this. The first is the obvious, if they had used safe storage techniques; the probability of their password list being compromised would have been practically eliminated. I cannot stress that enough, if a password is in the database as plain text, it will be compromised, I know that means you can’t just send a user their password when they forget, but that’s ok… it’s not a huge hassle to change a password. The second topic is users that “use the same information”. Granted, most of us are guilty of this at some point or another. We all have favorite passwords that we like to use. I personally try to make classifications of passwords for different types of sites, but sometimes I find myself using a “default” password out of habit. Please, people, one of the best ways you can protect yourself on the internet is to use different passwords. If not for everything, don’t use the same password for sites like facebook, myspace, or twitter that you would use for your bank or email account. The third MAJOR topic that I feel needs to be discussed is in regard to that first sentence that’s highlighted in red. “At this time we do not believe any credit card information has been compromised.” This should not even be a fear. Under no circumstances should you store your credit card on any sites database, and under no circumstance should any site store it without your asking. After a transaction is completed, the only thing that should remain is the authorization number, order number, and the last 4 digits of the card. That is all the bank and the company should EVER need to look up a transaction. Verifying identity using a credit card number is a terrible thing, and any company that does so should be avoided. I am hoping that the reason they do not believe any credit card #s were stolen is because they don’t store them… but only time will tell.

Ok, enough ranting and raving from me. I have spoken my mind on this topic, now I will shut up and let you all get back to your days. Just remember, sites do not always practice safe storage procedures, so the best protection from identity theft is still your common sense, so use it!

It is easy to spot an organization that stores passwords either completely unencrypted or encrypted using a method that allows for decryption easily.  One method to spot this insecure behavior is the ability to “recover your password” without the need of resetting it.  If you can recover your password, then someone else can easily access it as well (with the right tools).  Another method is one to spot carefully… it’s not to fear when a company requires your password to be different from your previous X passwords, but when they also look for similarities and judge your password to be “too close”.  This may come off as being a very secure tactic, when indeed it must mean that they are storing not just one, but several old passwords in a way that would make them, once again, an easy target.

So now we know some things to spot visibly that should throw up some caution flags.  What else is there to know.  There are methods of storing passwords that are more secure.  For instance, storing a “hash” or checksum of a password using an irreversible, or one-way, algorithm is a good start.  There are several hashing methods out there, some of which are better than others, but before we continue, allow me to explain what a hash is and how it can benefit secure data storage.

Sparing you from all the techno-jargon, a “hash” or checksum is an “encrypted” form of a variable.  That’s a few quotes thrown in there, technically the term hash is misused by the Internet community as is encrypted when talking about a checksum.  Encrypted would technically make the statement that the process is reversible using some sort of key.  When in all actuality there is no key, it is a one-way cypher resulting in a fixed length string of letters and numbers that is unique to the variable data.  A common hash string (MD5) is 128-bit or 32 hexadecimal characters.  In short you have 32 characters ranging from 0-9 and A-F, 16 possible choices for each character position, giving you approximately 340,000,000,000,000,000,000,000,000,000,000,000,000 possibilities.  This doesn’t eliminate the possibility of duplicate checksums, but obviously the chances of that occurrence are highly unlikely.  The benefit of storing a data in “hash” form is that if a person gets a hold of a list of passwords, they are much easier to enter than if they get a hold of just your password hashes, but there is still a weakness.

Passwords are only as good as the people that make them.  Of course a developer can submit their users to a multitude of password rules, eliminating common passwords and other occurrences, but you’re still left with the possibility of 2 people having the same password.  If 2 people have the same password, they therefor have the same hash.  So how do we eliminate this?  Now it’s getting fun!

Eliminating possible duplicate hashes in your database is the fun part, and the part that can really help you push forward into the realm of password security.  Salting your passwords is the easiest method to eliminate this rare phenomenon. A salt is small bit of data added “somewhere” to your password string.  As I said, this is where it can be a lot of fun if you’re creative.  The salt has to be stored, and should be unique to each individual user, otherwise you still have the possibility of identical hashes with the same password.  Attaching information collected during the registration process is a good start, or even using the “id” of the user.  Or you can be creative and use multiple items or even multiple times of running it through a hashing function.  This ultimately will be up to you, but I will give you a little guidance.

For convenience we will keep this easy.  The salt variable will be left undetermined in this sample so that you can fill it in with whatever you like.  Feel free to play around with it.

<?php
$salt=X;  //undetermined, replace X with something of your choosing.
$password=$_REQUEST['password'];  //Sent from a form, or other type of post/get data set.
$seasoned_password=$salt.$password; //This will joint the 2 together;
$password_hash=md5($seasoned_password);  //This can now be stored in the database along with the salt.
?>

Storing a salted hashed password will effectively eliminate the chances for duplicate password hashes, as long as the salt is wide enough variable.  Remember never to store your salt as it’s own field, hide it as something else.

I am indeed sorry if this was a little long and drawn out.  Security is not something to be taken lightly, and I hope this helps give insight in to how you can help protect your users passwords as well as the data you wish to protect.

I will be starting off with a very basic set of security rules that you will need to keep in mind in order to maintain a secure list of users and password information. Without going in to further details, I can’t stress enough the huge mistake that many authentication systems use by limiting the size, type, and strength of a users passwords as well as the mistake of how the information is stored. I plan on analyzing a few preexisting systems and show some fundamental flaws associated with them, and provide tips to help safeguard your data from any unwanted guests.

Please be sure to check back soon, as I will be posting in the next few days.