sql – 这是什么样的密码哈希/加密？

以下是多个示例

{enc:1}gdyb21LQTcIANtvYMT7QVQ==
{enc:1}ZEImYhrd/Ot/LcewJCFdMw==
{enc:1}+IOSBzegAx7nSytO1J3GEw==
{enc:1}6ULa1IFMxavY7SE66K3UDg==
{enc:1}UEFeGim2M8d0Iee7ejFRUw==
{enc:1}RjqL5rXOBpqJAKPjYkwLtw==
{enc:1}V/PEslecyYxFki03H4ctAQ==
{enc:1}VDEm9QmD+L7tsqcPz/S9XQ==
{enc:1}YkQuEPpL6dRfDLwKMEVMMg==
{enc:1}86rG96EP7T3tx9e8C7513g==
{enc:1}xvSwvsmkgwtXwVISvg7mJQ==
{enc:1}KjCF0RD4tcUGEP4Bpafw5A==
{enc:1}z9pGrdm4QAoomrFCJCXQIQ==
{enc:1}yhLv0HeW90FENKJjV9Nb+g==
{enc:1}EtYMl5FOW+zdpVvWsIj3Rw==

解决方法

{enc:1}gdyb21LQTcIANtvYMT7QVQ==

{enc：1}部分很可能是某种形式的版本控制.这是相当常见的,因此您可以升级随时间使用的任何散列/加密算法.每个值都标识用于生成散列的算法 – 如果实现决定使用不同的方法,它将知道使用第一个版本验证密码,但是可以用{enc：2}替换{enc：1}或无论如何,以及新形式的哈希.

其余的是base64 – 它是以==结尾的24个字符,这意味着原始值是16个字节.

所以它是一种16字节(128位)的某种散列,带有版本控制前缀.这几乎是我们所能告诉的……它可能是任何128位散列,或者可能是128位更长的散列(尽管你不得不想知道为什么他们会在那时丢弃数据).

如果您可以使用密码创建自己的用户,则可以执行进一步的测试.例如,具有相同密码的两个用户最终是否使用相同的哈希？如果没有,如果您从密码X更改为密码Y,然后再更改为单个用户的密码X,是否会获得相同的哈希？ (值中没有明显的盐,尽管用户名可以用作盐.)

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!