I don’t understand why the government, CC companies and others get together and set some strict guidelines on the handling of these numbers with jail time for non-conformers.
Everytime there is an ‘incident’ it just reinforces in the minds of the public that this is not a safe way to do business on the Internet and ecommerce penetration is set back x amount of time.
Every time there is a ‘incident’ millions of $ in consumer confidence is lost.
I know I can keep my card safe but if the number can be comprimised by the card ISSUER (or some website on the Internet that is programmed by amatures), I am not sure this is a safe way to do business.
With Google getting into online payment systems maybe Paypal will have some competition and services will improve. I can only hope that they will have some secure way of keeping these numbers safe and then I can then be free to make purchases online.
Someone here is also keeping International Bank Account numbers, passport information and other personal financial info. Scary.
After reading this thread I know I will NEVER give my CC number out to anyone other than Paypal because I know that is far too likely that the site is not secure.
For me to use my CC number online there has to be a good 10 years free of these little ‘incidents’. I suspect there are a lot of people like me.
I have a service with my bank (they call it e-card) that creates temporary credit card numbers with a specific withdrawal limit on them, designed for internet shopping. It’s a really handy service. See if your bank offers it.
I have given it to Amazon in the past but after the most recent loss of CC information I have lost confidence in CC’s. I’ll use paypal and whatever Google comes up with.
See I’m the opposite way. I know how Amazon stores my CC number and I comfortable with it. I am not comfortable with the fact that PayPal randomly just pulls up charges or closes people’s accounts.
thx so far for all you opions and information.
I am trying to picture it first and simplfy it for myself. Now bare with me, my geekdom isn’t that high
Questions and thinkpath
About Mattias solution: computer(A) is not connect to the Internet, but is connected to the server(B) in some way by a dedicated port/connection (vpn???)???
But how do we get all the user data to computer(A)?? Would it be something
to store the user data first on server(B) by SSL in combo with Longneck solution. If there is activity(new insert) on server(B) immediately send a signal from server(B) to computer(A) which will activate a little program.
This program would download user data from server(B) to computer(A) and delete afterwards the data on server(B)??
Basically, when you send a cc number to the motel(a), you just send it via web service. I don’t really see the need for anything more fancy. It’s never stored on the web server (b), just temporarily handled by it. The motel DOES have an internet connection, by the way - it’s just very, very locked down - essentially just limited to accessing and being accessed by the IP of the payment gateway.
What if you simply encrypt the CC numbers using the password of the user? I.e. store the encrypted CC number in a field in the database, with the users password as the key.
There will always be ways to get around it but if you need to keep them its your job to take as many and the most difficult path to protect them I think.
Yes, that’s a damn cool service!! My bank also has this service, which allows the users to create temp card numbers for online transactions. They can choose the amount to be available for that number. The number can be used a fixed number of times & is valid for 48 hours, after that the balance is transfered back to your account!! That’s really cool but not for services that have a recurring bill system & which bill you automatically after a period of time.
So is it like the key is the users non-hashed password (obtained when the logon through SSL), the password in the database itself is hashed (say with MD5).
The main weakness would be the strength of the users passwords. An attacker would be guranteed to get some CC numbers by simply using rainbow tables and indentifying the encryption. Also, assuming you meant the non-hashed version of the password, how do you keep that? In a session? The key is still easily accessible (at least, the way I am imagining it).
There are some old good ways like: minimum password length increased, various password complexity checks, user account lockout after one or more wrong passwords, password history, user logins allowed from one or more IP addresses/networks only, etc.
There are some old good ways like: minimum password length increased, various password complexity checks, user account lockout after one or more wrong passwords, password history, user logins allowed from one or more IP addresses/networks only, etc.
Rainbow tables can crack complex 7-character passwords without significant difficulty. You’d need 13 to 20 character non-dictionary passwords to defend yourself from rainbow tables.
Ryan, do you believe it is possible to use some kind of non-standard salt (preferaby computationally expensive) on the hash to prevent practical use of rainbow tables?
Then again, a CC motel is not vulnerable in this way, as the actual numbers never come out of it.
Also, assuming you meant the non-hashed version of the password, how do you keep that? In a session?
Yes, I’m referring to using the non-hashed password as the key. I’d imagine that storing it in a session would result in no significant security risks?
The key is still easily accessible (at least, the way I am imagining it).
This part of your post, I don’t get. The key for encrypting the cc numbers IS the users password. There is no other key involved.
If you use the non-hashed(& non-encrypted) password as the key to encrypt the CC numbers then that means that the passwords wouldn’t be 1-way hashes as you’d be storing them as encrypted in the database & would need to decrypt them to obtain the key to decrypt the CC numbers. then wouldn’t the same risk apply here as in the case of encrypting CC numbers with a common key? I mean that passwords would be decrypted easily and then decrypting CC numbers would be a milk-run!! Unless ofcourse you are thinking of encrypting passwords in the same way as CC numbers, ie., using another value as key for password encryption/decryption!!
That’s really cool but not for services that have a recurring bill system & which bill you automatically after a period of time.
I mean that passwords would be decrypted easily and then decrypting CC numbers would be a milk-run!! 
Unless ofcourse you are thinking of encrypting passwords in the same way as CC numbers, ie., using another value as key for password encryption/decryption!! 