hibp.sh

hátha később hasznos lesz

$ cat hibp.sh
#!/bin/sh
# https://haveibeenpwned.com/API/
# 551 509 767 pw in 2019 feb

for p in openssl curl ; do which $p >/dev/null 2>&1 || { echo "ERROR: no $p"; exit 1; }; done

hibp () {
echo "Enter password to check (only sha1 will be sent to hibp):"
stty -echo
read line
stty echo

local sha1="$(printf "$line"|openssl sha1|cut -d' ' -f2-)"
local prefix="$(echo "$sha1"|sed 's/\(.....\)\(.*\)/\1/')"
local suffix="$(echo "$sha1"|sed 's/\(.....\)\(.*\)/\2/')"

foundcount=$(curl "https://api.pwnedpasswords.com/range/$prefix" 2>/dev/null | grep -i "$suffix"|cut -d: -f2|strings)

if [ -n "$foundcount" ]; then echo "Found it ${foundcount}x times, very WEAK PW, dont use it, STOP"
else echo "PW not found in hibp, a GOOD starting sign, but way not enough"
fi
sleep 2
}

hibp
$
$
$ sh hibp.sh
Enter password to check (only sha1 will be sent to hibp):
Found it 78773x times, very WEAK PW, dont use it, STOP
$

( Hiena v | 2019. 02. 07., cs – 21:49 )

Miért van folyamatosan olyan érzésem, hogy a HIBP valójában csak egy email cím validáló és jelszó gyűjtögető project?
Darkneten összekaparnak egy csomó adatbázist, majd a sok befosatott userrel ellenőriztetik a valóban élő emailcímeket.
Arról nem beszélve, hogy a jelszóellenőrzéssel, rögtön lehet is csinálni egy új adatbázist.
--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

+1

Rendszeresen látok ilyent, ügyfél hív, hogy csinált egy CV gyűjtő email címet, és már van 5 spam, pedig még ki se rakta a hirdetést. De nekem is volt, hogy gmail címet regisztráltam speciális célra, kifelé ismeretlen, sose ment ki róla email, fejből nem is tudom a címet, de van rajta havonta x spam.

Az IT sec. nem így működik. Ha ellenőriztetsz n+1 email címet, majd ugyanabból a böngészőből ellenőriztetsz n+1 jelszót és az bekerül egy adatbázisba, annak későbbiek folyamán értéke lesz, mert háttérinfóként használhatod.
Ha tudod, hogx X.Y. egy adott mailt használ regisztrációhoz, és K,L,M,N,O jelszavakat teszteszlte, akkor csak 5 hasht kell generálnod, és kerestetned egy kiszivárgott adatbázisban amiben szerepel X.Y. email címe. Hasonlóképp, ha ismersz mondjuk 10 ember, 10 jelszókombinációját és van egy ismeretlen megfelelően sózott és borsozott hashed, akkor jóval kevesebb erőforrásra van szükséged, hogy kitaláld az alkalmazott elkódolás módját.
--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

Vagy en nem ertem vagy te :)
Ha beirom az emailcimem modjuk user(@)host.com majd ugyanabbol a bongeszobol lekerem azokat a jelszo hash-eket amelyeknek az elso ot betuje mondjuk abcde. Ha megtalalom az en jelszom hash-et a listaban amit kapok akkor nyilvan valtoztatom a jelszot (hanem miert kertem volna ellenorzest). Ha nem talata meg akkor nem valtoztatok.
Most szerintem ebbol azt tudjak meg, hogy a usre(@)host.com email-hez tarozo jelszo hash abcde -vel kezdodik/kezdodott. Ez meg csak hash es annak is csak az elso ot karaktere. Szerintem innen nagyon messze meg a jelszo.

Ha jól értettem meg a fickó (Troyhunt) tavalyi blog posztját, a beküldött jelszavak-nak "csak" a hash-ét kapja meg a database search szkriptje, nem a ténylegesen begépelt cleartext-et. Azt a hash-t is egy furmányos feldaraboló algoritmussal tördelik, amiről azt állítja a társszerzővel, hogy nem tudják belőle kinyerni a teljes hash-t, csak az egyik "felét". Tehát még azt se tudják pontosan visszanézni, hogy mire is kerestek a userek a náluk levő hash-listában. Jó persze, messziről jött ember azt mond amit akar. De ha azt nézzük, hogy százmillió++ username+pwdhash párokat kap hetente, amik nagy része azért valós és éles, nem nagyon látom miért kéne még neki is phishingelnie h. újabb párszázezres mintához jusson.
Aztán persze lehet h. egy világméretű átbaszás az egész a színfalak mögött. Az a baj az üldözési mániával, h. attól mert abban szenvedsz, még nem biztos hogy nem üldöznek ténylegesen.
--