Jak bezpiecznie przechowywać hasło użytkownika i sól w MySQL?

Tęcza / ataki słownikowe i hasła solone-podejście heretyków

Hasła nie powinny być przechowywane w bazie danych. Nie zwijaj własnego mechanizmu uwierzytelniania - prawie na pewno się pomylisz. Użyj Kereberos dla cennych rzeczy, i dobrze, że nie mam dobrej sugestii inaczej.

Jednak to pytanie od jakiegoś czasu wbija mi się w czaszkę (zobacz edycje) i chciałbym przedstawić heretycki punkt widzenia.

Tęcza tabele są tak zwane ze względu na sposób wykorzystania mechanizmu lookup (chaining) - ale są to tylko ataki słownikowe. Miliony słów słownikowych i popularnych haseł są zaszyfrowane z góry, a następnie używane do porównywania skradzionych haseł.

To działało dobrze dla procesu haseł NT4, który używał skrótów md5 i bez soli. Ale gdy do hasła przed hashowaniem dodaje się sól, to tablica tęczowa jest bezużyteczna - zamiast szukać hasha md5 z "mypass" musi precompute "MyPass-random-string_of-letters"

Nie można odgadnąć, jakiej soli ktoś użyje, więc solenie sprawia, że rainbow tables jest generycznym rozwiązaniem, używanym wszędzie przeciwko dowolnemu rozwiązaniu serwerowemu.

Ale ...

To tylko jeden przypadek użycia-z pewnością duże zagrożenie, z pewnością jeden do obrony. Ale Sole mają problem. Musisz zachować sól na czas, gdy chcesz uwierzytelnić następnym razem, gdy użytkownik loguje się. Wysyłają swój zwykły tekst (przez ssl!), dodajesz sól i hash, współpracują z Hashem przechowywanym w bazie danych. Ale jeśli nie zachowasz soli z hasłem, nie możesz tego zrobić i errr... no login

Ale nie tylko bronimy się przed ludźmi przechodzącymi wokół stołu przeznaczonymi do łamania haseł NT4. Mamy chronić naszych użytkowników indywidualnie.

Salt dodaje do haseł ochronę dwuskładnikową - nawet z Hashem atakujący będzie potrzebował soli, aby mieć jakąkolwiek szansę na jego złamanie. Ale standardowa Rada tylko daje Precz z obroną dwuskładnikową. Prawdopodobnie jest to rozsądne, ale nie jestem przekonany.

Kryje się za tym trochę matematyki. Zwykłe Rady (udzielane również przez RSA - ftp.rsa.com/pub/pkcs/pkcs-5v2/pkcs5v2-0.pdf) buduje sól 64 bitową, przechowuje ją z zaszyfrowane hasło. W ten sposób możesz ponownie potwierdzić hasło, ponownie odświeżając je za pomocą soli i odwracając hash jest prawie niemożliwe.

NB-mogę się mylić ...

Bit "next to impossible" pochodzi z prostej matematyki.

Przyjmijmy 8-cyfrowe hasło, z 62 możliwymi znakami (litery, górne dolne i cyfry)

To 62^8 kombinacji, czyli nieco ponad 200 milionów bilionów.

Aby to brutalnie wymusić, obliczając hash bezpośrednio (czyli dokonując moich tabel tęczowych) powinienem zobaczyć kolizję po 62^8/2 i powiedzmy 100 hashów na sekundę, zajmie to około 12 milionów dni. Tak dni.

OK, więc nawet przechowywanie hasha z hasłem sprawia, że zadanie znalezienie haszyszu jest nieosiągalne.

Istnieją jednak pewne założenia w powyższym. Po pierwsze, że hasło jest losowym wyborem z zakresu 62^8. W praktyce większość haseł znacznie słabsza - tabele rainbow nie są tak naprawdę oparte na wszystkich możliwościach 62^8 - są zbudowane ze słowników i prawdziwych tabel haseł znalezionych na przestrzeni lat.

Więc przestrzeń wyszukiwania, zamiast być 62^8 jest naprawdę mniejsza. Jak mały ? Zależy od hasła "Siła".

Jest około 250.000-750.000 słów w języku angielskim (http://oxforddictionaries.com/page/93). przyjmijmy 500,000 jako prostą sprawę. Następnie weźmy wariacje, które można zastosować-dodaj cyfrę, dodaj rok, przekonwertuj samogłoski na cyfry. Daje nam to 3 możliwe nowe słowa na słowo lub 2 miliony możliwych haseł.

Wygenerowanie 2 milionów hashów przy 100 / s daje 20 000 sekund lub 5 godzin-w zasięgu dowolnego laptopa.

Więc jeśli istnieje konkretny użytkownik bycie ukierunkowanym, (root, admin, spolsky itp.), a następnie przechowywanie soli z hasłem natychmiast sprawia, że pękanie jest możliwe.

Przechowywanie soli z dala od hasła zwiększa trudność pęknięcia-nie w żaden matematyczny sposób, tylko w trudnościach z uzyskaniem soli i hasła. Można by wyobrazić sobie oddzielny serwer, który pobiera zwykły tekst, nazwę użytkownika i hash i wyszukuje sól użyta w dniu przyłączenia się użytkowników i zwraca 1/0

W skrócie, jeśli przechowujesz sól z hasłem i ktoś uzyskuje dostęp do haseł, a następnie w zależności od siły hasła, każde hasło można złamać w rozsądnym czasie. Inna sól na użytkownika chroni wszystkich innych użytkowników, ale jeśli szukasz konkretnego konta, nie ma to znaczenia. Jeśli haker szuka tylko jednego hasła, przechowywanie soli z hasłem sprawia, że crack jest wykonalny. Utrzymanie rotacyjnej soli w innym miejscu z tabeli haseł oznacza, że haker potrzebuje teraz dwóch kradzieży danych, aby złamać hasło, bo bez soli każdy atak jest skazany na tysiące lat pracy.

To wszystko jest kompromis - zmuszanie ludzi do korzystania z 15 cyfrowych haseł oznacza, że wszyscy dostają po-it notowane na ekranie, lub stają się" łatwe do zapamiętania", czyli słowa.

W tym momencie możesz równie dobrze przenieść się na Kerberos lub podobne - jeśli dane, które chronisz, są cenne, użytkownicy je zrozumieją i wybiorą. Jeśli nie, to po co się kłopotamy.

Ale i tak polecam zrobić a nie wdrożyć własny auth mechansim. Używaj Kerberos, używaj PKI, nie obracaj się. Nie mam pojęcia, jak stwierdzić, czy mój serwer po prostu zamienił PAMIĘĆ RAM trzymającą moją sól na dysk i to tylko jeden błąd, o którym mogę natychmiast pomyśleć w zwijaniu własnego uwierzytelniania.

HTH

$username = mysql_real_escape_string($username);
$password = mysql_real_escape_string($password);
$time = time();
$query = "
INSERT INTO user (name, unixcreationtime, passhash) 
VALUES ('$username', '$time', SHA2(CONCAT('$time','$password'),512) ";

Nie używaj SHA1, nie jest już bezpieczny.
Proponuję zrobić cały hash w MySQL, w ten sposób można mieć pewność, że nie ma różnicy w wyniku hash.

Wybierz użytkownika używając:

$query = "SELECT id FROM user 
          WHERE name = '$username' 
            AND passhash = SHA2(CONCAT(creationdate,'$password'),512) ";

Nie, ponieważ kiedy hasło zostanie zahaszowane, nie wygląda jak fishABC09, wygląda jak: 5f4dcc3b5aa765d61d8327deb882cf99, które jest skrótem md5.

Na przykład: wykonaj wyszukiwanie w Google dla hasha md5 "hasła", który jest: 5f4dcc3b5aa765d61d8327deb882cf99

Dużo wyników, prawda?

Teraz idę do Utwórz hash ponownie, nadal będę używać "hasło" , ale dodam sól, która jest " AHG ( * @". Domyślam się, że jedyną odpowiedzią będzie ten post i niektóre skrobaki botów, które przeczytały ten post:)

cbe57e92ffbb0086320891b9f979156d

Powinien być tylko kilka wyników, lub ten post, który jest tym postem.

Just Remember

Wiem, że to stare, ale dla każdego, komu uda się natknąć na ten post...

Co naprawdę próbujesz zrobić? Próba zrobienia tego samemu stwarza problemy. Możesz częściowo obliczyć skróty, co zmniejsza wysiłek wymagany do odgadnięcia hasła, na przykład. HMAC rozwiązuje tego rodzaju problemy.

Lepiej jest scrypt lub bcrypt. HMAC nadal często używa algorytmów hashowych, które są zaprojektowane tak, aby były szybkie i łatwe do obliczenia; istnieje nawet sprzęt implementacje wielu algorytmów haszujących. bcrypt jest kosztowny obliczeniowo, a scrypt wymaga dużej ilości pamięci. Oba utrudnia atakującemu, ale scrypt w szczególności sprawia, że naprawdę trudno jest zbudować urządzenia sprzętowe, aby złamać hasło.

Bardzo podoba mi się tutaj Wykres: https://github.com/pbhogan/scrypt#why-you-should-use-scrypt

Its a old topic but other will come here too so I will try to describe it very easy:

Jeśli zrobisz hash (hasło), otrzymasz tę samą wartość hash dla każdego hasła [hash (hasło) = hash (hasło)]. jeśli dwóch użytkowników ma to samo hasło, zobaczysz je, ponieważ wartości hash są takie same. niektóre hasła takie jak" password "lub" 12345678 "są bardzo często brane tak: ta sama hashvalue w bazie danych - > może hasło" password " lub "12345678" (atak rainbowtable).

Jeśli hash (salt+password) nie dostaniesz tego samego hash dla tych samych haseł, ponieważ hash (salt1 + password) nie jest hash(salt2+password).

Hash (x) jest tylko funkcją matematyczną, taką jak f (x) = y. jeśli umieścisz to samo x, otrzymasz to samo y. ta funkcja musi być "specjalna", aby była bezpieczna. po prostu nie używaj sha1, ponieważ nie jest już bezpieczny: d

Sól jest liczbą losową o ustalonej długości. Sól ta musi być inna dla każdego przechowywanego wpisu. Musi być zapisany jako czysty tekst obok hashowanego hasła.

From

Https://www.owasp.org/index.php/Hashing_Java#Why_add_salt_.3F

Jeśli haker uzyska dostęp do plików PHP, może po prostu dodać funkcję poczty, więc ktokolwiek się loguje, dane konta są wysyłane do hakera.

Jeśli haker ma dostęp tylko do bazy danych, nie powinien mieć tam wyraźnie napisanych haseł, więc Zaszyfruj je przed zapisaniem. Zapisz go w md5 hash, którego nie można odwrócić.

Zwykle używam salt bazując na username lub userID, który program PHP wie jak wygenerować dla każdego użytkownika wraz ze static_site_key.