问题标签 [password-storage]

我想要一个需要密码才能登录但没有数据库的页面。

我正在考虑在页面中对其进行硬编码，即：

还是对其进行加密并将其存储在文本文件中？

任何建议表示赞赏。

我有一个表单，它有一个带有名称属性username的文本框和另一个带有名称属性password的文本框。我还有一个数据库，其中包含名为user和pass的列。当我的用户注册时，它将用户名添加到用户列和密码到通过列。

我将如何进行 MySQL 查询以检查表单是否提交了正确的用户名和密码，然后如果它确实有一个分支让我输入代码是否成功？

我真的需要一些代码，这一点进展不顺利，我知道它应该是这样的，SELECT * FROM table WHERE username == $username AND...但后来我被卡住了，因为我在数据库中有一个 MD5 密码，而第一位可能是错误的。请帮忙。:)

谢谢

我正在 vb.net 中编写一个程序，该程序需要用户登录才能使用该应用程序。安装程序时创建主用户，类似于安装时 windows 的工作方式。

主用户可以向程序添加其他用户。我已经知道我应该存储加密的密码。我的问题是，我应该在哪里存储用户名和密码？注册表、隔离存储或 .config 文件。我不希望任何用户能够修改/删除该文件，因为其他用户显然无法登录。此外，任何登录计算机的用户都应该可以访问该文件。

电脑不保证能联网，所以必须本地存储。

谢谢

假设我有一个密码：

AAABBBCCCDDD 我可以很容易地给 A 人第一部分（AAA），给 B 人第二部分，依此类推。

但是是否有四个人中的任何两个可以从我给他们的部分文本中解密/形成密码的选项？显然，仅从 AAA 和 DDD 部分无法形成密码。

如何？:)

我正在尝试为我的密码正确地执行每个用户和站点范围的盐。这是我所拥有的：

这是正确的吗？谢谢

可能是一个非常新手的问题，但是，我一直在阅读并发现在理解密码的创建和存储方面有些困难。从我读过的内容来看，md5/hash 密码是将它们存储在数据库中的最佳方式。但是，我将如何首先创建这些密码？

所以说我有一个用户 bob 和密码 bob123 的登录页面 - 我将如何 1. 将 bobs 密码输入数据库以开始（散列） 2. 我如何检索并确认散列密码？

谢谢

我看过许多关于使用盐和哈希创建可以存储在数据库中的安全版本的密码的帖子。

但是，一个问题让我感到困惑，我看不出有什么问题，所以我想我会在这里发布这个问题，看看其他人是否能指出这个想法中的任何缺陷。

我的基本想法是生成一个公钥/私钥对，然后销毁私钥。我对公钥/私钥密码学的有限理解是，如果我没有私钥，那么解密用公钥加密的消息“在数学上是不可能的”。

我会使用公钥加密密码，然后将加密版本存储在数据库中。当有人尝试登录时，我只需使用公钥加密密码并查看它是否与存储的密码匹配？

这个想法有什么可怕的缺陷吗？盐和哈希会更安全吗？

在 Java 桌面应用程序中存储密码的推荐方法是什么？

我希望用户能够仅输入一次凭据，而不会再次收到提示。

在个人项目中，我一直在使用 Preferences API，但我假设这与以纯文本形式存储（安全方面）没有什么不同。

非常感谢

编辑：

非常感谢您的建议。似乎有些混乱，毫无疑问，因为我可能没有把问题说得很清楚......

我将给出一个假设的场景：

假设我正在为远程数据库创建一个简单的前端，它使用用户名/密码创建一个连接字符串。通常，每次应用程序启动时都会提示用户输入用户名/密码组合。

将该密码存储在用户机器中的最佳方式是什么，无需重新输入（在应用程序启动时自动连接）。

一种“记住我”功能（我知道这本身不是一个很好的做法......）

编辑2：

谢谢大家的回答。Paŭlo Ebermann's 对手头的问题提供了非常丰富的信息，Chris Smith 的链接很有趣，但我接受了 JVerstry 的链接，因为密钥库可能是我要走的路线。

假设知识
Hashing、Salting、PBKDF[1-2]

问题
我正在使用像 PBKDF2 这样的缩放散列/加盐算法将密码存储在我的数据库中。我想‘嘿，如果我对我的密码进行 20000 次哈希处理，那应该足以抵御暴力攻击，对吧？它是真的。直到明年更好的计算机问世。

可能的解决方案

撇开加密密钥长度和盐长度的问题（也可以合并到这个解决方案中）我想，如果每 N 天，我重新散列数据库中的所有密码。所以它们被散列了 20,000 次，然后一周后，我又对它们进行了 500 次散列，总共 20,500 次。将它在数据库中某处的散列次数存储。这个想法是随着技术的进步增加哈希计数。

现有的类似实现
BCrypt引入了一个工作因素来增加散列密码所需的时间：
PBKDF2使用多次迭代来做同样的事情。Mac OS-X、windows 和 linux 使用它来进行文件级加密。Wi-Fi网络也使用它的实现。

任何人都可以看到这个问题吗？这已经试过了吗？是否有一种算法可以接受预先散列的密码并重新散列“N”次？

编辑
问题不在于多重散列是否安全（这已经过试验和测试）。问题在于重新散列以提高安全性，而不必让用户重新设置密码

解决方案：由与 JVestry 讨论提供

因此，每'N'天重新散列所有密码是浪费时间，因为黑客可以通过使用数据库的旧副本来破解它。但是，如果您将随时间增加哈希计数的概念与密码更新策略结合起来，那么这个概念是合理的。

实施
所有密码每 30 天过期一次。当它们被更新时，它们的哈希计数器会增加。因此，昨天的密码重置将比 20 天前的密码更难破解。哈希计数器可以存储或从使用最后修改日期的算法导出。

谢谢！

TTD

假设我正在设计一个具有适度安全要求的 Web 服务。在大多数情况下，威胁模型更多的是关于无聊的大学生，而不是你在间谍小说中找到的任何东西。使用以下密码存储方案实际上会有什么问题吗？

盐 || 哈希（网站 || 密码 || 盐）

其中site是我的站点的唯一标识符，password是用户密码，salt是用户特定的随机salt，hash是通用的加密散列函数，如SHA-1，|| 表示串联。

我知道这个计划带来的某些问题。

• 哈希（设计为）可以快速评估，并且一次迭代会使特定的弱密码变得可猜测。

• 单独的连接可能会导致哈希的整体输入中出现“双关语”。

现在，Internet 上的某些安全专家会让我相信，如果这是我对一个足够好的密码散列方案的想法，我不可能配得上工作，并且迫切需要重返学校。他们指出，从安全角度来看，有一些众所周知的密码散列方案具有更好的特性。他们要求我改用更好的东西。

但真的，我应该吗？我在这里有一点反驳的论点。

• 这可能不会是我服务中最薄弱的环节。真正决心闯入的人还有很多其他途径，我应该优先安排时间来保护较弱的途径。

• 如果我的网站没有什么内在价值，那么成本效益已经对攻击者不利。大型集群/僵尸网络可以在一天/一周内恢复弱密码，这有多大实际问题？那天/那一周肯定有更有价值的事情要做。

• 由于特洛伊木马、键盘记录程序、社会工程攻击等，更有可能发生被盗帐户。技术并不是这种安全性的限制因素。

• 我的方案越复杂，移动/扩展到另一个平台可能就越困难。如果我使用 bcrypt（假设），我可能必须编写一个 bcrypt 包装器并将其合并。

我真的很喜欢这个方案。这真的很简单。实施很难出错。我会争辩说，就普通网站而言，出于所有意图和目的，它应该没问题。要求我采用更好的散列方案几乎听起来像是要求我在已经很容易受到电锯伤害的门上安装更大的锁。

如果我在这里做错了什么，我将非常感谢有人指出这一点，特别是在实际和现实世界适用的问题方面。

谢谢。