Which brings me to Jimmy John's website.
Do NOT store your credit card information on this website, and usually not on any website to be sure.
So what exactly has gotten me riled up? Password resetting. It's a direct tell of how a website stores your information. I had previously ordered a tasty sandwich online, but forgot my password. So I clicked the forgotten password button and my email dinged. Now comes the best part, the password was in plain text - it was readable just as if I had typed it into an office document. Good security management is when a company sends you an email with a link to reset your password. You can get even better with security questions, but we're just ordering a sandwich here!
This tells me that they are not using hashed passwords. Anyone who stores passwords in the clear like this, should be kicked back to web development 101.
What is a hash? Simply put, think of it as a math equation where you input some text or data, in this case a password, and then out comes a fixed length mix mash of alphanumeric characters. Theoritically, the hash itself should not be able to take you back to the original password; more on that a little later.
Amateur level
User enters a password onto a website -> Database on website stores password in plain text
At the amateur level, if anyone compromises the database, they have it all. Also, the website developers and pretty much everyone at the company, can easily read your password. Pathetic job at security here.
Intermediate Level
User enters a password onto a website -> Database on website stores password as a hash
Works well at this level, but a lot of improvement is needed. If this equation is done right, even if someone steals the hashed passwords, they still wouldn't know what your password is.
There's something very wrong with this level though. If someone is trying to discover your password to gain access, they will use a rainbow table. Think of this as a massive spreadsheet with every popular password and common combination of words and phrases. In the first column is the plain text, and in the next column is the hashed value using the most common hashing algorithms. Now if they find your password hash in the second column, they can simply match it up to your original password. You would be surprised how easily this will crack popular passwords even though it takes a lot of computer horse power to initially run and the hash hasn't been technically compromised.
Advanced Level
User enters a password onto a website -> Database on website adds random data to password and then stores it as a hash
All we need is a little bit salt. This isn't a tasty seasoning, it's a bit of subterfuge. You hash the password just like the intermediate level, but you don't just use the plain text a user enters into the website. You mix it with something unique, or a salt. One simple example is to prefix some random text to the password.
Now if someone tries to make a rainbow table to search for your password's hash, as long as the salt is secure, it's not going to happen. This of course isn't the only "salt" you can use, but it provides a good beginning example.
For instance if I compute the MD5 hash onto the text string "password", I get "5f4dcc3b5aa765d61d8327deb882cf99" (minus the quotes). Try doing a Google search with that hash. The "password" phrase comes right up. This being such a common password phrase and with no salt, all it takes is a simple search to discover the original password.
Dash on a little salt, let's say "5^Lt" so we now have, "5^Ltpassword" and we get,
"faf50047e2d20a2afd699cdeed7cacdd". Do a search for that and you get ... nothing!
To be truly effective, the salt should be a secret that only very few people know. Whenever someone wants to log in to a website, they type in a password phrase and then only the computer secretly applies the salt and verifies if it's correct.
So if someone is storing your password, the only piece of information that verifies your identity, as
"password"
compared to
"faf50047e2d20a2afd699cdeed7cacdd"
who are you going to trust with your credit card and personal information?
Jimmy John's can make a tasty lunch, but they get no confidence from me when dealing with personal information. From now on, I'll pay at the counter.
Some references,
Ruby Digest Standard Library
http://www.ruby-doc.org/stdlib-1.9.3/libdoc/digest/rdoc/Digest.html
Hash Functions in more depth
http://en.wikipedia.org/wiki/Cryptographic_hash_function
For the curious I'm using Ruby to compute md5 hashes.
require 'digest'
Digest::MD5.hexdigest("password")
=> "5f4dcc3b5aa765d61d8327deb882cf99"
Also of note, MD5 isn't the ideal hash function. It is possible to break with brute force and for added security, and complexity, most commercial websites are going to use the SHA-2 hash.
No comments:
Post a Comment