我们如何保护您的密码

在之前的文章中，我们探讨了HTTPS如何保护您的应用和我们的服务器之间的传输路径，以及SSH如何保护服务器本身。现在是时候看看服务器内部——Splync如何在您的密码到达后确保其安全。如果有人获取了您的密码，他们就可以登录您的账户并访问敏感信息，包括您的支出记录。这就是为什么Splync从不以明文存储密码。相反，每个密码在保存到数据库之前都会被转换为哈希版本。这到底是什么意思？哈希是一种单向转换——一旦转换，就无法还原为原始密码。这种方法是互联网的标准，从银行到大型云服务都在使用，但许多人并不了解其工作原理。让我们通过一个简单的日常类比来探讨一下。

要理解密码保护如何工作，让我们从一种简单的哈希方法SHA-256开始。把它想象成一个搅拌机，总是以相同的方式混合原料。如果您将同一个密码放入搅拌机并按下按钮，您总会得到一个独特的“奶昔”——一串混乱的字母和数字。关键在于这个过程是不可逆的。就像您无法将奶昔分离回原来的香蕉和牛奶一样，您无法从混乱的哈希中恢复原始密码。

SHA-256是最常用的哈希算法之一。例如，它将密码"splync1234"哈希为“9cdafa20d069ecfb202e5f0bc937c73071cc6cd85634cc2d95d30ddcf2a71d41”。每当现有用户输入登录密码时，SHA-256总是能在毫秒内生成相同的哈希密码。应用程序只需再次哈希输入的密码并检查是否与存储的哈希匹配。系统在任何时候都不知道用户的原始密码。但是，如果攻击者预先计算了一个常用密码和其哈希的列表（称为彩虹表攻击），他们就能快速猜出用户的密码。这种担忧是非常真实的。这就是为什么现代系统，包括Splync，不依赖于纯粹的SHA-256。

Bcrypt使用随机的每用户盐并将其（以及工作因子）直接编码在存储的哈希字符串中。可以将bcrypt想象为一个带有秘密香料（盐）和缓慢马达（工作因子）的搅拌机——它使每次混合都独特且更难复制。由于盐是128位的（≈3×10³⁸种可能性），同一个密码可以对应非常大量不同的存储哈希。这使得预先计算的彩虹表在规模上毫无用处。在登录时，Splync从保存的bcrypt字符串中读取盐和工作因子，以这些参数对输入的密码重新运行bcrypt，并将结果与存储的哈希进行比较。如果它们匹配，密码就是正确的——但由于bcrypt故意较慢且盐是唯一的，暴力攻击对攻击者来说代价更高。

让我们看看这在实践中是什么样的。如果您用bcrypt（使用成本12）哈希密码"splync1234"，您可能会得到类似这样的字符串：`$2b$12$gBeouKYdue9uvvuV0HtGgeVPymnrojMqP/wcRw28HFlGEGIQbyw7O`。在这个bcrypt字符串中，`$2b`标记算法版本，`$12`表示成本因子（密码被处理的次数），`gBeouKYdue9uvvuV0HtGgeV`是唯一的随机盐，而`PymnrojMqP/wcRw28HFlGEGIQbyw7O`是最终的哈希密码。由于哈希本身包含盐和成本，Splync可以通过从存储的字符串中提取这些值进行验证。同样地，如果攻击者不知道盐和成本，他们不能为每个用户建立一个通用的彩虹表。

这种方法还有另一个重要的优势。因为Splync从不存储明文密码，即使数据库被泄露或被盗，用户也不会立即面临风险。攻击者无法直接使用被盗数据登录，因为他们只有一串乱序的字符串。这种设计为用户提供了额外的保护层，除此之外还有服务器本身已有的防护措施。密码哈希不仅仅是Splync独有的；它是整个技术行业的标准，被Google、Apple和Amazon等巨头使用。Splync的构建非常安全，并且随着我们不断通过电子邮件验证、暴力保护和持续监控等功能改进安全性，它只会变得更安全。