Linux'ta parola karmaşasının 6. karakteri nedir ve neden bu genellikle bir eğik çizgidir?

Linux'ta saklanan parolanın altıncı karakteri /etc/shadownedir?

Köpek yavrusu tarzı linux kutumda, shufve kullanarak 100 rastgele şifre oluşturmaya çalışırsam /dev/urandom, o zaman altıncı karakter /yarı yarıya.

Sorum şu ki, üretim amaçlı değil, çünkü her seferinde CD'den yeni başladım. Bu, sistemimin yanlış yapılandırıldığı veya bir şekilde güvensiz olduğu anlamına mı geliyor?

Bağlantı shufolup olmadığını görmek için dosya koştum 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

Bunun burada shufbir busyboxbağlantı olduğunu sanmıyorum .

ls -l /usr/bin/shuf

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

süre

ls -l /bin/wget

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

İşte yaptığım şey hakkında kabaca bir fikir:

# ! / 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. karma karakterin kabaca yarısı /:

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

Karma format ve kaynak

Parola karma biçimi, SHA-256 tabanlı bir karma olduğu $<type>$<salt>$<hash>yerdir <type> 5. Tuz genellikle en az 8 karakterdir (ve söz konusu örneklerdedir), bu yüzden altıncı karakter tuzun bir parçasıdır.

Bu karmalar büyük olasılıkla gölge araç takımının bir versiyonundan kaynaklanmaktadır ( Centian'da shadowDebian'daki src paketi shadow-utils).

Kodun eğik çizgiyi tam olarak neden saptırdığını bulmaya çalıştım. (Başlangıçta kodu kazmak için @ thrig sayesinde.)

TLDR: Biraz ilginç, ama önemli değil.

Tuz üreten kod

İçinde bir döngüde çağıran işlevi libmisc/salt.cbuluruz :gensaltl64a

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

Döngü rastgele bir sayı alır random(), onu bir dizgenin bir parçasına dönüştürür ve bunu tuzu oluşturan dizeye birleştirir. Yeterli karakter toplanana kadar tekrarlayın.

Olanlar yine l64ade daha ilginç. İç döngü, giriş değerinden (gelen random()) bir anda bir karakter oluşturur :

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++;
}

Döngünün ilk satırı ( digit = value & 0x3f) giriş değerinden altı bit alır ve ifyan tümceler, bunlar tarafından oluşturulan değeri bir karaktere dönüştürür. ( .sıfır, /bir, 0iki, vb.)

l64aBir alan longtarafından değerleri bir çıktı random()ile sınırlıdır RAND_MAXglibc'nin üzerinde 1 - 2147483647 veya 2 ^ 31 olduğu görülmektedir. Böylece, giden değer l64arastgele 31 bit sayısıdır. Bir seferde 6 bit veya 31 bitlik bir değer alarak, makul şekilde dağıtılmış beş karakter, artı sadece bir bitlik gelen altıncı bir karakter elde ederiz!

Bununla birlikte, üretilen son karakter l64aa olamaz ., çünkü döngü de koşulu vardır value != 0ve .altıncı karakter yerine l64asadece beş karakter döndürür. Bu nedenle, zamanın yarısı, altıncı karakter /a'dır ve zamanın yarısı l64abeş veya daha az karakter döndürür. İkinci durumda, takip l64aeden ilk pozisyonda bir eğik çizgi de oluşturabilir, bu nedenle tam bir tuzda altıncı karakter, zamanın yarısından biraz fazla bir eğik çizgi olmalıdır.

Kod ayrıca, tuzun uzunluğunu randomize etme fonksiyonuna da sahiptir, 8 ila 16 bayttır. Eğik çizgi karakteri için aynı önyargı l64a, 11. ve 12. karakterlerin başka herhangi bir şeyden daha sık eğik çizgi oluşturmasına neden olacak başka çağrılarla da olur . Soruda sunulan 100 tuz, altıncı pozisyonda 46, 13. ve 15 sıralarında ise sırasıyla 45 eğik çizgiye sahiptir. (Tuzların yarısından biraz az, 11 karakterden daha kısa).

Debian'da

Debian'da bunu chpasswd, soruda gösterildiği gibi dürüst bir şekilde çoğaltamazdım . Ancak chpasswd -c SHA256aynı davranışı gösterir. El kitabına göre, varsayılan eylem, -cPAM'ın karma işlemesini gerçekleştirmesine izin vermemektir, bu nedenle Debian'daki PAM en azından tuzu üretmek için farklı bir kod kullanır. Bununla birlikte, herhangi bir dağıtımdaki PAM koduna bakmadım.

(Bu cevabın önceki versiyonu, etkinin Debian'da görünmediğini belirtti. Bu doğru değildi.)

Önem ve tuzların gereksinimleri

Yine de önemli mi? @RemcoGerlich'in dediği gibi, hemen hemen yalnızca bir kodlama sorunudur. Bu etkili sıfıra tuz bazı bitleri çözecektir, ancak bu bit kökeni bu çağrıdır yana, bu bu durumda önemli bir etkiye sahip olasıdır srandomiçinde seedRNG:

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

Bu, şu anki zamanda bir RNG tohumlama geleneğinin bir çeşididir. ( tv_secve tv_useco andaki zamanın saniye ve mikrosaniyesidir, getpid()eğer çalışan işlem ise işlem kimliğini verir.) Zaman ve PID'ler öngörülemez olmadığından, buradaki rastgelelik miktarı kodlamanın tutabildiğinden daha büyük değildir.

Zaman ve PID, anahtarlar oluşturmak istediğiniz bir şey değildir , ancak tuzlar için yeterince öngörülemeyebilir. Tek bir hesaplama ile birden fazla şifre hashının kaba kuvvet testi yapılmasını önlemek için tuzların belirgin olması gerekir , fakat aynı zamanda hedeflenen önceden hesaplamayı önlemek veya yavaşlatmak için öngörülememesi gerekir ; bu, şifre hashlerinin alınmasından gerçek şifrelerin elde edilmesine kadar geçen süreyi kısaltmak için kullanılabilir. .

Hafif sorunlarda bile, algoritma farklı şifreler için aynı tuzu üretmediği sürece, iyi olmalı. Ve sorudaki listenin gösterdiği gibi, bir döngü içinde birkaç düzine üretirken bile görünmüyor.

Ayrıca, söz konusu kod, şifreler için tuz üretmekten başka bir şey için kullanılmaz, bu nedenle başka bir yerde sorunlara dair bir çıkarım yoktur.

Tuzlar için ayrıca bkz. Örneğin , Yığın Taşması ile ilgili ve bunun için güvenlik .

Sonuç

Sonuç olarak, sisteminizde yanlış bir şey yok. Şifrelerinizin iyi olduğundan ve ilgisiz sistemlerde kullanılmadığından emin olmak düşünmeniz daha faydalı olacaktır.

Bu karakter, crypt(3)kılavuz başına tuzun bir parçasıdır . Tuzun uzunluğunun ( $5$ID ile takip eden arasındaki dize $) sergilenen karma değerler için değiştiği göz önüne alındığında, söz konusu kolondan rastgele bir karakter seçmenin birkaç parola için tam olarak ne olduğundan emin değilim.

Öte yandan, / bir yerine daha fazlasında (102 örneği) yaygın tüm bu kadar şey (18 civarında) diğer olası karakterler karşılaştırıldığında tuz chpasswdtuz içinde bu karakteri teşvik eder gibi görünmektedir;

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'da sistem çalışması şu durumda:

   1006 /
    195 X
    193 U
    193 q
    193 e

Ve, evet, kod, sözlük saldırılarını kolaylaştıracak shadow-utils-4.1.5.1-5.el6bir önyargı sergiliyor /:

#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);
}

Hangi sonuçlarla:

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

Ve sonra aynı rutinleri kullanarak en son https://github.com/shadow-maint/shadow/blob/master/libmisc/salt.c adresinde hala bir önyargı olduğunu görüyoruz /. Yani evet, bu yamalı olması gereken bir böcek, pek /de tercih edilmiyor çünkü ideal olarak tuz karakterleri eşit ağırlıkta olmalı.

mkpasswd(1)Ön uç olabilir crypt(3), ancak chpasswd(1)CentOS'taki "shadow-utils" paketinin ve Debian'da "passwd" nin bir parçası olan koşu ile aynı değil . Bunun yerine, elmalar ile elmaları karşılaştırmalısınız. Aşağıdaki betiği düşünün:

#!/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

Debian Sid'den çıktı:

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'den çıktı:

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

Bu nedenle, sorun CentOS'a özgü değil, ancak her iki projenin de çekmekte olduğu yukarı akıştan geliyor.