|
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.
If you want to do the password hashing in the browser, you're going to have to implement that half of the protocol in JavaScript and make sure it runs correctly on a dozen different browsers, which is why it's not usually done.
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.
|
