I was hoping someone could help me sort something out. I’ve been working on a shopping cart plugin for WordPress for quite a while now. I started coding it at the end of 2008 (and it’s been one of those “work on it when I have time” projects, so the going is very slow, obviously!) and got pretty far with it. Even had a few testers take me up on it and give me feedback. (Please note that this plugin is also meant to be a fee download – I have no intention of making it a premium plugin.)
Anyway, in 2010, when all the PCI/DSS stuff became standard, I shelved it, because the plugin was meant to retain certain information in the database, and I was not 100% sure what qualified as “sensitive data,” and I didn’t want to put anything out there that might compromise anyone, and possibly come back on me.
Over the last few weeks, some colleagues and I have been having a discussion about PCI/DSS compliance, and it’s sparked a re-interest in finally finishing this plugin. I’m going to remove the storage of credit card numbers and any data of that nature, but I do like the idea of storing the names and shipping addresses of people who voluntarily might want to create an account with the site that might use this plugin so if they shop there again, that kind of info is retained. Keep in mind, the data stored would be public information – the kind of thing you’d find in a phone book, or a peek in the record room of a courthouse. So nothing like storing SS#’s, medical histories or credit card numbers. Just stuff that would maybe let someone see past purchases, and retain some info to make a future checkout process a bit easier.
One of my colleagues suggested I still do something to enhance security a bit, since the name and shipping address would likely be passed to whatever payment gateway the site owner would choose to use. They suggested I use “one-way encryption.” Now, I’m not a huge security freak, but I’m pretty sure this involves (one aspect anyway) stuff like MD5 hashes with salts, or the like. So this confuses me, because I wouldn’t have the slightest idea of where to look to see how to use that kind of thing with my code, and/or if it will work when passing that kind of data to PayPal or Google Checkout, or Mal’s, or what have you.
So I suppose this isn’t an “I need code examples” kind of question, but more of a “please enlighten me, because I’m sort of a dunce” kind of question. (which, I’m sure, makes people feel much better about the fact that I’m writing a shopping cart plugin LOL)
One way encryption is used to store information in the database that you don’t need back out of the database again in its unencrypted stage (hence the one-way moniker). It could, in a more general sense, be used to demonstrate that two different people (or systems) are in possession of the same piece of data. Git, for instance, uses hashes to check if files (and indeed entire directory structures) are identical.
Generally in an ecomm contect hashes are used for passwords (and sometimes credit cards) because as the site owner, you don’t need to retain the actual password, you just need a function to be able to determine if the password currently being sent by the user is the same as the one previously provided. So in order to authenticate a user you would pass the password provided through the encryption algorithm (MD5, SHA, etc) in order to get a ‘hash’. If the hash matches the hash previously generated and stored in the database, you know the password is the same.
WordPress uses salted hashes to store it’s passwords. If you open up your wp_users table in the database you’ll see the hashes.
Upside to this system is that if someone steals your database, they don’t get the original passwords, just the hash values which the thief can’t then use to log in to your users’ Facebook, banking, etc sites (if your user has used the same password). Actually, they can’t even use the hashes to log in to the site they were stolen from as hashing a hash produces a different hash.
The salt provides a measure of protection against dictionary attacks on the hash. There are databases available of mappings between common passwords and hash values where the hash values have been generated by regularly used one way hash functions. If, when generating the hash, you tack a salt value on to the end of your password string (eg my password becomes abc123salt), you can still do the comparison against the hash value you’ve previously generated and stored if you use the same salt value each time.
You wouldn’t one way hash something like an address or phone number (or something along those lines) if you need to use it in the future again in its raw form, say to for instance pre-populate a checkout field for a logged in user.
Best practices would also involve just not storing data that you don’t need again in the future, if you don’t need the phone number in the future, don’t store it. If you store the response transaction number from the payment gateway, you can use this for fraud investigations and leave the storage of all of the other data up to the gateway.
I’ll leave it to others to discuss the relative merits of MD5 vs. SHA vs ??? hashing systems. Note, there’s functions built in to PHP to do the hashing.