WeJcFMQ/8+8QJ/w0hHh+0g==）将密码存储在数据库中。如何确定正在使用哪种哈希或加密？#1 楼
您的示例字符串（WeJcFMQ/8+8QJ/w0hHh+0g==）是Base64编码，序列为16个字节，看起来不像有意义的ASCII或UTF-8。如果这是为验证密码而存储的值（即不是真正的“加密”密码，而是“哈希”密码），则可能是根据该密码计算出的哈希函数的结果；一个具有128位输出的经典哈希函数是MD5。但这可能与任何事情有关。知道这一点的“正常”方法是查看应用程序代码。应用程序代码以有形，繁琐的方式（服务器上的可执行文件，源代码在某处……）来实现，它没有，也没有像密钥那样受到尽可能多的保护。因此，逆向工程是“前进的道路”。
除非进行逆向工程，否则您可以做一些实验来尝试进行有根据的猜测：同一用户“更改”他的密码，但重复使用相同的密码，存储的值是否更改？如果是，则该值的一部分可能是随机的“盐”或IV（假设对称加密）。
假设该值是给定用户的密码确定性的，如果两个用户选择相同的密码，它导致相同的存储值吗？如果否，则用户名可能是计算的一部分。您可能想尝试计算MD5（“ username：password”）或其他类似的变体，以查看是否匹配。
密码长度是否受限制？也就是说，如果您设置了40个字符的密码，并且仅输入前39个字符就无法成功进行身份验证，那么这意味着所有字符都很重要，这意味着这实际上是密码哈希，而不是加密（存储的值用于验证密码，但不能仅从存储的值中恢复密码。）
评论
感谢您的输入。.请告诉我更多有关如何确认16字节序列的Base64编码的信息。关于您的实验，是的，这是存储的用于密码验证的值。 1）如果一个用户更改了密码，那么存储的值也会更改。。2）如果两个用户选择相同的密码，则存储的值是相同的。3）密码长度不受限制。
– Karthik
2011年5月27日10:28
@Learner：任何24个字符的序列（例如前22个是字母，数字，“ +”或“ /”，后两个为“ =”符号）是有效的128位值的Base64编码。而且，任何以Base64编码的128位值都会产生这样的序列。
–托马斯·波宁（Thomas Pornin）
11年5月27日在12:21
即使我想听听一些潜在的技巧（如果应用程序代码不可用），这也是正确的答案。如果您正在处理开源二进制文件-请访问aluigi.org/mytoolz.htm#signsrch
– atdre
2011年5月29日16:19
如果是MD5，则可以尝试任何md5破解网站，例如md5decrypter.co.uk。这些都不是快速或保证得出结果的方法。 Google为“ md5破解”找到更多。这也将在stottmeister.com/blog/2009/04/14/how-to-crack-md5-passwords中为您提供扩展列表
–user13695
13-2-26在15:41
#2 楼
编辑：我只是注意到一个很酷的脚本，名为hashID。这个名字几乎描述了它。~~~~
通常来说，利用经验进行有根据的猜测是这些事情的完成方式。
这是一个包含大量哈希输出的列表，因此您可以知道每个哈希表的外观并创建签名/图案，或者只是进行光学验证。 >
InsidePro软件论坛>哈希类型（通过Archive.org）
您首先要注意两件事：
长度的哈希值（每个哈希函数都有特定的输出长度）
使用的字母（所有英文字母吗？数字0-9和AF都是十六进制吗？有什么特殊字符？）
几个密码破解程序（例如，开膛手约翰）会在输入上应用某种模式匹配，以猜测所使用的算法，但这仅适用于通用哈希。例如，如果您获取任何哈希输出并将每个字母旋转1，则大多数模式匹配方案将失败。
评论
谢谢..我看了一下，尝试了几个密码。但是该方法在已知密码被散列且未加密的情况下有效，对吗？
– Karthik
2011年5月27日在9:27
密码通常不加密，而是经过哈希处理，通常以函数输出密码的形式表示-因此，您可以在上面的链接中找到许多这样的形式。最后，所有函数的输出只是二进制数字，通常以十六进制表示或base64表示并存储。
–约翰
11年5月27日在16:32
这个程序是垃圾。它甚至无法识别base64哈希。
– MikeSchem
17年7月14日在15:52
Base64不是哈希，而是一种编码。
– Monica辩护律师走出去
17年12月19日在20:56
#3 楼
您发布的是16字节（128位）的基本64编码数据。它是基于base 64编码的事实并不能告诉我们太多，因为base 64不是加密/散列算法，而是将二进制数据编码为文本的一种方式。这意味着该块包含一条有用的信息，即输出为16个字节长。我们可以将其与常用方案的块大小进行比较，找出不可能的方案。到目前为止，最常见的方案是：SHA-1（160位）
MD5（128位）
AES（128位）
DES（64位）
3DES（64位）
我们接下来要做的是查看其他密文块以找出以下问题的答案：
所有密文的长度是否相同，即使输入长度不同也是如此？
如果不是所有块的长度都相同，那么您就不是在寻找一种哈希算法，而是一种加密算法。由于输出将始终是基础块大小的倍数，因此存在无法被16字节均匀整除的块将意味着该块不能为AES，因此必须为DES或3DES。
如果您可以输入密码并观察输出，可以很快确定。只需输入17个字符的密码，然后看一下长度即可。如果它的16个字节具有MD5，则20个字节表示SHA-1，24个字节表示DES或3DES，32个字节表示AES。
评论
:-p我不明白..它是基于64位编码的数据吗？怎么样？而且我绝对没有得到您说“如果任何块都不能被16字节均分的话，那很可能是DES或3DES，否则很可能是AES”使我对此有所了解。 :)
– Karthik
2011年5月27日9:41
我已将@Learner添加到答案中，希望可以使其更加清晰。如果可以使用选定的纯文本，则可以从中解决。
– Yaur
2011年5月27日晚上10:04
非常感谢..我开始讲第二部分。在这里问了这个问题之后，我在Google的某个地方读到哈希是多对一的，这意味着可以将许多不同的文本哈希到同一输出（如果我错了，请纠正我）。来到我们的场景中，所有密码文本块的长度都不一样。.所以现在我可以确定它们没有被哈希但被加密了吗？但是，我仍然不知道您怎么说我发布的数据是16字节的base 64编码数据。如果有密码或哈希，我怎么知道它是16或32字节数据？
– Karthik
2011年5月27日11:31
@学习者= =填充是base64的特征。此工具home2.paulschou.net/tools/xlate（来自google搜索base64解码器hex）将从base 64转换为十六进制值数组。只需将您的文本粘贴到base 64框中，然后单击解码并计算字节数即可。您还可以通过将base64字符串中的字符数乘以.75来估算
– Yaur
2011年5月27日晚上11:41
@Karthik，几乎没有什么方法可以将数字（即哈希或加密的最终结果）表示为紧凑的人类可读文本。主要方式是十六进制（A-F，0-9）和以64为底（A-Z，a-z，0-9，+，/）。从技术上讲，也可以尝试以文本编码（ASCII，UTF-8等）查看数据，尽管这通常只是不知道如何查看数据的标志（例如，尝试在其中打开二进制文件）。记事本）。您只要看一下出现的是哪种类型的字符，然后从那里猜测就可以大致识别出它。
–凯特
18年2月20日在22:13
#4 楼
如果这确实是简单的密码哈希，我们也许可以使用Google对其进行破解。不过，使用所有这些斜杠和加号很难搜索Base64，因此让我们首先将哈希转换为十六进制：$ perl -MMIME::Base64 -le 'print unpack "H*", decode_base64 "WeJcFMQ/8+8QJ/w0hHh+0g=="'
59e25c14c43ff3ef1027fc3484787ed2
好，现在我们可以用Google搜索它。目前，我在md5this.com上仅获得了一次成功，尽管显然很快，包括这篇文章在内，还会有更多点击。
（不幸的是，或者幸运的是，取决于您的观点），我们还没有足够的幸运地找到一个原像（该站点当前将该哈希表列为“ cracking ...”），但是它确实位于该列表中的事实强烈表明它确实是一个真实的MD5哈希表密码。
评论
Google在这种情况下如何提供帮助非常有趣。好分享！
–亚伦·吉利恩（Aaron Gillion）
16 Apr 16'0:52
#5 楼
这取决于格式-一些用于存储加密文本的协议具有明文部分，用于定义如何加密。从您的示例中，我很怀疑，因为您引用的字符串太短，以致看起来好像只是加密的文本。我建议您考虑以下几点：
最后的“ ==”绝对是填充，因此不要在解密尝试中包括。
您可能正在处理哈希或加盐哈希，而不是加密。在这种情况下，尝试“解密”数据将不起作用-您需要使用与原始使用的相同的哈希值和/或盐值来匹配密码。用盐腌的密码无法获得原始值。
您的绝对最佳选择是获取用于存储密码的代码副本。那里的某个地方，密码正在进行加密操作。查找代码以了解此处发生的情况。在10的9倍中，他们使用某种API进行哈希/盐腌/加密，您可以使用相同的API进行模仿或逆向操作。
评论
末尾的==是该值被base64编码的明显标志。填充是必要的；你不只是放弃它。首先，您对数据进行base64解码，然后对其进行播放。
– tylerl
13年6月19日在16:45
由于可以根据消息长度进行计算，因此可以减少填充。为了在查询字符串中使用base64，您几乎必须将其传递给webSafeBase64转换，然后在解码之前反转该过程。
–安德鲁·霍夫曼（Andrew Hoffman）
14-10-29在18:20
#6 楼
通常可以猜测编码。例如，您在问题中发布的字符串是Base64编码的。等号在Base64方案中填充。我从经验中就知道了这一点。如果您给我一个加密的字符串，我也许可以告诉您编码，但是我不能告诉您用于加密的算法除非某种元数据可用。原因是：加密算法通过产生看似随机的数据来工作。如果我用两个密码（四个输出）分别加密两个句子，那么除非您解密或破解了密码，否则您将无法确定地说哪个密码属于哪个密码。
您的特定实例，密码通常是散列的。这意味着您无法从哈希中恢复密码，但是可以测试以查看哈希是否与密码匹配。在这方面，@ john的答案是黄金。如果您可以输入一个已知的密码，然后尝试使用通用的密码对策，则可以了解所使用的哈希是什么。
#7 楼
唯一的办法就是猜测。凭经验，猜测会更正确。例如：基于输出的长度：MD5输出为128位或16字节，SHA1输出为160位或20字节。基于输出的字符集：BASE64生成带有可打印字符的输出。
归根结底，这是一种反复试验的方法，可以教您如何操作。
#8 楼
唯一的方法是当有一些元数据告诉您时。例如，我最近一直在使用PDF，其格式包括包含过滤器，算法，密钥大小等的字典。但是，如果您所拥有的只是密文，那么您所拥有的只是一些不透明的Blob。数据。#9 楼
这在所有方面都是非常薄弱的安全性！明文为P4 $$ w0rdP4 $$ w0rd，使用XOR加密（密钥为CdZ4MLMPgYtAE9gQ80gMtg ==）进行加密。这将产生以上OP所发布的密文WeJcFMQ / 8 + 8QJ / w0hHh + 0g ==。要验证：
首先，使用xxd获取基础二进制文件明文的形式：
echo -n 'P4$$w0rdP4$$w0rd' | xxd -b -c16
产生的结果是：
01010000 00110100 00100100 00100100 01110111 00110000 01110010 01100100 01010000 00110100 00100100 00100100 01110111 00110000 01110010 01100100
接下来，base64解码密钥并使用xxd获取密钥的基础二进制文件：
echo -n 'CdZ4MLMPgYtAE9gQ80gMtg==' | base64 -d | xxd -b -c16
这产生：
00001001 11010110 01111000 00110000 10110011 00001111 10000001 10001011 01000000 00010011 11011000 00010000 11110011 01001000 00001100 10110110
现在，异或两个二进制字符串：
01010000 00110100 00100100 00100100 01110111 00110000 01110010 01100100 01010000 00110100 00100100 00100100 01110111 00110000 01110010 01100100 (plaintext)
[XOR]
00001001 11010110 01111000 00110000 10110011 00001111 10000001 10001011 01000000 00010011 11011000 00010000 11110011 01001000 00001100 10110110 (key)
-----------------------------------------------------------------------------------------------------------------------------------------------
01011001 11100010 01011100 00010100 11000100 00111111 11110011 11101111 00010000 00100111 11111100 00110100 10000100 01111000 01111110 11010010 (ciphertext)
最后，使用bc，xxd和base64将二进制密文转换为base64：
echo "obase=16; ibase=2; 01011001111000100101110000010100110001000011111111110011111011110001000000100111111111000011010010000100011110000111111011010010" | bc | xxd -p -r | base64
这将产生WeJcFMQ / 8 + 8QJ / w0hHh + 0g ==，这是OP在上面的问题中发布的密文。
如果这个答案我很抱歉似乎是人为的。诚然，是的。与此类似的问题是，发布者仅提供一些密文，并要求对如何生成密文有一些见解，似乎在security.stackexchange.com上经常出现。这个问题通常被认为是这些问题的重复。该答案的目的是说明这种性质的问题是无法回答的，因为这些类型的问题有无限的解决方案。
评论
等待，那么您是否只是选择了一个密码，选择了一个“哈希”方法（XOR），然后强行使用了产生给定密文的密钥？您的最后一句话是金子，但我认为可能值得再强调一点。没有密切关注的人可能会以为您已“解决”问题而轻易走开。
– Conor Mancone
20 Mar 24 '20 at 18:01
@Conor Mancone，感谢您的反馈。 XOR加密可以是``反向工程''的，因此，如果您知道3个变量中的2个（即明文，密钥，密文），则可以轻松找到第三个。 [明文xor密钥=密文，密文xor密钥=明文，明文xor密文=密钥]。我只是组成了一个纯文本（P4 $$ w0rdP4 $$ w0rd），然后使用上面的第三个方程式，找到了生成给定OP的密文的密钥，给定了我选择的明文。我可以选择任何纯文本。
– mti2935
20 Mar 24 '20 at 18:59
我想知道您是否可以直接使用XOR解决。我从来没有详细讨论过实际的加密方法，所以我不太确定。谢谢！
– Conor Mancone
20 Mar 24 '20 at 19:08
评论
方法的某些内容（或指向方法的链接）是为了解释如何在完全零知识的情况下识别某些类型的加密或编码。这些答案大多数都是“不可能的”，我的直觉告诉我，我们这个行业没有什么是不可能的。@atdre感谢您的赏金。这个问题似乎集中在密码散列格式上-您是否也在关注？这对我来说似乎是最好的，如果人们想回答有关文件格式的问题，他们可以问另一个问题。
@atdre：“不可能”通常是“当前技术不可行/在宇宙热死之前无法完成”的快捷方式。
@nealmcb：标识加密或编码的非明文。
我在SE上问了类似的问题：stackoverflow.com/questions/988642/…