I am interested in best practices for protecting credit card numbers in a Web-based order-entry system.
Typically, eBay and other online merchants store customers' credit card data to facilitate future purchases. I cannot believe that this data is stored in clear text.
So what are the typical protocols for managing encryption and key management? Is there a separate key for each customer? One key for encrypting/decrypting all data does not seem very secure. Is there some other approach?
Also, I would expect that the passwords are maintained in a 'hashed' form (MD5 or SHA1)? After initial registration, would it be more secure for the Web server to send a nonce along with the request for ID and password? The browser could compute and send MD5(MD5(password) + nonce), which would in essence be a one-time password. The Web server could then compute the comparable value using its stored password hash and the nonce it sent.
I would like to avoid sending 'static' passwords over the Internet. Short of using SecurID or other token-based systems (not good for a business-to-consumer application), this seems like one possible solution.
I have to commend you on your thoughts and designs, but I have to give you some bad news. The practices you're describing are far better than present best practices.
The vast majority of systems aren't using anything sophisticated. For one thing, they are storing the full password for each user. How else can they mail it back to you when you forget it? I find it a relief myself when the password is sent over SSL. There are far too many systems that don't even do that. Others, like eBay, support SSL, but make you go to extra work to get to the SSL.
I'm sure you know that security is a balance. Let's talk about what would be nice to do and what the tradeoffs are.
SSL is in my opinion a must-have for any system that involves real money. I don't think there's an excuse for not using it. Once you do have it, sending a plaintext password over the net is not so bad. You could use the same hash technique you mentioned on your server, so that the server doesn't store clear text passwords.
If you do that, there are things to keep in mind. Small ones are to use SHA-1 rather than MD5, and when you hash the password, hash some salt in, too. Salt is just a constant that you keep per-user. It helps thwart dictionary attacks, should someone get a hold of the database of hashed passwords.
We haven't discussed the threat model at all -- what you're protecting from whom and how much effort you want to spend to do it. I'll touch on both ends quickly. If you want to be able to say that you are encrypting your database, then you encrypt the credit card numbers (and other personal information) with a single key for the whole database, which you store there as well. Only your conscience will know that you didn't do much.
If you go to the other end, you put hardware security modules in your servers. For example, you can use nCipher modules. They cannot only manage the cryptographic keys for your database and make sure that they never leave the module. Some of them can even terminate an SSL link in the card itself, which means that a password sent over the net wouldn't leave the module, either.
However, you said that you didn't want to send static, clear passwords over the net. You can avoid this with SecurID or some other similar system; however, this system doesn't work on most commerce sites because you don't have to supply your customers with tokens, and this isn't really viable. Even a software-only system, like Swivel Secure, is going to require users to do something more than just type in a password. Most customers don't want to deal with much more than typing a password, and that is a huge reason of why no one uses authentication better than passwords on Web-based order entry. Let's face it -- making it hard for people to buy things from you is not the path to profit.
So you have to make tradeoffs, and among them are inconveniencing your customers, getting and maintaining software that runs in the browser, buying hardware security modules or doing without. You don't want to do the latter, of course, so that means that you have to decide what "good" practices you want to follow. I'll bet they're better than the industry's best practices.
This was first published in March 2004