Security - Best Encryption Tool

[gaurav khanna]

Hi

I need to store the credit card information in my database. I have
been looking for some third party tools which could provide encryption
for credit card numbers.

The help I need is:

a) What is the most secure encryption tool that can be used to store
credit card information?

b) Any tool which implements AES and does not expect a private key to
be supplied as shown in the sample application provided by
Microsoft. But in this case customize tool needs to be provided as
anybody can buy the tool and decrypt the information.

c) What is the best way to secure a private key used by the
algorithm like storing in RAM, registry, isolated storage etc? And
how to implement it.

d) If some code implementation, which allows encrypting securely
is available.


The client is ready to invest in Third Party Tool.
I short listed two third party .Net components for encryption:

Chilkat Software (http://www.chilkatsoft.com/dotNetCrypt.asp)

ezCrypto .NET (http://www.componentsource.com/Cata...S&PO=514745&option=10444&RC=FCSR&POS=1&bhcp=1
)


Both the above are c# implemented tools and implement AES algorithm.

But the problem is both ask for private key to be supplied. And I need
to store the private key in a secure manner.


The work round I decided was to use the dll provided by the tool.
Write some login to generate dynamically private key for each of the
registered users based on his profile. Store this logic in a dll and
some how secure this logic, so that no body is able to access it. But
how to secure the logic is a concern, as dll can also be hacked to
view its contents.

One option I was looking at was to use isolated storage as provided by
..Net.
But I'm not sure can we store and access a dll using isolated storage.


It would be great if somebody can help me with the above problem.

Regards
Gaurav

 

[Ken Halter]

vb.general isn't for VB.Net

 

[Schmidt]

The work round I decided was to use the dll provided by the tool.
Write some login to generate dynamically private key for each of the
registered users based on his profile. Store this logic in a dll and
some how secure this logic, so that no body is able to access it. But
how to secure the logic is a concern, as dll can also be hacked to
view its contents.

You should use the Login-Password (PW) and do a SHA1(PW & SomeFixedKey).
This SHA1-Value shouldn't made persistent, so it only exists in Memory and
can be used as private Key for en-/decrypting CreditCard-Info.
Changing the User-PW should be done with a transaction:
1. Show Dlg to get the old and the new PW (new PW twice).
2. Check, if NewPW1=NewPW2.
3. Check against your UserDatabase, that SHA1(OldPW)=CurrentPWInDataBase.
4. If succesful, then decrypt creditcard-info with SHA1(OldPW &
SomeFixedKey) as the private key.
5. Encrypt creditcard-info with SHA1(NewPW & SomeFixedKey) as the private
key.
6. Store the new PW and encrypted creditcard-info in the DataBase.
7. If no error inside transaction then commit else rollback.

For secure encryption a simple RC4 should do it with a 160Bit (SHA1-hashed)
Private Key.

Sub ArcFour(B() As Byte, BK() As Byte) '16 MB/sec on PIII 1 GHz
Dim i&, j&, k&, UB&, CC&, X As Byte, C(255) As Byte, T(255) As Byte
On Error Resume Next
UB = UBound(B): CC = UBound(BK) + 1
If Err Then Err.Clear: Exit Sub
On Error GoTo 0
'Init Key-Arrays
For i = 0 To 255: C(i) = i: T(i) = BK(i Mod CC): Next
For i = 0 To 255
j = (j + C(i) + T(i)) Mod 256
X = C(i): C(i) = C(j): C(j) = X
Next i
'Crypt
i = 0: j = 0
For k = 0 To UB
i = (i + 1) Mod 256: j = (j + C(i)) Mod 256
X = C(i): C(i) = C(j): C(j) = X
B(k) = B(k) Xor C((CInt(C(i)) + C(j)) Mod 256)
Next k
End Sub

usage then:
Private Function EncryptCreditcardInfo$(CI as String, PK as String)
Dim B() as Byte
B=Strconv(SHA1HexString(CI) & CI, vbFromUnicode)
ArcFour B, SHA1Bytes(PK)
EncryptCreditcardInfo = StrConv(B, vbUnicode)
End Function

Private Function DecryptCreditcardInfo$(eCI as String, PK as String)
Dim B() as Byte
B=Strconv(eCI, vbFromUnicode)
ArcFour B, SHA1Bytes(PK)
DecryptCreditcardInfo = Mid$(StrConv(B, vbUnicode), 41)
End Function

Olaf

 

[Alek Davis]

Guarav,

If you go with Olaf's suggestion (deriving encryption key from the user's
password hash), make sure that the password is protected within a session (I
assume that the user does not enter password on the page which uses the
credit card number). Also, take a look at CipherSafe.NET
(http://www.obviex.com/ciphersafe/); it can give you some ideas.

Alek

 

[Svein Terje Gaup]

Why not use DPAPI?

This article describes how to create a DPAPI ibrary:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetsec/html/SecNetHT07.asp

If you use the User store, then only the user that encrypted the data can
decrypt it on the same machine:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetsec/html/SecNetHT09.asp

If you use the Machine store, then the encrypted data can only be decryped
on the same server:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetsec/html/SecNetHT08.asp

Sincerely
Svein Terje Gaup

 

[Alek Davis]

Svein,

DPAPI with user store cannot be used from an ASP.NET application unless you
want to implement the encryption architecture using enterprise services (as
described in the document you reference). In addition to being a somewhat
hassle-prone, this approach posses other challenges, like authorization and
performance. If you use DPAPI encryption with machine store and your machine
crashes (or you move the application to a different machine, or run it on a
server farm, or [fill in the blank]) you will not be able to decrypt data.
This is in addition to the risk factor that any application running on the
same (original) machine will be able to decrypt data. These are just the
most obvious problems associated with DPAPI in this scenario. The bottom
line is that while DPAPI can be the best choice in some case, it is clearly
not a good option for encrypting data stored in databases (such as credit
card numbers). That is unless you do not mind not being able to decrypt
data.

Alek

 

[Svein Terje Gaup]

Alek, I see now that you are right, and I stand corrected.

Regards
Svein Terje Gaup

Svein,

DPAPI with user store cannot be used from an ASP.NET application unless you
want to implement the encryption architecture using enterprise services (as
described in the document you reference). In addition to being a somewhat
hassle-prone, this approach posses other challenges, like authorization and
performance. If you use DPAPI encryption with machine store and your machine
crashes (or you move the application to a different machine, or run it on a
server farm, or [fill in the blank]) you will not be able to decrypt data.
This is in addition to the risk factor that any application running on the
same (original) machine will be able to decrypt data. These are just the
most obvious problems associated with DPAPI in this scenario. The bottom
line is that while DPAPI can be the best choice in some case, it is clearly
not a good option for encrypting data stored in databases (such as credit
card numbers). That is unless you do not mind not being able to decrypt
data.

Alek

Why not use DPAPI?

This article describes how to create a DPAPI ibrary:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetsec/html/SecNetHT07.asp

If you use the User store, then only the user that encrypted the data can
decrypt it on the same machine:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetsec/html/SecNetHT09.asp

If you use the Machine store, then the encrypted data can only be decryped
on the same server:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetsec/html/SecNetHT08.asp

Sincerely
Svein Terje Gaup

(http://www.componentsource.com/Cata...APC&sc=CS&PO=514745&option=10444&RC=FCSR&POS=

 

[WJ]

Alek, I see now that you are right, and I stand corrected.

So it is safe to assume that DPAPI solution is best used in small and single
web site environment ?

Thanks

John

 

[Alek Davis]

I don't think it is the issue of small vs. large. There are cases when DPAPI
is simply a very bad choice, such as encryption of data stored in a
database. Whether the application runs on one machine or many machines, it
does not matter. DPAPI can serve best for storing application configuration
settings (in .config file or registry), but again you really need to
understand the limitations and vulnerabilities, because in certain
situations DPAPI is no more secure than its alternatives. There is a
misconception that DPAPI is a silver bullet for data protection, but
unfortunately it is not. In some cases it can be the best option, in other
cases, it is not.

Alek

 

[WJ]

I don't think it is the issue of small vs. large. There are cases when DPAPI
is simply a very bad choice, such as encryption of data stored in a
database.

In this case, yes, DPAPI is not built for this purpose.

DPAPI can serve best for storing application configuration
settings (in .config file or registry)

In my opinion, DPAPI is built for this purpose only. I think it is very
effecitive against internal abuse/hacks.

....understand the limitations and vulnerabilities, because in certain
situations DPAPI is no more secure than its alternatives. There is a
misconception that DPAPI is a silver bullet for data protection, but
unfortunately it is not.

There is no such thing called "absolute secure".

In some cases it can be the best option, in other cases, it is not.

Yes, DPAPI is best used to encrypt sensitive data such as connection string,
user logon id and password for impersonation method and other pieces of data
that is normally hard-coded in configuration files such as the .Net
"web.config" file.

In summary, any encryption logics that requires a secret key to protect the
decryption of its data illegally can be compromised. But I see no other
solution to get away with the secret key storage requirement. As a result,
DPAPI is indeed one of excellent tools for storing sensitive data as
described above. I like its concepts of Machine Store for web applications
and User Store for windows form applications.

John

 

[Alek Davis]

WJ wrote: "I like its [DPAPI] concepts of Machine Store for web applications
and User Store for windows form applications."

Machine Store is not safe. If a hacker manages to get the WRITE access to
any of the folders on a compromised machine, he can drop an application
there which will decrypt any setting encrypted using DPAPI with machine
store. This is not a very far-fetched scenario. DPAPI with user store for
Windows forms-based applications is probably the best option, assuming that
the application is always executed by the same user, which in our
(corporate) environment is not the case. From my experience, the best
candidates for DPAPI with user store are Windows services.

Alek

 

[WJ]

Machine Store is not safe. If a hacker manages to get the WRITE access to
any of the folders on a compromised machine, he can drop an application
there which will decrypt any setting encrypted using DPAPI with machine
store.

This is only possible if one uses Microsoft tool such as the "aspnet_setreg"
to store your data in the registry database. This tool is one example that
MS gave, to avoid this "problem", you will almost have to implement your own
DPAPI (modified) to store your key in other places. However that may be,
system administrator is responsible to lock his server(s) to avoid misshaps.

Cheer

John

 

[Alek Davis]

This is possible if ACLs are not set correctly on every folder under every
virtual directory. Or when a hacker manages to exploit a new vulnerability
in the OS or system services. Or when a hacker is an internal user who
manages to get access to the system or already has access to the system, but
is not supposed to know the application secrets...

I do not want to get into the long discussion, but what I am trying to say
is that if you base your application security on the conditions that the
underlying OS and supporting services are unbreakable and system
administrators never make mistakes, some day you may encounter an unpleasant
surprise. Hopefully you won't, but it cannot be guaranteed, so it is better
to implement the strongest feasible security on all levels: processes,
hardware, and software.

Alek

 

[WJ]

I do not want to get into the long discussion, but what I am trying to say
is that if you base your application security on the conditions that the
underlying OS and supporting services are unbreakable and system
administrators never make mistakes, some day you may encounter an unpleasant
surprise. Hopefully you won't, but it cannot be guaranteed, so it is better
to implement the strongest feasible security on all levels: processes,
hardware, and software.

I do not want to drag this communication too long. But shops paying the
security guys 6 figures, they better be "hardened" ones .

John