It surprises me how often I see people posting questions about what type of encryption to implement for credit card data. If you are processing credit cards yourself, and storing the data, you need to comply with the PIC regulations that exist. Here’s a good place to get started: https://www.pcisecuritystandards.org/.
Actually the place you need to start is with your bank or processing company. They should be able to guide you in what requirements need to be met for safe data storage.
However if you’re running some service and perhaps trying to store a credit card for a customer to make it easy to charge them over and over, that doesn’t mean you don’t need to comply. You are holding financial information about a customer and if something happens to the data, you’re at fault. Your company could be liable, and possibly even you personally if you make the recommendation to build something yourself.
Good security isn’t magical, and it isn’t secret. It involves you using well known algorithms, protecting the keys, and following best practices. There are some great encryption technologies in SQL Server 2005/SQL Server 2008, but don’t just implement them without learning a few things about what best practices are and how these technologies work.
Tag: security
-
PCI and Encryption
-
Should You Write Down Your Passwords?
According to Jesper Johansson, senior security program manager at Microsoft, the security industry is giving out the wrong advice by forbidding people to write down their passwords. Strong passwords are impossible to remember and lead to people picking easy passwords or using the same password across all the systems that they access.
And using the same password across all systems us poor security. I tend to agree with that in most cases because if one system is compromised then all of them are. However, for the administrators, it’s problematic if all systems have different passwords. Then the cost (in time) of administering these systems goes up. I admit that in most of my jobs I’ve used the same sa password on all servers and the same administrator password on all systems. The caveat is that we change those passwords often, usually every 30 days and always when an administrator leaves. While a security breach would leave all systems vulnerable, the window of opportunity is fairly small.
Bruce Schneier says that it’s impossible to remember strong passwords. And now password cracking programs are hip to the 3 for e and 0 for o replacements (and others). Plus with distributed cracking programs and cheap hardware, it takes less and less time to crack passwords for anyone that truly wants to get at your systems.
That’s quite a quandry for people. To me there are two problems we are trying to solve. One is protecting systems for the administrators.These are more techincally competent people and should be required to build stronger passwords. The system that I liked the best over the years was the central storage of all our administrator passwords (Windows Admin, SQL, Exchange, service accounts, etc.) in a central storage file. We used Password Safe for this on a network share accessable to administrators only. We changed the file password periodically and scripted changes of the various passwords every 30 days. Usually we’d solicit some theme and assign an administrator to change the passwords.The other problem is how to get users to create and deal with complex passwords. Of all the suggestions that I’ve seen, I think writing them down is a good idea. Make stringent requirements, 12 characters, mixed case, numbers, etc., require changes often, but allow them to write them down. Not on sticky notes, not posted, but maybe a card that they keep in their wallet or purse. Or these days, maybe their cell phone.
Now if we could just somehow secure your cell phones. Maybe outlaw Bluetooth
Steve Jones
