Reputation: 20271

Password encryption in Delphi

I need to store database passwords in a config file. For obvious reasons, I want to encrypt them (preferably with AES). Does anyone know a Delphi implementation that is easy to introduce into an existing project with > 10,000 lines of historically grown (URGH!) source code?

Clarification: Easy means adding the unit to the project, adding max. 5 lines of code where the config file is read and be done with it. Should not take more than 15 minutes.

Another clarification: The password is needed in order to create a connection to the db, not to support a user management scheme for the application. So using hashes does not help. The db engine checks if the password is valid, not the app.

Upvotes: 18

Answers (15)

UnDiUdin

Reputation: 15384

A simple but for most applications strong enough system is given by this Embarcadero's demo: https://edn.embarcadero.com/article/28325

Upvotes: 0

Jeroen Wiert Pluimers

Reputation: 24483

You need to store it in a place where only the current user has acccess too.

Basically there are two ways to do this:

Store it in an EFS encrypted file.
Store it in the secure local storage.

Internet Explorer uses 2. But if you can get local access, you can decrypt both 1. and 2. if you have the right master key and algorithm (for instance, iepv can get at the Internet Explorer passwords).

So:
If you can, avoid storing passwords.
Look for alternatives (like Windows authentication, directory services, etc) first.

--jeroen

Upvotes: 0

Nick

Reputation: 13414

Even if you encrypt, it seems to me that your decryption key as well as the encrypted password will both be in your executable, which means that in no way is just security by obscurity. Anyone can take the decryption key and the encrypted passwords and generate the raw passwords.

What you want is a one-way hash.

Upvotes: 2

user160694

Reputation:

A couple of solutions:

Don't store the password at all. If the database supports integrated authentication, use it. The process can be set to run with a specific identity, and be automatically authenticated by the database
Use Windows certificate stores and a certificate to encrypt your password. If you store the key used to crypt your password in your application, you have very little security anyway, you have to protect the key also.

Upvotes: 0

Sean B. Durkin

Reputation: 12729

TurboPower LockBox 3 (http://lockbox.seanbdurkin.id.au/) uses automatic salting. I recommend against Barton's DCPCrypt because the IV's are not salted. In some situations this is a very serious sercurity flaw.

Contrary to an earlier commment, LB3's implementation of AES is fully compliant with the standard.

Upvotes: 3

Michał Niklas

Reputation: 54302

I reccomend using some type of salt. Do not store crypt(password) in config file, but insted of this store crypt(salt + password). As 'salt' you can use something that is required to open database, eg. db_name+user_name. For crypt function you can use some well known algortithm as AES, Idea, DES, or something as simple as xoring each byte with byte from some other string, that string will be your key. To make it more different to solve you can use some random bytes, and store them.

So to store:

init_str := 5 random bytes
new_password := salt + password // salt := db_name + user_name
crypted_password = xor_bytes(init_str + new_password, 'my keyphrase')
crypted_password := init_str + crypted_password
store crypted_password in config, as this will be bytes you can hexify or base64 it

And to connect:

split data read from config into init_str and crypted_password
new_password = xor_bytes(init_str + crypted_password, 'my keyphrase')
password := remove (db_name + user_name) from new_password

Upvotes: 1

Mihai Limbășan

Reputation: 67576

As others have pointed out, for authentication purposes you should avoid storing the passwords using reversible encryption, i.e. you should only store the password hash and check the hash of the user-supplied password against the hash you have stored. However, that approach has a drawback: it's vulnerable to rainbow table attacks, should an attacker get hold of your password store database.

What you should do is store the hashes of a pre-chosen (and secret) salt value + the password. I.e., concatenate the salt and the password, hash the result, and store this hash. When authenticating, do the same - concatenate your salt value and the user-supplied password, hash, then check for equality. This makes rainbow table attacks unfeasible.

Of course, if the user send passwords across the network (for example, if you're working on a web or client-server application), then you should not send the password in clear text across, so instead of storing hash(salt + password) you should store and check against hash(salt + hash(password)), and have your client pre-hash the user-supplied password and send that one across the network. This protects your user's password as well, should the user (as many do) re-use the same password for multiple purposes.

Upvotes: 1

Steve

Reputation: 6460

I've always user Turbopower Lockbox. It works well, and very easy to use. I actually use it for exactly the same thing, storing a password in a config text file.

http://sourceforge.net/projects/tplockbox/

Upvotes: 3

DonOctavioDelFlores

Reputation: 363

Just a reminder.

If you don´t need to interoperate with others crypt libs, then DCP or LockBox would do the job.

BUT

if you need it to be fully compliant with the rinjdael specs, forget free components, they´re kinda "lousy" most of the time.

Upvotes: 1

Allen Bauer

Reputation: 16862

TOndrej has the right approach. You should never store a password using a reversible cypher. As it was correctly pointed out, if your "master" key were ever compromised, the entire system is compromised. Using a non-reversible hash, such as MD5, is much more secure and you can store the hashed value as clear text. Simply hash the entered password and then compare it with the stored hash.

Upvotes: 3

Ondrej Kelle

Reputation: 37211

For typical authentication purposes, you don't need to store the passwords, you only need to check if the password entered by the user is correct. If that's your case then you can just store a hash signature (e.g. MD5) instead and compare it with the signature of the entered password. If the two signatures match the entered password is correct.

Storing encrypted passwords may be dangerous because if someone gets your "master" password they can retrieve passwords of all your users.

If you decide to use MD5 you can use MessageDigest_5.pas which comes with Delphi (at least it's included with my copy of Delphi 2007). There are also other implementations with Delphi source code you can choose from.

Upvotes: 15

Giacomo Degli Esposti

Reputation: 2452

I think Turbopower LockBox is an excellent library for criptography:

http://sourceforge.net/projects/tplockbox/

I don't know if it's too big for your uses but it is very easy to use and you can encrypt a string with 5 lines of code. It is all in the examples.

Upvotes: 8

Marek Jedliński

Reputation: 7316

Nick is of course right - I just assume you know what you are doing when you say you want to spend all of 15 minutes on implementing a security solution. The DCPCrypt library also implements a number of hashing algorithms if you decide to go that (better) route.

Upvotes: 0

Marek Jedliński

Reputation: 7316

I second the recommendation for David Barton's DCPCrypt library. I've used it successfuly in several projects, and it won't take more than 15 minutes after you've read the usage examples. It uses MIT license, so you can use it freely in commercial projects and otherwise. DCPCrypt implements a number of algorithms, including Rijndael, which is AES.

There are many googlable stand-alone (single-unit) implementations too - the question is which one you trust, unless you are prepared to verify the correctedness of a particular library yourself.

Upvotes: 18

cleg

Reputation: 5022

I've used this library, really quick to add. But wiki shows few more solutions.

Upvotes: 2

Password encryption in Delphi

Answers (15)

Related Questions