@def Ej właśnie! O tym nie pomyślałem xD Jak to działa? Akurat kto jak kto banki to raczej plain texta nie trzymają

https://zaufanatrzeciastrona.pl/post/kryptografia-hasel-maskowanych-czyli-magia-matematyki/

@tmg To prawda. To znaczy ja zakładam że w 2023 roku to już każdy używa nowego bcrypta nawet jak o tym nie wie, bo mu framework sam go wrzuca ¯\_(ツ)_/¯ Ogólnie ja mam takie poczucie że jak pierwszy raz ustawiam gdzieś hasło, to ono automatycznie przestaje być "moje" bo przecież nie wiem co sie z nim dalej dzieje. Dlatego (i z wielu innych powodów) menadżery haseł 100% RiGCz

@tmg wg tego co napisał OP to nowe hasło jest porównywane z obecnym hashem. Nie widzę tu trzymania starych haseł, jak walidacja przejdzie to obecne zostanie nadpisane

@lokurva No to zależy od implementacji, ale widziałem wersje że nowe hasło nie może być podobne do żadnego z poprzednich. A nawet jak nie w mechanizmie podobieństwa, to i tak trzymają hashe starych haseł żebyś nie ustawił drugi raz tego co już miałeś, to częsta praktyka

Trzymają hasła w plain, miszcze, albo mają jakieś prościutkie szyfrowanie.

@lokurva wręcz przeciwnie, muszą mieć hashe starych haseł by wykrywać ich podobieństwo z nowym, no chyba że trzymają hasła w plaintext

@UncleFester @tmg Właściwie to cały mój wpis jest dokładnie o tym że nie muszą tego robić w plain text xD

@Barcol @tmg

Raczej muszą.

Porównanie hashy nie powinno dawać informacji o podobieństwie haseł.

Przy poprawnie dobranym algorytmem hashującym zmiana nawet 1 znaku w haśle powinna dawać diametralnie inny ciąg wynikowy, co uniemożliwia porównanie.

@UncleFester Czy Ty czytałeś mój wpis (ten tutaj, jak przescrollujesz wyżej) w którym dokładnie i krok po kroku opisuje jak jest to osiągane przy pełnoprawnie zahashowanych hasłach? Bo ciężko mi uwierzyć że ktoś mógłby komentować wpis bez czytania go, ale tak to właśnie wygląda.

Jeżeli tekst jest za długo to chętnie go skrócę:

1. Masz stare hasło (np. "Dupa") - oni go nie znają, ale znają jego hash, powiedzmy że wynosi on 2137
   

2. Musisz je zmienić, więc wybierasz nowe hasło (np "Dupa1") - jego hash jest zupełnie inny, wynosi 8888
   

3. Algorytm bierze Twoje nowe hasło i przepuszcza przez najbardziej oczywiste zmiany i permutacje. Wiesz, usuwa znak, dekrementuje cyfre, odwraca stringa, i tak dalej.
   

4. Dostaje szereg nowych stringów zbudowanych z Twojego hasła, np "Dupa0", "dupa1", "Dupa" , czy może nawet od tyłu "1apuD"
   

5. Bierze te hasła i hashuje. Dostaje 1111, 6666, 2137, 9999.
   

6. Bingo! Jeden hash sie zgadza z tym z bazy! Znaczy to, że nowe hasło jest podobne.

@Barcol 

OK, drugi wpis dotarł.

Ciekawy sposób, taki mały autobrutforce na początek i to faktycznie ma prawo zadziałać ... ale.

Takie podejście zakłada, że algorytm liczący hashe permutacji zna plaintext hasła, czyli albo działa po stronie klienta (bezsens), albo po stronie serwera, ergo hasło plain jest przesyłane via internet - niekoniecznie bezpieczne.

Z tego co wiem, w nowszych systemach, hasło między klientem z serwerem jest przesyłane już w formie którejś z popularnych funkcji skrótu.

W takim przypadku algorytm sprawdzający nie zadziała, ponieważ na wejściu dostaje, hash a nie plain.

Może zadziałać natomiast przesyłanie hasła zaszyfrowanego kluczem publicznym.

@UncleFester Hmmm, ale przecież tak właśnie działa HTTPS, prawda? Szyfruje cały ruch przy użyciu mądrych mechanizmów SSL.

Szczerze mówiąc zawsze spotykałem się z plain textowym hasłem w trakcie obrabiania go na serwerze. Po prostu usuwamy go z logów (lub framework robi to domyślnie) ale ono tam jest. Nie słyszałem nigdy o hashowaniu jeszcze po stronie klienta. Zresztą samo określenie "hashowanie" jest trochę na wyrost, bo sugeruje że tam jakiś goły md5 leci, podczas gdy faktyczne funkcje generujące hashe haseł są bardziej skomplikowane. Taki bcrypt trzyma w zaszyfrowanym polu wersję algorytmu hashującego, koszt, sól, i w końcu faktyczny hash. To wszystko musiałoby być wysłane do klienta, i to przed uwierzytelnieniem go! Brzmi to dość niewiarygodnie, ale nie wyszuwam byś próbował mnie oszukać.

@Barcol 

Pomimo zabezpieczenia SSL/TLS, przesyłanie plaina, to zawsze zły pomysł.

Cały myk w tym, żeby już po stronie klienckiej zastosować nawet goły MDx lub SHAxxx i ten hash przesyłać do serwera.

Tam, to już można stosować wszelkie cuda wianki kryptograficzne i na koniec zapisać w bazie .

Tak to działa w niektórych routerach i IoT.

@UncleFester HMMM, to ciekawe. Doczytam w wolnym czasie

• @Macer Mnie rozwala jak mam dobre hasło wygenerowane przez menadżer, a tu nagle dostaje komunikat "nieprawidłowe hasło" i szukam co im sie nie podoba a tam tak idiotyczne frazy jak "Żaden znak nie może być powtórzony więcej niż 2 razy" (co XD) albo "hasło nie może zaiwerać w sobie podobieństwa do loginu" - no i co to niby kurwa znaczy? W okcie przepuściło mnie dopiero hasło które nie miało żadnej literki z mojego loginu. To jest czysty debilizm

@Barcol to chyba jest celowo wymyslane zeby stworzyc podstawy pod wprowadzenie tego digital ID. ze to niby takie wygodne bo nie trzeba hasel wymyslac. ale i tak nie trzeba, bo nikt normalny nie lamie hasel pojedynczych uzytkownikow, jesli juz to kradnie bazy albo stosuje phishing.

Niedługo i pole do wpisywania hasła będzie tak wygldac: https://neal.fun/password-game/

:D

@redve Ja mam w banku max 16 ಠ_ಠ To znaczy rozumiem że limit musi być, ale kurde 16 znaków w tych czasach traktowane jako MAKSIMUM to tak średnio poważnie, o 12 nie mówiąc :v

Limit masz jak jest hasło maskowane, ale jak je wyłączysz to powinno dać się dłuższe, chyba, z zapomnieli i mają błąd xd.