您的示例字符串（ WeJcFMQ / 8 + 8QJ / w0hHh + 0g == ）是16字節序列的Base64編碼，看起來不像有意義的ASCII或UTF-8。 如果這是為密碼 verification 存儲的值（即不是真正的“加密”密碼，而是“散列”密碼），那麼這可能是哈希函數的結果通過密碼計算；一個具有128位輸出的經典哈希函數是MD5。

了解這一點的“正常”方法是查看應用程序代碼。應用程序代碼以有形，繁瑣的方式（服務器上的可執行文件，某處的源代碼...）來實現，它沒有，也沒有像密鑰那樣受到盡可能多的保護。因此，逆向工程是“走的路”。

除非進行逆向工程，否則您可以做一些實驗來嘗試做出有根據的猜測：

• 如果同一用戶“ “更改”他的密碼，但重複使用相同的密碼，儲值是否會更改？如果是，則該值的一部分可能是隨機的“鹽”或IV（假定對稱加密）。
• 假定該值是給定用戶的密碼確定性值，如果兩個用戶選擇相同的值密碼，是否得到相同的儲值？如果否，則用戶名可能是計算的一部分。您可能想嘗試計算MD5（“ username：password”）或其他類似的變體，以查看是否匹配。
• 密碼長度是否受限制？也就是說，如果您設置了40個字符的密碼，並且僅輸入前39個字符就無法成功進行身份驗證，那麼這意味著所有字符都很重要，這意味著這實際上是密碼 hashing ，而不是加密（存儲的值用於驗證密碼，但是不能僅從存儲的值中恢復密碼）。

編輯：我剛剛注意到一個名為 hashID的非常酷的腳本。

~~~

通常，用經驗做有根據的猜測是這些事情的完成方式。

這裡是一個列表中包含大量的哈希輸出，這樣您就可以知道每個哈希表的外觀並創建簽名/圖案，或者只是進行光學驗證。

• 在線哈希散列哈希生成器
• InsidePro軟件論壇>哈希類型（通過Archive.org）

您首先要完成兩個 main 事情注意：

• 哈希的長度（每個哈希函數都有特定的輸出長度）
• 使用的字母（都是英文字母嗎？數字0-9和AF十六進制？有什麼特殊字符？）

幾個密碼破解程序（例如，開膛手約翰）對輸入應用了一些模式匹配，以猜測所使用的算法，但這僅適用於通用哈希。例如，如果您獲取任何哈希輸出並將每個字母旋轉1，則大多數模式匹配方案都會失敗。

您發布的是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。

這取決於格式-一些用於存儲加密文本的協議具有明文部分，用於定義加密方式。從您的示例中，我很懷疑，因為您引用的字符串太短，以至於看起來只是加密的文本。

我建議您考慮一下：

• 最後的“ ==”絕對是填充，因此不要在任何解密嘗試中包括。

• 您可能正在處理哈希或鹽化哈希，而不是加密。在這種情況下，嘗試“解密”數據將不起作用-您需要使用與原始使用的相同的哈希值和/或鹽值來匹配密碼。用鹽醃的密碼無法獲得原始值。

• 您的絕對最佳選擇是獲取用於存儲密碼的代碼副本。那裡的某個地方，密碼正在進行加密操作。查找代碼以了解此處發生的情況。在10的9倍中，他們使用某種API進行哈希/鹽醃/加密，您可以使用相同的API進行模仿或逆向操作。

通常可以猜測編碼。例如，您在問題中發布的字符串是Base64編碼的。等號在Base64方案中填充。憑經驗我知道這一點。

如果您給我一個已加密的字符串，我也許可以告訴您編碼，但是我不能告訴您用於加密的算法，除非某種元數據可用。原因是：加密算法通過產生看似隨機的數據來工作。如果我用兩個密碼（四個輸出）分別加密兩個句子，那麼除非您解密或破解了密碼，否則您將無法確定地說哪個密碼文本屬於哪個密碼。

關於您的密碼在特定的實例中，密碼通常是散列的。這意味著您無法從哈希中恢復密碼，但是可以測試以查看哈希是否與密碼匹配。在這方面， @john的答案是黃金。如果您可以輸入一個已知的密碼，然後嘗試使用通用的密碼對策，則可以了解所使用的哈希是什麼。

如果這確實是簡單的密碼哈希，我們也許可以使用Google進行破解。不過，使用所有這些斜杠和加號很難搜索Base64，因此讓我們首先將哈希轉換為十六進制：

  $ perl -MMIME :: Base64 -le'print unpack“ H *”，decode_base64“ WeJcFMQ / 8 + 8QJ / w0hHh + 0g ==“'59e25c14c43ff3ef1027fc3484787ed2  

確定，現在我們可以為此使用Google了。目前，我從 md5this.com中僅獲得一擊，儘管顯然很快，包括這篇文章在內，還會有更多。

不幸的是（或者幸運的是，取決於您的觀點），我們還沒有足夠幸運地找到原像（該站點當前將此哈希表列為“ cracking ...”），但實際上它確實在該列表中確實強烈暗示這確實是真實密碼的未加鹽的MD5哈希。

唯一的方法就是猜測。憑經驗，猜測會更正確。

例如：根據輸出的長度：MD5輸出為128位或16字節，SHA1輸出為160位或20字節。基於輸出的字符集：BASE64生成帶有可打印字符的輸出。

最終，通過試錯法教您如何操作。

唯一的方法是當有一些元數據告訴您時。例如，我最近一直在使用PDF，並且格式包括包含過濾器，算法，密鑰大小等的字典。但是，如果您所擁有的只是密文，那麼您所擁有的只是一個不透明的Blob。數據。

這在所有方面都是非常薄弱的​​安全性！純文本為 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  

現在，對兩個二進製字符串進行XOR：

  01010000 00110100 00100100 00100100 01110111 00110000 01110010 01100100 01010000 00110100 00100100 00100100 01110111 00110000 01110010 01100100（純文本）[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（密文） 

最後，使用bc，xxd和base64轉換到base64的二進制密文：

  echo“ obase = 16; ibas e = 2; 01011001111000100101110000010100110001000011111111110011111011110001000000100111111111000011010010000100011110000111111011010010“ | bc | xxd -p -r | base64  

這將產生 WeJcFMQ / 8 + 8QJ / w0hHh + 0g == ，這是OP在上述問題中發布的密文。

如果您對此表示歉意，這個答案似乎是人為的。誠然，是的。與此類似的問題是，發帖人僅提供一些密文，並要求對如何生成密文有一些見解，似乎在security.stackexchange.com上經常出現。這個問題通常被認為是這些問題的重複。這個答案的目的是說明這種性質的問題是無法回答的，因為這些類型的問題有無限的解決方案。