[如果我正在为开放源代码（Python-Flask）创建密码，并且在对密码进行哈希处理，那么像下面一样对它们进行哈希处理是否安全？还是应该在不在存储盐的git repo中的服务器上创建配置文件？当人们可以准确地看到某人如何对密码进行哈希处理时，它的安全性是否较差？如果有人能够动手访问数据库，并且知道用于哈希密码的确切方法（例如下面的代码），他们是否可以轻松地将其撤消？还是我可以添加一些东西来使它变得困难？
login_details_dict['account_id'] = account.account_id
login_details_dict['account_password'] = sha256_crypt.hash(account_password)
login_details = login_schema.load(login_details_dict)
login_details.save_to_db()
否；对于任何Web应用程序仅使用一轮SHA-256散列密码是不安全的！
SHA-256是主要用于数据完整性验证的哈希算法。这意味着它已针对速度进行了优化。针对速度进行了优化，使其容易受到蛮力和字典攻击，其中包括多次猜测密码。
假设您的登录数据库已泄漏，即使对于大型Web应用程序（如银行或大型公司），也会发生这种情况。您的密码哈希将暴露给对手。他们将如何获取这些多汁的密码？他们会不断猜测密码，直到找到正确的密码为止。比特币挖矿使用类似的“哈希猜测”机制进行挖矿，并且有SHA256 ASIC可以每秒执行太ahash。对于攻击者每秒能够猜测数万亿次密码的情况，您是否感到满意？
一种更安全的方法是使用现代的KDF，例如Scrypt或Argon2。现代KDF被设计为占用大量内存，这限制了散列到RAM的速度，因此很难为其构建高效的ASIC。由于KDF速度较慢，因此最好在客户端执行KDF，然后将KDF哈希发送到服务器，最后一次在服务器端使用SHA-256之类的快速算法对KDF哈希进行哈希处理。这样一来，您就可以将处理工作分担给客户端，而无需将泄漏数据库中的哈希用作密码。
注意：JavaScript密钥派生速度可能很慢。如果希望客户端密钥派生更快，则可以使用WebAssembly加速它。尽量不要减少太多参数；它将使算法更易于暴力破解。
此外，将盐存储在Git存储库中听起来像您打算在整个Web应用程序中添加一种盐。这是一个坏主意，因为这意味着攻击者可以使用哈希函数/ KDF的一个迭代来猜测所有数据库条目的单个密码。最好为每个密码随机生成一个盐，并将其与密码一起存储在数据库中。
虽然我们在这里，您可能还想防止定时攻击。在比较散列时，使用像简单的“ ==”这样的定时比较功能将使攻击者一次在哈希中暴力破解单个字符以登录到系统。使用诸如itsdangerous.constant_time_compare()的恒定时间比较功能可以防止此类攻击。
如果您正在使用现代安全性实践，那么将源代码公开给公众应该不会使其变得不安全。制作Web应用程序时，请注意上面列出的最佳安全实践以及其他最佳实践。