kingpukky
asked on
Suggest Encrypt Algorithm
Hi Experts,
We have a little situation here where some security is required and I dont know much about it.
Actually we are developing a product which integrates with another product.
To log into the another product we are given a username and password
Currently in our beta release we store without encryption in a text file. Before we release the product we need to encrypt the password for security.
This password is made available to us during the installation (installshield)
Now we want to encrypt, store this password in a file and decrypt it while logging to the other product. (this we do through c++ application)
I know that since we require to decrypt it again, the security will not be tight, but its ok since we have to stick to the architecture.
Can you experts suggest me how do I do this? Which algorithm to use? And whether any third party (open source) tools are available.
I want to do some hard thinking before I finialise, so If you could provide me with some links to increase my knowledge in this area, that will be great.
Thanks and Regards,
KP
We have a little situation here where some security is required and I dont know much about it.
Actually we are developing a product which integrates with another product.
To log into the another product we are given a username and password
Currently in our beta release we store without encryption in a text file. Before we release the product we need to encrypt the password for security.
This password is made available to us during the installation (installshield)
Now we want to encrypt, store this password in a file and decrypt it while logging to the other product. (this we do through c++ application)
I know that since we require to decrypt it again, the security will not be tight, but its ok since we have to stick to the architecture.
Can you experts suggest me how do I do this? Which algorithm to use? And whether any third party (open source) tools are available.
I want to do some hard thinking before I finialise, so If you could provide me with some links to increase my knowledge in this area, that will be great.
Thanks and Regards,
KP
I'm no programmer, but this site, and this book will be more helpful to a programmer.
http://www.woodmann.com/crackz/
http://www.oreilly.com/catalog/1886411794/
http://www.woodmann.com/crackz/Tutorials/Protect.htm#pavolcerven
If the password is stored in the machine code, it would be viewable with a simple disassembler or debugger, IDA Pro, SoftIce etc... Perhaps the book and links will give you some better ideas on how to store the data.
-rich
http://www.woodmann.com/crackz/
http://www.oreilly.com/catalog/1886411794/
http://www.woodmann.com/crackz/Tutorials/Protect.htm#pavolcerven
If the password is stored in the machine code, it would be viewable with a simple disassembler or debugger, IDA Pro, SoftIce etc... Perhaps the book and links will give you some better ideas on how to store the data.
-rich
ASKER
jakopriit : I am not quite clear of your solution. We have c++ applications which pick up the password from the file and decrypt it and login, how do we handle that?
richrumble: I am going thru the sites for info....
richrumble: I am going thru the sites for info....
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
I would certainly suggest going with a 3rd party encryption method/module. Designing your own, especially when your not completely comfortable with the subject, has a very strong chance of ending up in an insecure implementation. Even commercial products from respected vendors have vulnerabilities, if you don't know exactly what you're doing it's much safer to use a tried and tested product. Just make sure that the implementation you're going for uses a well-known and tested algorithm, if they use a proprietary algorithm and its secureness is based on it being secret (security by obscurity), stay away. jakopriit provided a good list of well known algorithms, they all have their pros and cons.
ASKER
jakopriit : Thnx for the in brief explaination.
I understood ur options. Have got some queries in it.
1. When you say that you ask the user his own password and use it for symmetric encryption, do u mean that i should use his password as a encryption key or just for authentication for the process.
2. Also the thing is that we get the password of the intergrated product and store it in the file. And after this there is no user interaction, our c++ application read the username/password to login to the product. So your statement "you might ask for the password again" cannot be used.
Also, once the password is stored in the file, our product can be stopped / started anytime, so "trust the session isn't compromised" is not valid too. So does it means that my key has to be hard-coded in my program?
CoccoBill: You are right, this is not going to be so easy. I have started reading basics of cryptology and will especifically concentrate on the algos specified by jakopriit.
I understood ur options. Have got some queries in it.
1. When you say that you ask the user his own password and use it for symmetric encryption, do u mean that i should use his password as a encryption key or just for authentication for the process.
2. Also the thing is that we get the password of the intergrated product and store it in the file. And after this there is no user interaction, our c++ application read the username/password to login to the product. So your statement "you might ask for the password again" cannot be used.
Also, once the password is stored in the file, our product can be stopped / started anytime, so "trust the session isn't compromised" is not valid too. So does it means that my key has to be hard-coded in my program?
CoccoBill: You are right, this is not going to be so easy. I have started reading basics of cryptology and will especifically concentrate on the algos specified by jakopriit.
1. good point. not the password itself. I should have mentioned that too. It would be better to use something _computed_ from the password, as a key. Maybe a one way hash with enough possible values to make rainbow tables unpractical -- you can preach users whatever you want to but they still reuse passwords. Without user interaction that is of little consequence anyway - on to the second point.
2. oh. the lack of interactiveness complicates matters greatly. on the other hand it makes it easier -- depending on what you'll have to prevent. hard-coding encryption keys is a bad habit, anyhow ;) What I would do to prevent hardcoding these, is to rely somewhat on filesystem ACL and have a SUID encryption handling component that has proper file access to the private key, it's access password and the encrypted file. That would leave you the option of replacing them, when necessary.
Please remember that the security of your app ought to be proportional to the one that is being guarded. For example, if you're gonna use a XML web service over the plain HTTP, as the other application, it would be overkill to guard the login/passwd as well as we (experts) would like.
2. oh. the lack of interactiveness complicates matters greatly. on the other hand it makes it easier -- depending on what you'll have to prevent. hard-coding encryption keys is a bad habit, anyhow ;) What I would do to prevent hardcoding these, is to rely somewhat on filesystem ACL and have a SUID encryption handling component that has proper file access to the private key, it's access password and the encrypted file. That would leave you the option of replacing them, when necessary.
Please remember that the security of your app ought to be proportional to the one that is being guarded. For example, if you're gonna use a XML web service over the plain HTTP, as the other application, it would be overkill to guard the login/passwd as well as we (experts) would like.
ASKER
Yeah, well looks the security on filesystem is going to be a key point here...
I got ur point on the "computed from password"
can u please explain or redirect me to some link about "one way hash and rainbow tables"??
Thanks a lot for ur comments...
i think now its upto our research here....
I got ur point on the "computed from password"
can u please explain or redirect me to some link about "one way hash and rainbow tables"??
Thanks a lot for ur comments...
i think now its upto our research here....
Heres the article on rainbow tables, basically, you precompute every possible password hash and it's plain-text counter part
https://www.isc2.org/cgi-bin/content.cgi?page=738
pass1234 = MD5 B4AF804009CB036A4CCDC33431
pass1235= MD5 B7E3715214F9EE9B589197D1E6
pass1236= MD5 7826842F8E10191865318AA346
pass1237= MD5 11E3ABF4FDA721E9C26B616159
etc... the storage is much more compressed than the examples above. For instance, the LM passwords for windows using Rainbow Crack's tables are around 64gig's, for 99.9% accuracy of all possible character combinations. OphCrack has a better storage/table search so it's smaller, however the passwords take just as long to find, so no overall benefit.
-rich
https://www.isc2.org/cgi-bin/content.cgi?page=738
pass1234 = MD5 B4AF804009CB036A4CCDC33431
pass1235= MD5 B7E3715214F9EE9B589197D1E6
pass1236= MD5 7826842F8E10191865318AA346
pass1237= MD5 11E3ABF4FDA721E9C26B616159
etc... the storage is much more compressed than the examples above. For instance, the LM passwords for windows using Rainbow Crack's tables are around 64gig's, for 99.9% accuracy of all possible character combinations. OphCrack has a better storage/table search so it's smaller, however the passwords take just as long to find, so no overall benefit.
-rich
Or better yet, give the user a password protected certificate with a key pair and use the users cert and a master cert of your helpdesk people to encrypt the data needing to be protected with an asymmetric algorithm. That way you'll be able to recover whatever data was lost due to the user error.