我继承了一个 Web 应用程序，发现它将超过 30 万个用户名/密码以明文形式存储在 SQL Server 数据库中。我认识到这是非常糟糕的事情™。
我知道我必须更新登录和密码更新流程以进行加密/解密，并对系统的其余部分影响最小，您会建议什么是从数据库中删除明文密码的最佳方法？
感谢任何帮助。
编辑：如果我表述不清楚，我想问的是您加密/哈希密码的步骤，而不是具体的加密/哈希方法。
我应该只需要：
我担心的更多是用户数量如此之多，因此我要确保操作正确。
编辑（2016年）：按照偏好顺序使用Argon2, scrypt, bcrypt 或 PBKDF2。尽可能使用大的减速系数，根据您的情况而定。使用经过审核的现有实现。确保使用正确的盐（虽然您使用的库应该为您确保这一点）。
Python中的示例实现，使用SHA-256作为安全哈希：
编辑：正如Eli Collins所提到的，这不是PBKDF2实现。 您应该更喜欢坚持标准的实现，例如PassLib。
from hashlib import sha256
from hmac import HMAC
import random
def random_bytes(num_bytes):
return "".join(chr(random.randrange(256)) for i in xrange(num_bytes))
def pbkdf_sha256(password, salt, iterations):
result = password
for i in xrange(iterations):
result = HMAC(result, salt, sha256).digest() # use HMAC to apply the salt
return result
NUM_ITERATIONS = 5000
def hash_password(plain_password):
salt = random_bytes(8) # 64 bits
hashed_password = pbkdf_sha256(plain_password, salt, NUM_ITERATIONS)
# return the salt and hashed password, encoded in base64 and split with ","
return salt.encode("base64").strip() + "," + hashed_password.encode("base64").strip()
def check_password(saved_password_entry, plain_password):
salt, hashed_password = saved_password_entry.split(",")
salt = salt.decode("base64")
hashed_password = hashed_password.decode("base64")
return hashed_password == pbkdf_sha256(plain_password, salt, NUM_ITERATIONS)
password_entry = hash_password("mysecret")
print password_entry # will print, for example: 8Y1ZO8Y1pi4=,r7Acg5iRiZ/x4QwFLhPMjASESxesoIcdJRSDkqWYfaA=
check_password(password_entry, "mysecret") # returns True
基本策略是使用密钥派生函数将密码与某些盐“哈希”。盐和哈希结果存储在数据库中。当用户输入密码时，盐和他们的输入以相同的方式进行哈希，然后与存储的值进行比较。如果匹配，则用户已通过身份验证。
魔鬼在于细节。首先，很多取决于所选择的哈希算法。像基于哈希的消息验证码的密钥派生算法PBKDF2使得查找一个输入（在这种情况下是密码）能够生成给定输出（攻击者在数据库中找到的内容）变得“计算上不可行”。
预先计算的字典攻击使用哈希输出到密码的预先计算索引或字典。哈希化是慢的（或者应该是这样），因此攻击者一次性哈希所有可能的密码，并以这样的方式存储结果，即可以查找相应的密码。这是空间和时间的经典权衡。由于密码列表可能很大，因此有方法来调整权衡（如彩虹表），以使攻击者放弃一点速度以节省大量空间。
通过使用“加密盐”来防止预计算攻击。这是用密码散列的某些数据。 它不需要是秘密的，它只需要对于给定的密码来说是不可预测的。对于每个盐值，攻击者需要一个新的字典。如果使用一位字节的盐，则攻击者需要 256 份其字典的副本，每个都由不同的盐生成。首先，他将使用盐查找正确的字典，然后他将使用哈希输出查找可用的密码。但如果您添加 4 个字节呢？现在他需要 40 亿份字典副本。通过使用足够大的盐，可以排除字典攻击。在实践中，来自加密质量随机数发生器的 8 至 16 字节数据是一个很好的盐。
如果预先计算不可行，攻击者必须在每次尝试中计算哈希值。现在找到一个密码需要多长时间完全取决于计算候选密码的哈希值需要花费多长时间。哈希函数的迭代会增加这个时间。迭代次数通常是密钥派生函数的参数；现在许多移动设备使用10,000到20,000次迭代，而服务器可能使用100,000次或更多次迭代（bcrypt算法使用"cost factor"来衡量所需时间的对数度量单位）。
我认为你需要在数据库中添加一个加密密码的列，然后对所有记录运行批处理作业，获取当前密码，加密它（如其他人所提到的哈希函数md5是相当标准的 编辑：但不应该单独使用-有关好的讨论请参见其他答案），将其存储在新列中并检查所有操作是否顺利进行。
然后，您需要在前端更新用户登录时哈希用户输入的密码，并将其与存储的哈希值进行验证，而不是检查明文与明文之间的匹配。
在删除纯文本密码之前，为了确保没有任何奇怪的事情发生，我认为留下两个列是明智的。
还要记住，每当访问密码时，代码都必须更改，例如密码更改/提示请求。 当然，您将失去通过电子邮件发送忘记密码的功能，但这并不是坏事。 相反，您必须使用重置密码系统。
编辑： 最后一点，您可能希望避免我在测试安全登录网站上的第一次尝试中犯的错误：
在处理用户密码时，请考虑哈希计算发生的位置。 在我的情况下，哈希是由运行在Web服务器上的PHP代码计算的，但密码以明文形式从用户的计算机传输到网页！ 在我工作的环境中，这还可以（几乎）接受，因为它已经在https系统内部了（大学网络）。 但是，在现实世界中，我想您会希望在密码离开用户系统之前对其进行哈希处理，使用JavaScript等，并将哈希传输到您的站点。
遵循Xan的建议，保留当前密码列一段时间，以便出现问题时可以快速回滚。
至于加密密码：
请参阅Thomas Ptacek的Enough With The Rainbow Tables: What You Need To Know About Secure Password Schemes了解更多详情。
正如其他人所提到的，如果可能的话，您不想解密。标准最佳实践是使用单向哈希算法进行加密，然后当用户登录时将其密码进行哈希处理以进行比较。
否则，您将不得不使用强大的加密来进行加密，然后再进行解密。我只会建议在政治原因非常强烈的情况下使用（例如，您的用户习惯于能够调用帮助台检索其密码，并且您从高层领导面临强大压力不要更改这一点）。在这种情况下，我会从加密开始，然后开始构建一个过渡到哈希处理的商业案例。
步骤1：向数据库添加加密字段。
步骤2：更改代码，使得当密码被更改时，它会更新两个字段，但登录仍然使用旧字段。
步骤3：运行脚本以填充所有新字段。
步骤4：更改代码，使得登录使用新字段，并停止更新旧字段的密码更改。
步骤5：从数据库中删除未加密的密码。
这样可以在不影响最终用户的情况下完成转换。
另外： 我会给新的数据库字段命名为与密码完全无关的名称，比如“LastSessionID”或类似的无聊名称。然后，不要删除密码字段，只需用随机数据的哈希值填充即可。这样，如果您的数据库被攻击，他们可以花费所有时间尝试解密“密码”字段。
这可能实际上并没有实现任何东西，但想象有人坐在那里试图解密毫无价值的信息是很有趣的。
与所有安全决策一样，都存在权衡。如果您对密码进行哈希处理，这可能是最简单的方法，但您将无法提供返回原始密码的密码检索功能，也无法让您的员工查找某人的密码以便访问其账户。
您可以使用对称加密，但它也有自己的安全缺陷。（如果您的服务器被攻击，对称加密密钥也可能会被泄露）。
您可以使用公钥加密，并在一个独立的机器上运行密码检索/客户服务，该机器将私钥与Web应用程序隔离存储。这是最安全的方法，但需要两台机器架构，可能还需要防火墙。