लिनक्स पर पासवर्ड हैश का 6 वां वर्ण क्या है, और यह अक्सर स्लैश क्यों होता है?

83

लिनक्स पर, पासवर्ड हैश के छठे वर्ण को किसमें संग्रहीत किया जाता है /etc/shadow?

मेरे पिल्ला स्टाइल के लिनेक्स बॉक्स पर, यदि मैं 100 यादृच्छिक पासवर्ड का उपयोग करके उत्पन्न करने की कोशिश करता हूं , shufऔर /dev/urandomछठा वर्ण /लगभग आधा समय है।

मेरा सवाल उत्पादन के उद्देश्य से नहीं है, क्योंकि मैं इसे हर बार सीडी से ताजा करता हूं। क्या इसका मतलब यह है कि मेरा सिस्टम किसी तरह से गलत या असुरक्षित है?

मैं shufयह देखने के लिए फ़ाइल पर भागा कि क्या यह एक busyboxकड़ी थी।

file /usr/bin/shuf

    shuf: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, stripped

मुझे नहीं लगता कि shufयह एक busyboxकड़ी है।

ls -l /usr/bin/shuf

    -rwxr-xr-x 1 root root 41568 Mar  7  2015 /usr/bin/shuf

जबकि

ls -l /bin/wget

    lrwxrwxrwx 1 root root 14 Apr 29 03:49 wget -> ../bin/busybox

यहाँ मैंने क्या किया का एक मोटा विचार है: 

# ! / b i n / b a s h
##  don't try this on any real computer
##  this is not a production script, it is just psuedo code
##  with pseudo results to illustrate a point

##  for this run of 100 ?random? passwords,
##  46 of the 6th character of the hash stored in
##  '/ect/shadow' were '/'

function is_this_really_a_random_password () {
PERHAPS_RANDOM=''
for (( Z=0 ; Z<=8 ; Z++ )) do
PERHAPS_RANDOM="$PERHAPS_RANDOM$( shuf --head-count=1 --random-source=/dev/urandom $FILE_OF_SAFE_CHARACTERS )"
done
echo "$USER_NAME:$PERHAPS_RANDOM" | chpasswd
}

rm sixth-character-often-forward-slash.txt
for (( I=1; I<=100; I++ )) do
is_this_really_a_random_password
grep --regexp=root /etc/shadow | cut --characters=-40 >> sixth-character-often-forward-slash.txt
done

    root:$5$56YsS//DE$HasM6O8y2mnXbtgeE64zK
    root:$5$ho8pk/4/A6e/m0eW$XmjA5Up.0Xig1e
    root:$5$jBQ4f.t1$vY/T/1kX8nzAEK8vQD3Bho
    root:$5$BJ44S/Hn$CsnG00z6FB5daFteS5QCYE
    root:$5$Jerqgx/96/HlV$9Wms5n1FEiM3K93A8
    root:$5$qBbPLe4zYW$/zXRDqgjbllbsjkleCTB
    root:$5$37MrD/r0AlIC40n6$8hplf2c3DgtbM1
    root:$5$.4Tt5S6F.3K7l7E$dAIZzFvvWmw2uyC
    root:$5$A4dX4ZlOoE$6axanr4GLPyhDstWsQ9B
    root:$5$HXAGhryJ/5$40tgmo7q30yW6OF7RUOE
    root:$5$EzNb9t5d$/nQEbEAQyug7Dk9X3YXCEv
    root:$5$HHS5yDeSP$LPtbJeTr0/5Z33vvw87bU
    root:$5$sDgxZwTX5Sm$6Pzcizq4NcKsWEKEL15
    root:$5$FK1du/Paf/$hAy8Xe3UQv9HIpOAtLZ2
    root:$5$xTkuy/BLUDh/N$/30sESA.5nVr1zFwI
    root:$5$PV4AX/OjZ$VU8vX651q4eUqjFWbE2b/
    root:$5$iDuK0IUGijv4l$cdGh8BlHKJLYxPB8/
    root:$5$0DEUp/jz$JBpqllXswNc0bMJA5IFgem
    root:$5$Wz3og/W3Jra/WKA.$6D7Wd4M1xxRDEp
    root:$5$ntHWB.mC3x$Kt4DNTjRZZzpbFvxpMxP
    root:$5$g/uEc/cq$Ptlgu8CXV.vrjrmuok9RRT
    root:$5$/XAHs/5x$Z9J4Zt4k6NxdjJ27PpLmTt
    root:$5$mgfbZeWD0h/$UDGz8YX.D85PzeXnd2K
    root:$5$f4Oh3/bF2Ox/eN$xt/Jkn0LxPnfKP8.
    root:$5$J0mZZXGJG7/v$e16VxghNvZZKRONown
    root:$5$SNza9XFl9i$Qq7r/N6Knt2j74no8H0x
    root:$5$aFCu//xiL$Ocn9mcT2izcnm3rUlBOJg
    root:$5$kMkyos/SLZ/Mm6$wNYxZ9QeuJ8c8T.o
    root:$5$ujXKC/Xnj0h/nQ$PUmePvJZr.UXmTGK
    root:$5$wtEhA/YKaTKH$6VCSXUiIdsfelkCYWV
    root:$5$I1taRlq59YZUGe$4OyIfByuvJeuwsjM
    root:$5$N54oH//j4nbiB$K4i6QOiS9iaaX.RiD
    root:$5$ps8bo/VjPGMP0y4$NTFkI6OeaMAQL7w
    root:$5$IRUXnXO8tSykA8$NatM5X/kKHHgtDLt
    root:$5$VaOgL/8V$m45M9glUYnlTKk8uCI7b5P
    root:$5$/lPDb/kUX73/F3$jJL.QLH5o9Ue9pVa
    root:$5$/sHNL/tVzuu//cr$QasvQxa02sXAHOl
    root:$5$hGI.SMi/7I$fYm0rZP0F5B2D1YezqtX
    root:$5$WsW2iENKA$4HhotPoLRc8ZbBVg4Z5QW
    root:$5$cN6mwqEl$q5S3U85cRuNHrlxS9Tl/PC
    root:$5$wwzLR/YMvk5/7ldQ$s3BJhq5LyrtZww
    root:$5$GUNvr/d15n8/K$CiNHwOkAtxuWJeNy1
    root:$5$nGE75/8mEjM/A$pD/84iLunN/ZNI/JK
    root:$5$77Dn2dHLS$d5bUQhTz.OU4UA.67IGMB
    root:$5$EWrI//1u$uubkPk3YhAnwYXOYsvwbah
    root:$5$Hzfw1UCudP/N/U$Rjcdzdbov1YgozSJ
    root:$5$2y8CKTj.2eTq$7BEIgMWIzAJLl1SWBv
    root:$5$lcWsD/42g8zEEABA$r/vGxqqUZTkJ0V
    root:$5$LPJLc/Xz$tnfDgJh7BsAT1ikpn21l76
    root:$5$ucvPeKw9eq8a$vTneH.4XasgBIeyGSA
    root:$5$Fwm2eUR7$ByjuLJRHoIFWnHtvayragS
    root:$5$yBl7BtMb$KlWGwBL6/WjgHVwXQh9fJS
    root:$5$1lnnh2kOG$rdTLjJsSpC3Iw4Y6nkPhq
    root:$5$WfvmP6cSfb066Z$1WvaC9iL11bPCAxa
    root:$5$qmf/hHvalWa4GE25$m3O2pdu25QBCwU
    root:$5$4P.oT/9HQ$Ygid4WXi0QCEObLVNsqFZ
    root:$5$FNr4Bkj56Y$38mG7mKV0mdb1PMCxrVd
    root:$5$hoNcyURtV$aTidBWHjngc1I0vUTi5bB
    root:$5$rzHmykYT$ATiXdUDUvUnB2fNMUQgwvE
    root:$5$o11Yb/ZQv2/k3wg9$5yShpVejDBk6HB
    root:$5$REPGN//y9H$awpPmUvCqvi6Bd/6bQxF
    root:$5$HbAEY/djXJx$y56GhMwavd7xTQ.jPg6
    root:$5$3T1k5.LZUcy$Cup.LM5AnaBTIaJtBnF
    root:$5$wXaSC/P8bJ$y/0DoYJVjaP09O6GWiki
    root:$5$YuFfY8QPqm/dD$IIh0/tyn.18xEBl5Y
    root:$5$uTTBpjsKG//3Et8$9ibN9mVwSeVyOI4
    root:$5$dASlMLzbVbFMnZ$N4uGBwGHhdg93z/V
    root:$5$03.FA/LnRBb.k7Zl$XOHU2ZlHkV9oz9
    root:$5$2zL1p/VDCi$/QRT7Bo3cZ3Rxb8Y7ddo
    root:$5$0NpZqZs/qt/jIv.$8W/TTM3Gy2UMOWy
    root:$5$a4SXynoro7ucT$qFM2C79QJ15jQ0ZlL
    root:$5$RL0Eg/jroH8/ONP$EzceXz.pz74k104
    root:$5$O3R5V/n1$U.mmCTbpID8xMXbvtzd4ch
    root:$5$0T2nVrv/P/xaRwUD$YVm17XF8kTsL0f
    root:$5$2bRwMNIXobZwn$Q228FJqg6/iRCe9GQ
    root:$5$PyYgL/axfgj/$uaL5y/kdzU4Kzi.JlB
    root:$5$A6QtfJdJ4Gwvx4$d4PA5AJ0806NzRnm
    root:$5$H8Mta5LDgGXp$QGdOJh.bFWgR3L719Z
    root:$5$H06URjv4BtOAbA$EJs1mZYhdKIVgCmn
    root:$5$OeB.O/GrmFB/az$SoE759KE9WIE17Uf
    root:$5$huiB9/sk$el3XMf7SGX81LnD3.SaF8J
    root:$5$fO7tfM.fjdSHA8G6$s.QIjfNniCzFdU
    root:$5$32at3SQJAD/xlw$HbXmBLVXTTyZfxQv
    root:$5$FHBFL/QdFl$FMipxpW0HlEFUIAr7IxF
    root:$5$sHvKf/M5OPdBuZZ$dz4qLOkTLGeCINX
    root:$5$hw4Vu/e34$/82lXu7ISrse.Ihk.qbqT
    root:$5$k1JOy/jRWZ$30YSk7kbhdKOjfDaiWVf
    root:$5$MnX.LUzqrB/B2$JuwqC.SmKFnMUWkEf
    root:$5$arRYf/PG$Xw6PpZNFO656p.Eb636iLt
    root:$5$5op/p8Hqs5$Nj2jA0Qxm80aG4fHW3oz
    root:$5$VHIT9/8yzZ$CpIK4ODps78GcqcsgiMT
    root:$5$.AlH7jBJoh/8$sjuVt.PcRH.vyvB3og
    root:$5$f7Ewinqm$nrJ2p/hKTuiEK//IfCTjth
    root:$5$N.dv/VCvrCADg$peSXfo35KN1dmbw/n
    root:$5$PSc4W./54l/SroH$CFFVOHRYK.Jj8Sp
    root:$5$8UBP3f4IcnAd/N1/$P.ud49qTStQ7Lw
    root:$5$qnXsZ/NlLZh/$nlaQVTS3FCJg1Jb2QG
    root:$5$xOpbbBqENR/7$boYJQzkCkZhRf7Uicf
    root:$5$V93tjZhzT$LrsIZWZmYo4ocRUvCixO6
    root:$5$1MVz8/lf5oC/$rUKpnX23MhFx4.y2ZS

6 हैश वर्णों में से लगभग आधे हैं /:

cat sixth-character-often-forward-slash.txt | cut --character=14 | sort


    /
    /
    /
    /
    /
    /
    /
    /
    /
    /
    /
    /
    /
    /
    /
    /
    /
    /
    /
    /
    /
    /
    /
    /
    /
    /
    /
    /
    /
    /
    /
    /
    /
    /
    /
    /
    /
    /
    /
    /
    /
    /
    /
    /
    /
    /
    .
    .
    .
    .
    2
    5
    6
    8
    8
    B
    d
    D
    e
    e
    E
    f
    H
    I
    j
    j
    j
    J
    k
    k
    K
    l
    L
    M
    M
    n
    n
    N
    q
    r
    r
    r
    s
    S
    S
    t
    t
    T
    U
    U
    U
    U
    V
    w
    x
    X
    X
    X
    Z
    Z
    Z
password  shadow 
— असुरक्षित
स्रोत
3
man 3 cryptऔर इस क्षेत्र के पूर्ण विवरण के लिए NOTES अनुभाग पढ़ें।
— स्टीफन हैरिस
(पूरी तरह से जांच करने के इच्छुक व्यक्ति के लिए एक संकेत के रूप में छोड़ दिया गया): पासवर्ड फ़ील्ड में उपयोग किए जाने वाले 64 वर्ण हैं; इसलिए कुछ बेस 64 वैरिएंट का उपयोग किया जाता है। इसलिए मैं चाहता हूँ लगता है कि आप जो देख रहे base64 गद्दी है, लेकिन यह अजीब है कि यह नमक के अंत में नहीं है तो है ...
— derobert
1
डेबियन परीक्षण और mkpasswd के साथ, ऐसा नहीं होता है - यदि यह आपके लिए mkpasswd के साथ होता है तो उत्सुक है (जैसा कि वास्तव में रूट पासवर्ड सेट करने की तुलना में परीक्षण करना आसान होगा):for ((i=0; i<50; ++i)); do pwgen -1 -s 16 | mkpasswd -m sha-256 --stdin ; done | cut -c9 | sort | uniq -c
— derobert
मैं इसे वर्तमान Ubuntu 14.04 या 16.04 पर पुन: उत्पन्न नहीं कर सकता। स्लैश आवृत्ति सूची के बीच में है (50 के बजाय 5000 छोरों के साथ @derobert स्निपेट का उपयोग किया जाता है), लेकिन यह अभी भी थोड़ा गैर-समान दिखता है, सबसे अक्सर चार (कुल) @ 2.00% कुल 1.63 से कम अक्सर अधिक है लगातार एक (r) @ कुल 1.22%।
— arielf
@ मुझे यह संदेह है कि एक सांख्यिकीय-महत्वपूर्ण है। आपको यह सुनिश्चित करने के लिए χ2 टेस्ट जैसा कुछ करना होगा , लेकिन यह यूनिक्स और लिनक्स क्षेत्र के बाहर अच्छी तरह से है और क्रॉस वैध क्षेत्र में हो रहा है।
— derobert

जवाबों:

86

हैश प्रारूप और स्रोत

पासवर्ड हैश का प्रारूप है $<type>$<salt>$<hash>, जहां <type> 5SHA-256 आधारित हैश है। नमक आमतौर पर कम से कम 8 वर्ण होता है, (और उदाहरण में प्रश्न में है) इसलिए छठा वर्ण नमक का हिस्सा है।

उन हैश की संभावना छाया उपकरण सूट के एक संस्करण (सेनोस shadowमें डेबियन में src पैकेज shadow-utils) द्वारा उत्पन्न होती है

मैंने यह पता लगाने की कोशिश की कि, वास्तव में, कोड स्लैश को बायपास क्यों करता है। (मूल रूप से कोड खुदाई के लिए @thrig का धन्यवाद।)

TLDR: यह थोड़ा दिलचस्प है, लेकिन कोई फर्क नहीं पड़ता।

नमक पैदा करने वाला कोड

में libmisc/salt.c, हम एक पाश में gensaltकॉल करने वाले फ़ंक्शन को पाते हैं l64a:

strcat (salt, l64a (random()));
do {
       strcat (salt, l64a (random()));
} while (strlen (salt) < salt_size);

लूप एक यादृच्छिक संख्या लेता है random(), इसे एक स्ट्रिंग के एक टुकड़े में बदल देता है, और इसे नमक बनाने वाले स्ट्रिंग तक पहुंचता है। तब तक दोहराएं जब तक कि पर्याप्त वर्ण एकत्र न हो जाएं।

क्या होता है l64a, हालांकि अधिक दिलचस्प है। आंतरिक लूप इनपुट मान से एक बार में एक वर्ण उत्पन्न करता है (जो आया था random()):

for (i = 0; value != 0 && i < 6; i++) {
    digit = value & 0x3f;

    if (digit < 2) {
        *s = digit + '.';
    } else if (digit < 12) {
        *s = digit + '0' - 2;
    } else if (digit < 38) {
        *s = digit + 'A' - 12;
    } else {
        *s = digit + 'a' - 38;
    }

    value >>= 6;
    s++;
}

लूप की पहली पंक्ति ( digit = value & 0x3f) इनपुट मूल्य से छह बिट्स को चुनती है, और ifखंड उन वर्णों द्वारा निर्मित मान को एक वर्ण में बदल देते हैं। ( .शून्य के लिए, /एक के लिए, 0एक दो के लिए, आदि)

l64aलेता है, longलेकिन इसके द्वारा मानों का उत्पादन random()सीमित हो जाता है RAND_MAX, जो ग्लिबैक पर 2147483647 या 2 ^ 31 - 1 प्रतीत होता है। तो, जो मान जाता है l64aवह 31 बिट्स की एक यादृच्छिक संख्या है। एक बार में 6 बिट्स या 31 बिट वैल्यू लेने से, हमें पांच समान रूप से वितरित वर्ण मिलते हैं, साथ ही एक छठा जो केवल एक बिट में आता है!

द्वारा उत्पन्न अंतिम वर्ण l64aएक नहीं हो सकता .है, तथापि, के बाद से पाश भी हालत है value != 0, और एक के बजाय .के रूप में छठे चरित्र, l64aकेवल पाँच वर्ण देता है। इसलिए, आधा समय, छठा वर्ण एक है /, और आधा समय l64aपांच या उससे कम वर्ण देता है। बाद के मामले में, निम्नलिखित l64aभी पहले पदों में एक स्लैश उत्पन्न कर सकते हैं, इसलिए एक पूर्ण नमक में, छठे चरित्र को आधे से थोड़ा अधिक समय में स्लैश होना चाहिए।

कोड में नमक की लंबाई को यादृच्छिक करने के लिए एक फ़ंक्शन भी है, यह 8 से 16 बाइट्स है। स्लैश चरित्र के लिए एक ही पूर्वाग्रह भी आगे की कॉल के साथ होता है l64aजिसके कारण 11 वें और 12 वें चरित्र का स्लैश भी किसी अन्य चीज़ की तुलना में अधिक बार होता है। प्रश्न में प्रस्तुत 100 लवणों में छठे स्थान पर 46 और क्रमशः 11 वें और 12 वें स्थान पर 13 और 15 हैं। (आधे से कम लवण 11 वर्णों से कम होते हैं)।

डेबियन पर

डेबियन पर, मैं इसे सीधे के साथ पुन: पेश नहीं कर सका chpasswdजैसा कि प्रश्न में दिखाया गया है। लेकिन chpasswd -c SHA256वही व्यवहार दिखाता है। मैनुअल के अनुसार, डिफ़ॉल्ट कार्रवाई, बिना -c, PAM को हैशिंग को संभालने देना है, इसलिए जाहिर तौर पर डेबियन पर PAM कम से कम नमक बनाने के लिए एक अलग कोड का उपयोग करता है। हालाँकि, मैं किसी भी वितरण पर PAM कोड को नहीं देखता था।

(इस उत्तर के पिछले संस्करण में कहा गया है कि प्रभाव डेबियन पर नहीं दिखाई दिया। यह सही नहीं था।)

लवण के लिए महत्व और आवश्यकताएं

क्या यह मायने रखता है, हालांकि? जैसा कि @RemcoGerlich ने टिप्पणी की, यह बहुत ही एन्कोडिंग का सवाल है। यह प्रभावी रूप से नमक के कुछ बिट्स को शून्य तक ठीक कर देगा, लेकिन यह संभावना है कि इस मामले में इसका कोई महत्वपूर्ण प्रभाव नहीं होगा, क्योंकि उन बिट्स की उत्पत्ति इस कॉल srandomमें है seedRNG:

srandom (tv.tv_sec ^ tv.tv_usec ^ getpid ());

यह वर्तमान समय के साथ RNG को सीड करने का एक पुराना रीति रिवाज है। ( tv_secऔर tv_usecवर्तमान समय के कुछ सेकंड्स और माइक्रोसेकंड हैं, getpid()यदि प्रक्रिया चल रही हो तो प्रक्रिया को आईडी देता है।) जैसा कि समय और पीआईडी ​​बहुत अप्रत्याशित नहीं हैं, यहां यादृच्छिकता की मात्रा एन्कोडिंग को धारण करने की तुलना में बड़ी नहीं है।

समय और पीआईडी ​​ऐसा कुछ नहीं है जिसके साथ आप कुंजी बनाना चाहते हैं , लेकिन लवण के लिए अप्रत्याशित रूप से पर्याप्त हो सकता है। एक ही गणना के साथ कई पासवर्ड हैश ब्रूट-बल परीक्षण को रोकने के लिए लवण अलग होना चाहिए, लेकिन लक्षित पूर्वसंक्रमण को रोकने या धीमा करने के लिए अप्रत्याशित भी होना चाहिए , जिसका उपयोग पासवर्ड को वास्तविक पासवर्ड प्राप्त करने के लिए हैश करने से समय को कम करने के लिए किया जा सकता है ।

यहां तक ​​कि मामूली मुद्दों के साथ, जब तक एल्गोरिथ्म अलग-अलग पासवर्ड के लिए समान नमक उत्पन्न नहीं करता है, तब तक यह ठीक होना चाहिए। और यह प्रतीत नहीं होता है, यहां तक ​​कि जब लूप में एक दर्जन युगल पैदा करते हैं, जैसा कि प्रश्न दिखाता है।

इसके अलावा, प्रश्न में कोड का उपयोग पासवर्ड के लिए लवण उत्पन्न करने के लिए कुछ भी नहीं किया जाता है, इसलिए कहीं और समस्याओं के बारे में कोई निहितार्थ नहीं है।

लवण के लिए, यह भी देखें, यह स्टैक ओवरफ्लो पर और सुरक्षा पर ।

निष्कर्ष

अंत में, आपके सिस्टम में कुछ भी गलत नहीं है। यह सुनिश्चित करना कि आपके पासवर्ड किसी भी अच्छे हैं, और असंबंधित सिस्टम पर उपयोग नहीं किया जाता है, इसके बारे में सोचने के लिए अधिक उपयोगी है।

— ilkkachu
स्रोत
2
इसलिए वास्तविक लवण पक्षपाती नहीं हैं, यह सिर्फ एक कलाकृति है कि वे कैसे एन्कोडेड हैं और इसका कोई सुरक्षा प्रभाव नहीं है, क्या यह सही है?
— रेमकोगर्लिच
8
@RemcoGerlich यह एक पूर्वाग्रह की पाठ्यपुस्तक की परिभाषा है। क्योंकि सभी बिट्स के लिए समान रूप से जिम्मेदार नहीं हैं। यह अन्य परियोजनाओं में भी निहितार्थ रखता है जहां इस कोड का उपयोग गैर-नमक संदर्भ में किया जाता है। पासवर्ड के लिए / etc / shadow में लवण के रूप में, यह शोस्टॉपर नहीं है, लेकिन यह चिंता का विषय है।
— आरोन टोपनोसे 16
@RemcoGerlich, बहुत ज्यादा हां। ठीक है, यह एक मजबूत आरएनजी नहीं है, इसलिए हम इसमें पक्षपात के बारे में बात कर सकते हैं। लेकिन सुरक्षा के लिहाज से यह नमक के लिए कोई मायने नहीं रखता।
— ilkachachu
3
आपने सुरक्षा के बारे में गलत व्याख्या की है। आप जिस पोस्ट से जुड़े हैं, और जो एसओ पोस्ट से आप जुड़े हैं, उसका स्वीकृत उत्तर गलत है, यही कारण है कि 10x से अधिक वोटों के साथ एक और जवाब है जो इसके विपरीत है। यह कथन कि "लवण को केवल अलग होने की आवश्यकता है" सत्य नहीं है; एक नमक का एन्ट्रापी मायने रखता है, क्योंकि यह वही है जो नियंत्रण करता है कि यह प्रीकम्प्यूटेशन की कठिनाई को कितना बढ़ाता है। पूर्वाग्रह के कारण ये लवण अपनी लंबाई के मुकाबले कम एन्ट्रापी होते हैं। गंभीर रूप से कम नहीं , लेकिन 5 बिट्स की तरह कुछ कम। यह एक दोष है।
— हॉब्स
शायद किसी को एक सुरक्षा करनी चाहिए। एक प्रश्न विशेष रूप से योग्य राय प्राप्त करने के लिए इस फ़ंक्शन को संदर्भित करता है।
— हॉब
26

यह चरित्र प्रति crypt(3)मैनुअल नमक का हिस्सा है । यह देखते हुए कि नमक की लंबाई ( $5$आईडी और बाद में स्ट्रिंग $) प्रदर्शित की गई हैश के लिए भिन्न होती है, मुझे बिल्कुल यकीन नहीं है कि कुछ पासवर्डों के लिए उस विशेष कॉलम से एक यादृच्छिक चरित्र क्या दिखाता है।

दूसरी ओर, / है बल्कि अधिक में प्रचलित (102 मामले) पूरे अन्य संभावित वर्ण (18 के आसपास), तो में कुछ की तुलना में नमक chpasswdनमक में उस चरित्र के पक्ष में दिखाई देता है;

for x in `seq 1 100000`; do
  echo testacct:asdfasdfasdf | chpasswd -c SHA256
  awk -F: '/testacct/{print $2}' /etc/shadow | awk -F\$ '{print $3}' >> salts
done
perl -nle 'print for m/(.)/g' salts | sort | uniq -c | sort -nr | head -5

RedHat EL 6 सिस्टम रन पर मुड़ता है:

   1006 /
    195 X
    193 U
    193 q
    193 e

और, हाँ, कोड shadow-utils-4.1.5.1-5.el6एक पूर्वाग्रह प्रदर्शित करता है /जिसके लिए शब्दकोश हमले आसान हो सकते हैं:

#include <sys/time.h>

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>

// these next two borrowed from libmisc/salt.c of shadow-4.1.5.1 from
// Centos 6.8 RPM at http://vault.centos.org/6.8/os/Source/SPackages/shadow-utils-4.1.5.1-5.el6.src.rpm
char *l64a(long value)
{
    static char buf[8];
    char *s = buf;
    int digit;
    int i;

    if (value < 0) {
        abort();
    }

    for (i = 0; value != 0 && i < 6; i++) {
        digit = value & 0x3f;

        if (digit < 2) {
            *s = digit + '.';
        } else if (digit < 12) {
            *s = digit + '0' - 2;
        } else if (digit < 38) {
            *s = digit + 'A' - 12;
        } else {
            *s = digit + 'a' - 38;
        }

        value >>= 6;
        s++;
    }

    *s = '\0';

    return (buf);
}

static void seedRNG(void)
{
    struct timeval tv;
    static int seeded = 0;

    if (0 == seeded) {
        (void) gettimeofday(&tv, NULL);
        srandom(tv.tv_sec ^ tv.tv_usec ^ getpid());
        seeded = 1;
    }
}

int main(void)
{
    seedRNG();
    for (int x = 0; x < 1000; x++) {
        printf("%s\n", l64a(random()));
    }

    exit(0);
}

जिसके परिणामस्वरूप:

% ./salttest | perl -nle 'print for m/(.)/g' | sort | uniq -c | sort -nr | head -3
 593 /
  96 8
  93 3

और फिर नवीनतम https://github.com/shadow-maint/shadow/blob/master/libmisc/salt.c से उसी रूटीन का उपयोग करके हम पाते हैं कि अभी भी एक पूर्वाग्रह है /। तो उह यह एक बग है जिसे पैच किया जाना चाहिए /ताकि इतना पसंदीदा न हो, क्योंकि आदर्श रूप से नमक के पात्रों को समान रूप से भारित किया जाना चाहिए।

— thrig
स्रोत
14
नमक में गैसें अपने आप में हानिकारक नहीं होती हैं (बायसेज़ के विपरीत, कहते हैं, एक कुंजी)। नमक को केवल विशिष्ट होना चाहिए, इसे अप्रत्याशित होने की आवश्यकता नहीं है। एक मैक पते (या मशीन की विशिष्ट पहचान) और समय (घड़ी पीछे नहीं जाती है) से युक्त नमक ठीक होगा। यह कथन कि "आदर्श रूप से नमक पात्रों को समान रूप से भारित किया जाना चाहिए" गलत है।
— गाइल्स
7
@thrig नहीं, एक पूर्वानुमानित नमक शब्दकोश हमलों के साथ मदद नहीं करता है, क्योंकि एक नमक शब्दकोश हमलों के साथ मदद नहीं करता है। एक नमक उन हमलों में मदद करता है जो कई खातों को लक्षित करते हैं (अधिक सटीक: एकाधिक हैश - एक ही खाते पर क्रमिक हैश), और इसके लिए, यह सब मायने रखता है कि नमक अलग-अलग खातों के लिए अलग है। लवण की अप्रत्याशितता अप्रासंगिक है, केवल उनकी विशिष्टता (वास्तव में, यहां तक ​​कि एक कम दोहराने की गिनती काफी अच्छी है)।
— गिल्स
3
गाइल्स जो कह रहे हैं उसका मुख्य बिंदु यह है कि नमक जनरेटर के खराब होने के लिए बहुत जगह है लेकिन लगभग इतना बुरा नहीं है कि एक ही छाया फ़ाइल में वास्तविक टकराव हो (या कई प्रणालियों में एक हमलावर एक बार में हमला कर सकता है )। यह सब काम करने के लिए नमक के लिए मायने रखता है। रेनबो टेबल्स को हराने के लिए केवल यादृच्छिकता का एक सा लगता है ।
— पीटर कॉर्ड्स
7
हालांकि, अगर नमक बुरी तरह से उत्पन्न होता है, तो यह बाकी क्रिप्टो कोड में विश्वास को प्रेरित नहीं करता है।
— इम्बिसिस
3
लवण के साथ, उन्हें विश्व स्तर पर अद्वितीय होने की आवश्यकता है। उन्हें यादृच्छिक होने की आवश्यकता नहीं है, और उन्हें गुप्त होने की आवश्यकता नहीं है। लेकिन उन्हें विश्व स्तर पर अद्वितीय होने की आवश्यकता है। यह पता चला है, यह करने के लिए कठिन है अगर आप एक काउंटर को बढ़ाने की कोशिश करते हैं, या ओएस आरएनजी से यादृच्छिक बिट्स को हथियाने की तुलना में कुछ फैंसी नियतात्मक एल्गोरिथ्म बनाते हैं। यदि आप बेतरतीब ढंग से 16 बेस 64 अक्षर उत्पन्न करते हैं, तो आपके पास टक्करों का एक / 64 ^ 16 मौका है। बेशक, लवण की पूरी बात, इंद्रधनुष तालिका हमलों को बेकार बनाना है। इस मामले में, 16-वर्ण बेस 64 नमक स्थान 64 ^ 15 <n <64 ^ 16 होगा। शोस्टॉपर नहीं, लेकिन आसानी से तय हो गई।
— एरोन टोपोन्से 17
4

mkpasswd(1)एक फ्रंट-एंड हो सकता है crypt(3), लेकिन यह चलने के समान नहीं है chpasswd(1), जो कि CentOS पर "छाया-बर्तन" पैकेज का हिस्सा है और डेबियन पर "पासवार्ड" है। इसके बजाय, आपको सेब-से-सेब की तुलना करनी चाहिए। निम्नलिखित स्क्रिप्ट पर विचार करें:

#!/bin/bash

# This repeatedly changes a `saltuser' password
# and grabs the salt out of /etc/shadow.
# Requires root and the existence of `saltuser' user.

if [ $EUID -ne 0 ]; then
    echo "This script requires root access to read /etc/shadow."
    exit 1
fi

grep -q saltuser /etc/passwd

if [ $? -ne 0 ]; then
    echo "This script requires the 'saltuser' to be present."
    exit 2
fi

: > /tmp/salts.txt

for i in {1..1000}; do
    PW=$(tr -cd '[[:print:]]' < /dev/urandom | head -c 64)
    echo "saltuser:${PW}" | chpasswd -c SHA256 -s 0 2> /dev/urandom
    awk -F '$' '/^saltuser/ {print $3}' /etc/shadow >> /tmp/salts.txt
done

while read LINE; do
    # 6th character in the salt
    echo ${LINE:5:1}
done < /tmp/salts.txt | sort | uniq -c | sort -rn

डेबियन सिड से आउटपुट:

512 /
 14 T
 13 W
 13 v
 13 t
 12 x
 12 m
 12 d
 11 p
 11 L
 11 F
 11 4
 10 s
 10 l
 10 g
 10 f
 10 7
 10 6
  9 Z
  9 w
  9 N
  9 H
  9 G
  9 E
  9 A
  8 Y
  8 X
  8 r
  8 O
  8 j
  8 c
  8 B
  8 b
  8 9
  7 u
  7 R
  7 q
  7 P
  7 M
  7 k
  7 D
  6 z
  6 y
  6 U
  6 S
  6 K
  6 5
  5 V
  5 Q
  5 o
  5 J
  5 I
  5 i
  5 C
  5 a
  5 3
  4 n
  4 h
  4 e
  4 2
  4 0
  4 .
  3 8
  3 1

CentOS 7 से आउटपुट:

504 /
 13 P
 13 B
 12 s
 12 Z
 11 e
 11 Y
 11 O
 11 L
 11 G
 10 w
 10 u
 10 q
 10 i
 10 h
 10 X
 10 I
 10 E
  9 x
  9 g
  9 f
  9 W
  9 F
  9 C
  9 9
  9 8
  8 v
  8 t
  8 c
  8 b
  8 S
  8 H
  8 D
  8 0
  7 z
  7 y
  7 o
  7 k
  7 U
  7 T
  7 R
  7 M
  7 A
  7 6
  7 4
  7 1
  6 p
  6 d
  6 a
  6 Q
  6 J
  6 5
  6 .
  5 r
  5 m
  5 j
  5 V
  5 3
  5 2
  4 n
  4 l
  4 N
  4 K
  3 7

तो, समस्या CentOS के लिए अद्वितीय नहीं है, लेकिन संभावना है कि ऊपर की ओर से आ रही है जहां दोनों परियोजनाएं खींच रही हैं।

— हारून टोपनोसे
स्रोत
के : > /tmp/salts.txtरूप में ही है touch /tmp/salts.txt? :एनओपी है, है ना?
— someonewithpc
1
@someonewithpc यह एक फ़ाइल खाली करने का POSIX तरीका है। touch(1)यदि यह मौजूद नहीं है, तो एक फ़ाइल बनाता है, लेकिन अगर यह मौजूद है तो बस संशोधित टाइमस्टैम्प को अपडेट करता है। यह किसी फ़ाइल को खाली करने का सही तरीका नहीं है। : > fileगारंटी होगी कि यह मौजूद है और यह खाली है।
— एरॉन टोपनोस 23
@ ऐरन, हाँ, आप बिल्कुल सही हैं। यह एक वितरण के लिए पूरी तरह से विशिष्ट नहीं है।
— लक्कू
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.