Preorder drugiego tomu książki sekuraka: Wprowadzenie do bezpieczeństwa IT. -15% z kodem: sekurak-book
320 milionów haseł z realnych włamań – do sprawdzenia on-line lub pobrania
Mamy nową funkcję w znanym serwisie Troy Hunta – haveibeenpwned.
Tym razem Troy udostępnia nam możliwość sprawdzenia online czy dane hasło znajduje się na liście tych skompromitowanych (obecnie mamy w bazie około 320 milionów unikalnych rekordów).
Czy jest to rozsądne? Mamy mieszane uczucia (wymaga to podania hasła do sprawdzenia, które w ogólnym przypadku jeśli nie jest skompromitowane – to może właśnie takim się stać).
Z drugiej strony Troy tłumaczy, dlaczego zdecydował się na taki krok i pokazuje też źródła haseł do swojej bazy (m.in. Anti Public oraz Exploit.in).
Hasła są też możliwe do pobrania tutaj (ok 5,5 GB skompresowany plik tekstowy). Ale uwaga – hasła są zahashowane SHA-1 (choć oryginalnie są one w znakomitej większości – jeśli nie w 100% – dostępne w plaintext). Chroni to ich oryginalną treść, ale umożliwia łatwe zbudowanie funkcji weryfikującej czy hasło, które chce nam ustawić użytkownik w aplikacji nie wyciekło wcześniej.
Takie sprawdzenie jest swoją drogą zalecane przez niedawno wydaną rekomendację NIST: Digital Identity Guidelines: Authentication and Lifecycle Management.
–ms
Hoho, Michale brawa za referencje do NIST SP 800-63. Mam spore nadzieje na rozpowszechnienie i wdrozenie tych wytycznych (calej serii).
tak, to całkiem świeża seria ich rekomendacji – jak trochę okrzepnie to może dałbyś zrobić jakieś podsumowanie na sekuraka tego: https://www.nist.gov/itl/tig/special-publication-800-63-3 ?
na wesoło – podsumowanie w opcji czytania dokumentu w Google Chrome i użycie funkcji Tłumacz:
„A.5 Summary
Wymagania dotyczące długości i złożoności poza zalecanymi tutaj znacząco zwiększają trudności z zapamiętanymi tajemnicami i zwiększają frustrację użytkowników. W rezultacie użytkownicy często pracują nad tymi ograniczeniami w sposób, który jest odwrotny. Ponadto inne złagodzenia, takie jak czarne listy, bezpieczne przechowywanie haszysz, a ograniczanie stawek jest skuteczniejsze w zapobieganiu atakom brutalnych sił. Dlatego też nie nakłada się żadnych dodatkowych wymogów dotyczących złożoności.”….
Compromised to nie koniecznie skompromitowane.
’Wyciekłe w formie otwartego tekstu’ – to jakoś tak niezgrabnie ;-)
Ujawnione? Złamane? Upublicznione? Poznane? Wykradzione?
Dobre propozycje. Choć pewnie do każdej też można się przyczepić. Złamane? (jak jak przechowywali w plaintext to nawet łamania nie trzeba było)
Osobiście sądzę że Compromised to bardzo specyficzne słowo w jęz. ang. żebyśmy mieli jasność za którego znawcę czy do niego specjalistę nie uważam się. Gdyż nie mam ku temu podstaw. Jednak tłumaczenie wspomnianego wyrazu jak złamane… to chyba troszeczkę przegięcie.
Skompromitowany może być człowiek nie dane tak przynajmniej sądzę. Te dane jak Kolega powyżej sugerował wyciekły czy zostały wykradzione ale to takie tłumaczenie na nasz język. Może po prostu zostańmy przy wersji w języku oryginalnym a rozummy po prostu o co chodzi. Na nasze – dane wyciekły i zostały upublicznione i to pod kątem bezpieczeństwa jest niedobrze przynajmniej dla ich ówczesnego posiadacza czy tego kto je z/gromadził. Czego chyba na stronie takiej jak Sekurak.pl nikomu tłumaczyć nie trzeba ;-) Bowiem niekontrolowany wyciek informacji czy też ich kradzież to żadna radość ani chwała.
uczciwsze byłoby umożliwienie sprawdzenie hasha zamiast hasła
dla kogo?
Ale to jest możliwe…
Przykładowo dla „password” należy obliczyć sha1, a następnie odpytać:
https://haveibeenpwned.com/api/v2/pwnedpassword/5baa61e4c9b93f3f0682250b6cf8331b7ee68fd8?originalPasswordIsAHash=true
API zwróci 200 jeśli hasło „wyciekło” lub 404 jeśli nie.