Hide password decryption
-
Hi everybody, We have to store a password that we use to access an encryption certificate in the configuration of our application (it is an automated process, so we cannot ask a user for a password). We have done this for many years, using our own enceryption / decryption algorithm. The decryption would be coded in the software itself and not in a dll, so that it would not be easily accesible to others. Since we are moving the software from C++ to C# however, the easy possibilities of reverse engineering, make it an easy task for outsiders to find the used algorithm and consequently to decrypt the password, which would then give them access to the certificates used. Does anyone have an idea of a means of incorporating routines in a c# program that cannot be easily reverse engineered (of course, if one goes through the hassle of viewing the assembly, it would always be possible to find-out, but this is a such an effort that we feel we can take that risk) Many thanks in advance, William
-
Hi everybody, We have to store a password that we use to access an encryption certificate in the configuration of our application (it is an automated process, so we cannot ask a user for a password). We have done this for many years, using our own enceryption / decryption algorithm. The decryption would be coded in the software itself and not in a dll, so that it would not be easily accesible to others. Since we are moving the software from C++ to C# however, the easy possibilities of reverse engineering, make it an easy task for outsiders to find the used algorithm and consequently to decrypt the password, which would then give them access to the certificates used. Does anyone have an idea of a means of incorporating routines in a c# program that cannot be easily reverse engineered (of course, if one goes through the hassle of viewing the assembly, it would always be possible to find-out, but this is a such an effort that we feel we can take that risk) Many thanks in advance, William
-
Obfuscation? If it is for a company there is a lot of software that exists that can make it a lot harder to reverse.
Thanks a lot. I did not even know the word before, but google provides some very interesting links! William
-
Thanks a lot. I did not even know the word before, but google provides some very interesting links! William
-
Hi everybody, We have to store a password that we use to access an encryption certificate in the configuration of our application (it is an automated process, so we cannot ask a user for a password). We have done this for many years, using our own enceryption / decryption algorithm. The decryption would be coded in the software itself and not in a dll, so that it would not be easily accesible to others. Since we are moving the software from C++ to C# however, the easy possibilities of reverse engineering, make it an easy task for outsiders to find the used algorithm and consequently to decrypt the password, which would then give them access to the certificates used. Does anyone have an idea of a means of incorporating routines in a c# program that cannot be easily reverse engineered (of course, if one goes through the hassle of viewing the assembly, it would always be possible to find-out, but this is a such an effort that we feel we can take that risk) Many thanks in advance, William
If they key and process are stored in the same place the scheme is broken and will no hold up to any determined attack. You need a method to remove the key from the process, period. Without asking a user for a password the next best thing is the windows certificate store, after that physical token verification. Unfortunately, it sounds like you are trying to protect your certificates from your users so asking them to have the keys to the kingdom is also not secure. If that is the case then the application should only contain the public key. As such the important piece, the private key, can be kept secure in your own location.
Need software developed? Offering C# development all over the United States, ERL GLOBAL, Inc is the only call you will have to make.
If you don't ask questions the answers won't stand in your way.
Most of this sig is for Google, not ego. -
If they key and process are stored in the same place the scheme is broken and will no hold up to any determined attack. You need a method to remove the key from the process, period. Without asking a user for a password the next best thing is the windows certificate store, after that physical token verification. Unfortunately, it sounds like you are trying to protect your certificates from your users so asking them to have the keys to the kingdom is also not secure. If that is the case then the application should only contain the public key. As such the important piece, the private key, can be kept secure in your own location.
Need software developed? Offering C# development all over the United States, ERL GLOBAL, Inc is the only call you will have to make.
If you don't ask questions the answers won't stand in your way.
Most of this sig is for Google, not ego.The keys are stored in the certificate, which is in the windows certificate store. This means that they are separated from the process. However, in order to get access to the crtificate, a password is required. We are not trying to deny the users access to this certificate, but since the relevant process is running as an unattended process, there is no user to ask for the password. We therefore store this password in a separate file, but we want to avoid a readable password to be around somewhere on the system, so we encrypt this password, using an algorithm that does not require any further keys. However, we want to keep the decryption process as secret as we can, which is why the reverse-engineering possibility of c# is a bother.
-
The keys are stored in the certificate, which is in the windows certificate store. This means that they are separated from the process. However, in order to get access to the crtificate, a password is required. We are not trying to deny the users access to this certificate, but since the relevant process is running as an unattended process, there is no user to ask for the password. We therefore store this password in a separate file, but we want to avoid a readable password to be around somewhere on the system, so we encrypt this password, using an algorithm that does not require any further keys. However, we want to keep the decryption process as secret as we can, which is why the reverse-engineering possibility of c# is a bother.
Can you not just export the certificate's public key without a password? I thought only the private key needed the password?
Need software developed? Offering C# development all over the United States, ERL GLOBAL, Inc is the only call you will have to make.
If you don't ask questions the answers won't stand in your way.
Most of this sig is for Google, not ego. -
Hi everybody, We have to store a password that we use to access an encryption certificate in the configuration of our application (it is an automated process, so we cannot ask a user for a password). We have done this for many years, using our own enceryption / decryption algorithm. The decryption would be coded in the software itself and not in a dll, so that it would not be easily accesible to others. Since we are moving the software from C++ to C# however, the easy possibilities of reverse engineering, make it an easy task for outsiders to find the used algorithm and consequently to decrypt the password, which would then give them access to the certificates used. Does anyone have an idea of a means of incorporating routines in a c# program that cannot be easily reverse engineered (of course, if one goes through the hassle of viewing the assembly, it would always be possible to find-out, but this is a such an effort that we feel we can take that risk) Many thanks in advance, William
Just to throw this out there. You should look up the concept of "Security through Obscurity" and why its a bad idea. To put it simply...the problem with maintaining security through obscurity means your mechanism of security hasn't really been tested. Even if you use obfuscation techniques to maintain your obscurity, eventually someone is going to figure out how to get around it and that someone will put your security algorithms to the test. Given the nature of digital security and based on the wealth of knowledge provided by cryptoanalysts, using a mainstream, thouroughly tested security algorithm is more likely to give you better security than a home-grown solution that has never really, truely been tested. Good mainstream algorithms that have been vetted by the crytoanalyst community have been put through rigorous testing over many years, and are generally prooven to be secure against attack. Just my two cents anyway.