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,
Who is Participating?

[Webinar] Streamline your web hosting managementRegister Today

jakoConnect With a Mentor sysadminCommented:
I should have been more verbose, I know. My first option implies that before your application stores the login/password pair to a file, it asks the user for the password of his/her own (and a confirmation to rule out the typos), it then uses this password to encrypt symmetrically the login/password pair of another product and stores it somewhere, be it a file, a database field, anything. Then, when it is time to do the logging in procedure to the other/integrated product, you might ask for the password again or trust the session isn't compromised and use that newly asked or remembered password to decrypt the file, the database field and use that decrypted data. Symmetric-key algorithms include: Blowfish, Twofish, AES (a.k.a. Rijndael), RC4, TripleDES, IDEA.

the second option is just a bit more complicated but it won't leave the login/password pair uncoverable if the user of your product decides to change the password and forget. it is the beauty of asymmetric encryption that you can later decrypt the data using several different private keys one of which may be in the possession of your own helpdesk people. Most often used asymmetric-key algorithms are: Diffie-Hellmann, RSA, El-Gamal and some elliptic curve techniques.

C++ as a programming language doesn't necessarily play a role here - you could accomplish it in almost any language. What it does mean that using a popular language as C++, makes you probably able to purchase and use ready made objects for actual encryption routines (I know Delphi components are wildly popular merchandise).

You're probably not gonna get by just by slapping something together there. It's gonna be lots and lots of reading for you guys ;)
Give the user of your product a password he/she has to remember and use that to encrypt the password your product uses to log into another using a fairly strong symmetric algorithms.

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.
Rich RumbleSecurity SamuraiCommented:
I'm no programmer, but this site, and this book will be more helpful to a programmer.

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.
Will You Be GDPR Compliant by 5/28/2018?

GDPR? That's a regulation for the European Union. But, if you collect data from customers or employees within the EU, then you need to know about GDPR and make sure your organization is compliant by May 2018. Check out our preparation checklist to make sure you're on track today!

kingpukkyAuthor Commented:
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....
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.
kingpukkyAuthor Commented:
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.
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.
kingpukkyAuthor Commented:
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....
Rich RumbleSecurity SamuraiCommented:
Heres the article on rainbow tables, basically, you precompute every possible password hash and it's plain-text counter part
pass1234 = MD5            B4AF804009CB036A4CCDC33431EF9AC9
pass1235= MD5            B7E3715214F9EE9B589197D1E6912469
pass1236= MD5            7826842F8E10191865318AA3468C8375
pass1237= MD5            11E3ABF4FDA721E9C26B616159D738C7

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.

All Courses

From novice to tech pro — start learning today.