Storing a password

tntcoder

tntcoder

tntcoder

Soldato
Joined
7 Apr 2004
Posts
4,212
Hi,

I'm using C++, and need to store a password in a config file and I don't think plain text is a good idea. Whats the best way to do this?

I don't really want the user to have to provide a key every time they start the program to decrypt settings, so I think im going to have to store the encryption key inside the program, but that's got to be better than plain text?

Has anyone done this before? I suppose ideally i just want a simple encrypt & decrypt function that i can pass a string to, but i have no idea what algorithm to use.

Thanks,
Jack
 
If you could base it on user input then I would have said keep the file hashed (using md5 or something) then hash the user input and compare to the hash stored in the file. That way you never store it in plaintext.

Hmm, what platform your targeting? I guess you try integrate it with a key from some kinda keystore on the users PC (gnome keyring/whatever m$ uses).

What your talking about is pointless because if the key is stored in the app or you use some funky algo it will be easy for someone to work it out from your app.
 
Hey,

Thanks, its for Linux and i don't have the option of using hashing sadly :(

I like the idea of using a keystore program though, i think both gnome and kde have something suitable, will defiantly look into that. I can see why you say encryption is pointless if the key is in the code, i was just wondering if it would be better to use that for obscuring it rather than just have it plaintext in a config file but as you say i guess there isnt much point in that approach.
 
Aye if you look at the keychain apps once the user logs on they use their login password to unlock the keychain. This way you won't need to reauth for the whole x session.

You can obfuscate and make your program very hard to reverse engineer, so much so thats its going to stop 99% of people apart from the very determined but at the end of the day the concept is flawed and thats why schemes like DRM fail. It depends on your threat model and how sensitive the data is. Then if its a networked application you got other problems! haha.
 
DO NOT store the password.

Do a hash/checksum, (md5/SHA-1, plenty of source code out there, no need to use a built in function of the OS or a standard library), and store the checksum unencrypted. Then make the checksum each time they try to log in and compare it.

It's almost impossible to convert the checksum to the password again, it can be done with a good rainbow table, but this is rendered useless if you use a "salt", as good rainbow tables (ones with large character sets, this is why we use characters in passwords) still take days to make.
 
BigglesPiP said:
DO NOT store the password.

Do a hash/checksum, (md5/SHA-1, plenty of source code out there, no need to use a built in function of the OS or a standard library), and store the checksum unencrypted. Then make the checksum each time they try to log in and compare it.

It's almost impossible to convert the checksum to the password again, it can be done with a good rainbow table, but this is rendered useless if you use a "salt", as good rainbow tables (ones with large character sets, this is why we use characters in passwords) still take days to make.
Click to expand...

I would do this approach, but the password is used to connect to a server, and that password is sent in plain text which is a protocol fault not mine, as this is for a 'remember password' feature, i have nothing to check a hash against :(
 
You must log in or register to reply here.
Back
Top Bottom