data encryption

[will]

hi,

i have a SQL table which stores some passwords. how do i encrypt and
decrypt them in C# (see the catch below)?

the catch is, i'm assuming a worst case scenario where the whole web
server and SQL server have been compromised, so the intruder have access
to all the codes and tables.

so how do most online companies protect our credit card numbers? how do
they prevent an intruder to do:

SELECT encrypted_pass FROM some_db;
while (encrypted_pass is still coming thru)
{
FUNCTION.DECRYPT(encrypted_pass);
}

with C#'s IL, a compiled dll can easily be decompiled, even with a
obfuscator, it is still easy to spot some of the text.

however, in the above scenario, the intruder doesn't even need to know
what FUNCTION.DECRYPT() does, he just needs to run it.

any advice?

thanks

will.

 

[Justin Rogers]

You kind of have to assume that something is going to be *safe* or *protected*.
If you are doing
encryption of something like credit card numbers, then there has to be a method
of decrypting those
passwords using some secret information. If this secret information is
compromised then you get
screwed.

If I were you, I would use the login/password of the user as my *secret*. Here
is an example model
from start to finish that allows a user to create a new account, save their
credit card information, then
come back and use my site at some later date. Note that only the user can ever
retrieve the credit
card information because you need their password to gain access to the *secret*.

1. Have the user initiate an SSL session with your web server.
2. Allow the user to select a username/password combo.
3. Hash the password and store that in the database. Never store the password
itself.
4. User inputs credit information. Either have them re-give you the password
for this step so you can
encrypt the credit card, or have them give it to you during the same session so
the password is still
available. You need to watch that the password isn't available for long periods
of time, meaning somewhere
in memory, because that can be bad. That is why I suggest them giving it to you
again, obviously over SSL
as before.

1. User comes back to site and logs in. Hash the password and check the hash
versus the user.
2. If the user orders something, have them give you their password again during
the order processing step
so you can decode it long enough to establish a connection with your merchant
account system. Again,
throw the password out and the credit card number as soon as possible.

This is all really hard in managed code. Any strings are stored in a string
table, so you need to work with everything
in a byte array format so that it never manifests as an actual string in the
string table which can quickly be dumped
and inspected by anyone with a debugger attached. If they do have a debugger
attached they can do a lot more damage,
so you really need to set up physical security if you are going to be processing
user's credit cards.

A lot of small company systems do something with purging credit records from the
database every evening and doing a
hard copy back-up. Next time you place your order, they simply let you place it
then run the credit cards by hand. If you
have a good merchant account system, then sometimes they let you set up
profiles, so that you can create a customer profile
on their system and let them handle the security of saving the credit card
numbers. Next time the user places an order you
simply use the profile ID. Since the money only goes into your account and
can't be re-routed, if someone does commit fraud
using the system, the money is always in your account to repay the user. You
have so many options, and I'd say leave it up
to a secure merchant system to provide you with security rather than doing it
yourself.

 

[José Joye]

Really interesting!

José

You kind of have to assume that something is going to be *safe* or *protected*.
If you are doing
encryption of something like credit card numbers, then there has to be a method
of decrypting those
passwords using some secret information. If this secret information is
compromised then you get
screwed.

If I were you, I would use the login/password of the user as my *secret*. Here
is an example model
from start to finish that allows a user to create a new account, save their
credit card information, then
come back and use my site at some later date. Note that only the user can ever
retrieve the credit
card information because you need their password to gain access to the *secret*.

1. Have the user initiate an SSL session with your web server.
2. Allow the user to select a username/password combo.
3. Hash the password and store that in the database. Never store the password
itself.
4. User inputs credit information. Either have them re-give you the password
for this step so you can
encrypt the credit card, or have them give it to you during the same session so
the password is still
available. You need to watch that the password isn't available for long periods
of time, meaning somewhere
in memory, because that can be bad. That is why I suggest them giving it to you
again, obviously over SSL
as before.

1. User comes back to site and logs in. Hash the password and check the hash
versus the user.
2. If the user orders something, have them give you their password again during
the order processing step
so you can decode it long enough to establish a connection with your merchant
account system. Again,
throw the password out and the credit card number as soon as possible.

This is all really hard in managed code. Any strings are stored in a string
table, so you need to work with everything
in a byte array format so that it never manifests as an actual string in the
string table which can quickly be dumped
and inspected by anyone with a debugger attached. If they do have a debugger
attached they can do a lot more damage,
so you really need to set up physical security if you are going to be processing
user's credit cards.

A lot of small company systems do something with purging credit records from the
database every evening and doing a
hard copy back-up. Next time you place your order, they simply let you place it
then run the credit cards by hand. If you
have a good merchant account system, then sometimes they let you set up
profiles, so that you can create a customer profile
on their system and let them handle the security of saving the credit card
numbers. Next time the user places an order you
simply use the profile ID. Since the money only goes into your account and
can't be re-routed, if someone does commit fraud
using the system, the money is always in your account to repay the user. You
have so many options, and I'd say leave it up
to a secure merchant system to provide you with security rather than doing it
yourself.