Geek Answers Handbook

How to store passwords locally for a multi-user application?

I want to create a multi-user application, but I do not know how to save and read encrypted passwords.

procedure SavePass(Password: WideString); var Pass: TIniFile; begin Pass := TIniFile.Create(ChangeFileExt(Application.ExeName, '.PASS')); Pass.WriteString('Users', 'USERNAME', Password); Pass.Free;

Passwords must be saved on the computer. It works, but it's silly to save passwords using this. Password hashing would also be good.

+4
source share
6 answers

If the connecting software accepts hashed passwords, it will not stop people who steal hashed passwords. All he does is hide what a real password is.

In addition, if the software you are connecting to does not accept hashed passwords (database, website, ...), you will have to store your password so that you can return it back to its original state. The hashed version will not help you there.

If you want to scramble the storage so that people cannot read the file, you can use Windows.EncryptFile() and Windows.DecryptFile() . In the new Delphi, which is neatly wrapped in IoUtils.TFile.Encrypt() and IoUtils.TFile.Decrypt .

If you really want others to not read your plaintext version, you will have to use some encryption with the key. Where do you store this key then? This can damage the whole purpose of storing a password in the first place. It is better to prevent other users from accessing, for example, using user privileges for the file system, because all that you or your software can do, a hacker can do if he has the same privileges.

+9
source

You must store hashed passwords. For example, you can use one of the SHA algorithms from the Delphi Cryptography Package . When you check the password hash that the user supplies and compares with the one stored in the file.

Do you consider using Windows security rather than trying to tip over?

As an aside, you may run into problems writing to your program directory if your program is located in the program file directory and is used by UAC.

+2
source

My suggestion is to not use passwords in your application at all, unless you really need to. The user experience of using another password to enter and remember is usually not required.

What I do for my applications, by default, the domain name and user of the current user are used as identification. The user is already logged in with a password or a more secure system if he wants to. Only at the entrance to the system can they be the current user. Then my server takes this for authentication.

Variations in this case include the optional passing of the machine name, so that the same user is processed differently on different computers (when they need to use several computers at the same time). And, of course, you can enable a regular password if you want.

+2
source

Lockbox has hash and encryption procedures. You must enter the password associated with the random salt and save the salt and hash together. To make it more difficult to force a hash - trying all possible passwords until you find the correct one, you must iterate over the hash. When the user subsequently enters his password to enter the system, take the salt from your store and enter it with the password you entered, and try again, and check the result against the hash that you saved. If they are the same, they gave the correct password.

+1
source
  • As long as you can, do not store the password, but hash them properly (use salt, repeat the hash n times, etc.), because attacks from rainbow tables are possible and work well against weak passwords and hashing that is too simple.
  • Use "integrated security" if possible. Use Windows Authentication to avoid storing passwords.
  • If you really need to save the master password, etc., use Windows APIs such as CryptProtectData to protect them locally.
+1
source

I think it’s best to save user settings in the registry under HKEY_CURRENT_USER. This will keep its settings together and separate from the settings of other users.

You will automatically read the correct user preferences when reading from this registry area, and you must also save your password. Yes, encrypt it, as David recommends. The registry is easy for everyone to read with RegEdit .

Here's an article on how you can write and read from the registry .

0
source

More articles:


All Articles