3

I'm using Qt resource system to store images used in GUI and encrypted passwords of database. I want to store passwords and let users to change them. The application should be able to remember passwords. So I would like to store newly created encrypted password in application itself (same way as resources are embedded).

Currently I'm saving the password file in application resource at compile time. And after compile password is unchangeable.

sorush-r
  • 10,490
  • 17
  • 89
  • 173
  • I think I got the answer: http://stackoverflow.com/questions/1038795/can-i-modify-the-content-of-an-embedded-resource-text-xml-file-in-a-net-appli – sorush-r Mar 22 '12 at 09:14

2 Answers2

3

What you're trying to do is very bad style. An application should never need to modify its own executable. In a well administered system, users of applications can't write to the installation directory anyway. Use QSettings, that's what it's for. You can store it in an .ini file instead of the registry if you really wish to do so.

Make sure that for passwords you use a one-way function -- a cryptographically strong hash, not encryption. Encryption is two-way by definition: you can encrypt, and then decrypt. If you consider yourself a professional, you won't ever want to use the word encryption interchangeably with one-way function (a hash). They are very different things, and you will, and should, get scolded -- how would I know what you really mean, whether you're merely loose with your language, or proposing something inherently unsafe.

With passwords, you never ever want to allow decryption. If someone supplies a password to check, you encrypt, then compare encrypted versions. That way it's hard to recover the original password (likely used by Vinnie in the H.R. for her Facebook account and for boss's company bank account, too). Make sure that you salt your hash to prevent rainbow table attacks. You probably should ensure you know what you are doing: educate yourself in that area. No one is born with it. Let's avert yet another home-baked unsafe password scheme... there's too many of them, done by people who think that without knowing anything about the subject, they will, somehow produce a reasonably secure application. Reality, alas, cannot be fooled here, and not knowing usually means someone who does know will, eventually, look at your code (perhaps reverse engineer it), and ridicule it... End rant.

Kuba hasn't forgotten Monica
  • 95,931
  • 16
  • 151
  • 313
  • +1 for suggesting QSettings. Thats EXACTLY what its for. Platform-independant settings – jdi May 29 '12 at 03:35
  • Thanks for information. Currently I'm saving hashed password when user enters the password for first time using QSetting. Then each time user enters the password, I hash the newly entered password and compare the result with saved one. Here is some problem: 1. Hashed password is visible to everybody and MD5 hashing is easy to break. 2. Two different passwords may have same hash. – sorush-r May 29 '12 at 19:15
  • 1. Use a cryptographic grade hash. I can't tell you if MD5 is "easy to break", you should be able to figure it out. 2. That's not a problem. So what if the hashes collide? There's an abundance of passwords that will have any given hash -- finding them requires an exhaustive search. Thus you have security-by-infeasibility. Finding those same-hash passwords takes "very long". It's state of the art at the moment. – Kuba hasn't forgotten Monica May 30 '12 at 16:55
1

Sorush: here are a couple of less aesthetic, more technical answers:

On Windows, it's difficult-to-impossible due to the OS not letting you edit an executable while running: https://stackoverflow.com/a/1954479/58133

On Linux, probably doable: http://www.overclockers.com/forums/archive/index.php/t-195048.html

Community
  • 1
  • 1
ctd
  • 1,693
  • 12
  • 27