我应该如何在本地存储多用户应用程序的密码?

发布于 2024-11-05 13:36:33 字数 324 浏览 5 评论 0原文

我想创建一个多用户应用程序,但我不知道如何保存和读取加密密码。

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

密码必须存储在计算机上。 这可行,但使用它来保存密码是愚蠢的。 对密码进行哈希处理也不错。

I want to create a multi-user application, but I don't 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;

The passwords must be stored on the computer.
This works but it's stupid to save passwords using this.
Hashing passwords would be also good.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(6

残花月 2024-11-12 13:36:33

如果连接软件接受散列密码,它不会阻止窃取散列密码的人进行连接。它所做的只是隐藏真正的密码。

此外,如果您连接的软件不接受散列密码(数据库、网站等),您将必须以可以将其恢复到原始状态的方式存储您的密码。哈希版本不会对你有帮助。

如果您想打乱存储以便人类无法读取文件,您可以使用 Windows.EncryptFile() 和 Windows.DecryptFile()。在较新的 Delphi 中,它被整齐地包装在 IoUtils.TFile.Encrypt()IoUtils.TFile.Decrypt 中。

如果您确实想阻止其他人读取您密码的明文版本,则必须使用密钥进行某种加密。那么你将该密钥存储在哪里?这首先就违背了存储密码的全部目的。例如,最好通过使用文件系统的用户权限来防止其他用户访问,因为您或您的软件可以做的任何事情,如果“黑客”具有相同的权限,他也可以做​​。

If the connecting software accepts hashed passwords, it's not going to stop people who steal the hashed passwords from connecting. All it will do is hide what the real password is.

Furthermore, if the software that you're connecting to does not accept hashed passwords (database, website, ...), you're going to have to store your password in such a way that you can get it back to its original state. A hashed version is not going to help you there.

If you want to scramble your storage so that humans cannot read the file, you could use Windows.EncryptFile() and Windows.DecryptFile(). In newer Delphi's that's neatly wrapped into IoUtils.TFile.Encrypt() and IoUtils.TFile.Decrypt.

If you really want to stop others from reading the cleartext version of your password, you're going to have to use some encryption with a key. Where do you store that key then?That would defeat the whole purpose of storing a password in the first place. It's better to prevent access by other users by using user privileges to the file system for example, because anything you or your software can do, a "hacker" can do if he has the same privileges.

月野兔 2024-11-12 13:36:33

我的建议是根本不要在您的应用程序中使用密码,除非您确实需要。需要输入另一个密码的用户体验通常不需要记住。

我为我的应用程序所做的默认是使用当前用户的域和用户名作为标识。用户已经使用密码或更安全的系统(如果他们需要)登录。只有登录后他们才能成为当前用户。然后我的服务器接受它作为他们的身份。

对此的变体还包括选择性地传递计算机名称,以便同一用户在不同的计算机上受到不同的对待(当他们需要同时使用多台计算机时)。当然,如果您愿意,您仍然可以允许使用普通密码。

My suggestion is to not use passwords in your application at all, unless you really need to. The user experience of having yet another password to enter & remember is usually not needed.

What I do for my applications is default to using the domain and user name of the current user as the identification. The user has already logged on with a password, or more secure system if they want it. Only by logging on can they be that current user. My server then accepts that as their identification.

Variations on this include optionally passing the machine name too, so that the same user is treated differently on different computers (when they need to use more than once computer at once). And of course you can still allow a normal password if you want to.

回梦 2024-11-12 13:36:33

您应该存储散列密码。例如,您可以使用 Delphi 加密包 中的一种 SHA 算法。当您检查密码时,会对用户提供的密码进行哈希处理,并与文件中保存的密码进行比较。

您是否考虑过使用 Windows 安全性而不是尝试推出自己的安全性?


顺便说一句,如果您的程序驻留在程序文件目录下并且正在使用 UAC,则在写入程序目录时可能会遇到问题。

You should store hashed passwords. For example you could use one of the SHA algorithms from the Delphi Cryptography Package. When you check passwords hash the password that the user supplies and compare against that saved in the file.

Have you considered using Windows security rather than attempting to roll your own?


As an aside, you are liable to encounter problems writing to your program directory if your program resides under the program files directory and UAC is in use.

梦中的蝴蝶 2024-11-12 13:36:33

Lockbox 中有哈希和加密例程。您应该对与随机“盐”连接的密码进行哈希处理,并将盐和哈希值存储在一起。为了让人们更难暴力破解哈希值(尝试所有可能的密码,直到找到正确的密码),您应该迭代哈希值。当用户随后输入密码登录时,从您的商店中获取盐,并使用输入的密码对其进行哈希处理,然后进行迭代,并根据您存储的哈希值测试结果。如果它们相同,则说明密码正确。

There are hash and encryption routines in Lockbox. You should hash the password concatenated with a random 'salt' and store the salt and hash together. To make it harder for people to brute-force the hash - trying all likely passwords until the right one is found - you should iterate the hash. When the user subsequently enters their password to login take the salt from your store and hash it with their entered password, and iterate, and test the result against the hash you have stored. If they are the same they have given the correct password.

山人契 2024-11-12 13:36:33
  • 只要可以,就不要存储密码,而是正确地对它们进行哈希处理(使用盐、重复哈希n次等),因为彩虹表攻击是可行的,并且可以很好地应对选择不当的密码和过于简单的哈希处理。
  • 如果可能,请利用“集成安全性”。使用 Windows 身份验证以避免存储密码。
  • 如果您确实需要存储主密码等,请使用 Windows API,例如 CryptProtectData 在本地保护它们。
  • As long as you can, don't store password, but hash them properly (use a salt, repeat hash n times, etc.) because rainbow table attacks are feasible and work well against poor chosen passwords and too simple hashing.
  • If possible, take advantage of "integrated security". Use Windows authentication to avoid storing passwords.
  • If you really need to store a master password or the like, use Windows APIs like CryptProtectData to protect them locally.
寂寞美少年 2024-11-12 13:36:33

我认为最好将用户特定的设置保留在注册表中的 HKEY_CURRENT_USER 下。这将使他们的设置保持在一起,并与其他用户的设置分开。

当您从注册表的该区域读取时,您将自动读取正确的用户设置,并且您也应该将密码存储在那里。是的,请按照大卫的建议对其进行加密。任何人都可以使用 RegEdit

这是一篇有关如何写入和读取注册表的文章

I think its best to keep user-specific settings in the Registry under HKEY_CURRENT_USER. That will keep their settings all together and separate from other users' settings.

You'll automatically read the correct user's settings when you read from this area of the Registry, and you should store your password there as well. Yes, do encrypt it as David recommends. The Registry is easy for anyone to read using RegEdit.

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

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文