DISCLAIMER storing CC numbers is a bad idea - however I'll review your security protocols below.
This article will give you some good information on mean time to crack
This article provides some good ideas on password verifycation.
Basically force the short password to contain at least on ove the following upper case letter, lower case letter, number, special character and force the user to at least 8 characters. This has a huge mean time to crack, which following methods in the second linked article you can make even longer.
3. customer enters credit card (behind SSL of course). number is encrypted using a GPG decrypt function, using "sender@server.com" as the sender and recipient@server.com as the recipient. resulting blob of encrypted data is stored in mysql database.
The casual browser who visits your site can tell that this is encrypted data right away. You're better off to make it look like it's not encrypted at all, or at least make it look like it's not encrypted when it still is. Keep doing what you're doing, but first:
1) Split the cc# into an array of 2 digit numbers (00 - 99)
2) Come up with a keyed cipher (use their name or something as the key) that will map each of these 100 entries to a different entry.
3) Use your current methods to encrypt this already encrypted cc#, so if the cracker manages to get through your initial protocols they think they have a valid cc#, when in fact they do not.
4. merchant logs into admin center using recipient@server.com's passphrase (for consistency's sake), which is md5'd and compared with a stored hash. the passphrase is NOT stored as a session variable.
This all sounds reasonable, so long as you follow the rules in point 1 for allowing the user to choose their password.
5. merchant clicks on an order and is asked again for the passphrase. he has to enter the passphrase every single time he wants to view an order, as i refuse to store it as a cookie or as a session variable.
Well you can store something (not the passphrase but a user id) in a cookie or session variable, but then you have to make sure session highjacking isn't possible. The best way to do this is
1) Create a token (probably md5 their username and a timestamp) when the first log in
2) Store the token in their db record and as a cookie (which expires in like 1/2 hour)
3) when they visit a protected page compare their stored token to their cookie token. If the tokens match generate and store a new token. If the tokens do not match then consider them not logged in.
However this method does leave you suseptible (in a small way) to session fixation but the cracker would have to fixate the session, then get the user's token and use the token before it expiered or the user visited another page on the site.
6. merchant deletes the credit card portion of the database once he runs the number and ships the order.
Good idea - but don't count on this happening if it's a manual process.
7. not yet done: my home computer (mac os x) logs in incrementally to compare md5 hashes of several files, ensuring me that no one's tampered with the scripts.
Good idea
