爲什麼鹽被包含在用C crypt函數哈希

看這個很基本的C程序：爲什麼鹽被包含在用C crypt函數哈希

#include <stdio.h> 
#include <stdlib.h> 
#include <string.h> 
#include <sys/types.h> 
#include <unistd.h> 
#include <crypt.h> 

int main (int argc, char *argv[]) 
{ 
    char pid[16]; 
    int id; 
    for (id = 0; id < 100; id++) 
    { 
     snprintf(pid, sizeof(pid), "%i", id); 
     printf("%s %s\n",pid, crypt(pid, "$1$awesome")); 
    } 
}

這裏是Linux系統上的輸出：

0 $1$awesome$cVjo4Ue9HeJs7sStMTm6v. 
1 $1$awesome$6.658tD5uVqwQJ6/S8Mc71 
2 $1$awesome$bKavcHTWRGnlTgP.zTZhO. 
3 $1$awesome$ZlBH.fgxGrfw/naq38hyv. 
4 $1$awesome$aQCliN7gPud1PC07Vri.y1 
5 $1$awesome$EewcRVU39I/n0uMGaDxCN0 
6 $1$awesome$fKMRDZaa5wra4G8xy9.m0/ 
7 $1$awesome$AqJ0SmXImg.xcUg/Yh/ov. 
8 $1$awesome$bT3Wq9QORw1dnNZFZmVBk. 
9 $1$awesome$4uM8mfZGdj2zeZ/CP/GSz1 
10 $1$awesome$Gsa/ilcFg1LRl2dqNhgXg0

我不明白爲什麼鹽在輸出中可見。我試圖在Mac OS X上編譯相同的程序，但沒有看到散列中的鹽。這不是一個安全漏洞嗎？我們不應該在哈希中清楚地看到鹽？

感謝

來源

2017-09-13 Bob5421

不，這不是安全漏洞。您需要存儲鹽以便能夠散列下一個輸入並進行比較。鹽的目的是迫使攻擊者單獨處理每個密碼，而不是一個祕密。你用同樣的鹽來解決這個問題。它應該是隨機的。見例如https://security.stackexchange.com/questions/51959/why-are-salted-hashes-more-secure-for-password-storage – jonrsharpe

一種重要的注意：'crypt'功能是不是C標準的一部分。它是[POSIX標準]的一部分（http://pubs.opengroup.org/onlinepubs/9699919799/functions/crypt.html）。 –

鹽不** **不必須保持祕密見：[隱藏鹽的哈希的必要性（https://stackoverflow.com/questions/213380/the-necessity-of-hiding-the-鹽換一個散列）。 –

閱讀從誰最初提出它的研究人員section 3。它說什麼@jonrsharpe在上面的評論說，但總是很高興得到原始源（重點煤礦）：

關鍵搜索技術仍可能當它在一個用於打開了幾個密碼大量的密碼集合，並且似乎明智地使這個任務儘可能地困難。爲此，當第一次輸入密碼時，密碼程序獲得一個12位隨機數（通過讀取實時時鐘）並將其附加到用戶輸入的密碼。連接的字符串是加密的，並且加密的12位隨機數（稱爲鹽）和64位結果都被輸入到密碼文件中。

當用戶稍後登錄到系統時，將從密碼文件中提取12位數量並附加到輸入的密碼。與以前一樣，加密結果與密碼文件中剩餘的64位中的相同。這個修改不會增加查找任何個人密碼的任務，從開始，但現在測試給定字符串的工作對大量的加密密碼已經乘以4,096, （2^12）。原因是每個密碼有4,096個加密版本，其中一個已被系統隨機挑選或多或少地選取。

通過這種修改，壞人可能會花費幾天的時間在計算機上試圖在具有數百個密碼的密碼的系統上找到密碼，並且根本找不到任何密碼。更重要的是事實上，事先準備一個加密的字典是不切實際的。這樣的加密字典可以用來在毫秒出現時破解新密碼。

此修改存在（無意）的副作用。變得幾乎不可能找出在兩個或多個系統上使用密碼爲的人是否在所有人身上都使用了相同的密碼，除非您已經知道這一點，否則。

來源

2017-09-13 10:10:52 TheGreatContini

爲什麼鹽被包含在用C crypt函數哈希

回答

相關問題