Przechowywanie haseł - wymóg stosowania różniących się haseł

0

Dostaliśmy specyfikację dot. haseł w nowej aplikacji którą tworzymy i są wśród nich m.in.

  • nie może być takie samo jak 6 ostatnio użytych dla danego użytkownika
  • nie może zawierać frazy, która wystąpiła w tych ostatnich 6 użytych hasłach

O ile pierwsza kropka jest prosta bo jeśli będziemy przechowywać hashe to wystarczy je porównać.
Mamy problem z drugą kropką. Czy to w ogóle jest wykonalne?
Jedyne co udało nam się wymyślić to przechowywać hashe wszystkich fraz i sprawdzać czy już nie wystąpiła, ale nie jesteśmy do tej metody przekonani.
Ma ktoś może doświadczenie jak to jest realizowane np. w systemach bankowych?

PS: Fraza to podciąg hasła o jeszcze nie ustalonej długości (osobiście stawiam na podciąg długości 3)

0

Przy zmianie hasła można stare zapamiętać, a nowego nadal hash+salt.

0

Miałem na myśli rozwiązanie drugiego problemu.

Jak ktoś zmienia hasło, to podaje stare w celu weryfikacji, stare jest sprawdzane czy nie zawiera fraz i jak nowe jest zatwierdzone, to stare ląduje w bazie starych nie jako hash.

Z jednego strony to jest bezpieczne, bo te hasło nie jest już wykorzystywane.
A z drugiej kto wie, czy jak wyciekną hasła to nie będzie afery, źe to te prawdziwe, albo ktoś miał akurat wszędzie takie samo xd.
A do góry nogami z tej strony to też jest niebezpieczne, bo wtedy atakujący wie, że jak się dorwie do haseł, to będzie wiedział jakie frazy nie występują w nowych hasłach i odsiew słabych haseł zwiększony.

0

Tylko że nadal musimy sprawdzać frazy w 6 poprzednich hasłach.
Chociaż zdania o niebezpieczeństwach mnie przekonują o tym że to zły pomysł.

1

Nie no bez żartów, absolutnie zapomnijcie o trzymaniu starych haseł plaintextem :D Raz bo wielu ludzi tylko "mutuje" sobie hasła jak musi zmienić, a dwa bo pewnie gdzieś indziej ma podobne. To by była masakra jakaś.
Pomysł że nowe hasło nie może zawierać jakiejś 3 znakowej frazy ze starego hasła jest też totalnie bez sensu. Jeszcze rozumiem jakby jakaś odległość edycyjna miała być większa niż 3, ale to o czym piszecie to idiotyzm, szczególnie dla długich haseł. Powodzenia podczas próby zmiany hasła, szczególnie tej 6 :D
Nie wiem kto wam te guidliny wymyślił, ale powinien iść się leczyć. Jeszcze powiedz że hasła do zmiany co miesiąc na przykład :D

0

Nie wiem co to za system, ale są znacznie lesze metody na zwiększanie bezpieczeństwa bez wątpliwej sensowności "nie może zawierać frazy, która wystąpiła w tych ostatnich 6 użytych hasłach". Choćby Multi-factor authentication. Może warto renegocjować specyfikacje?

0

Nie chciałbym korzystać z takiego systemu. Jak ustawię sobię hasło alamakota2017, a za jakiś czas zmienią na k23j5k25lkh_ASDOIHASODmakod-99-u235235kndf to też będzie źle? No paranoja :P
Apple stosuje podobny manewr, ile razy mnie juz ..rwica strzelała przez to.... ehhh

0

@Shalom:
absolutnie nie chcemy żadnego hasła plaintextem trzymać, jakieś tam podstawy bezpieczeństwa mamy :)

@Changs
Od razu nam się ta specyfikacja nie spodobała, ale woleliśmy zapytać. A system jest dla instytucji współpracującej z bankami i to banki wymuszają na nas takie reguły.

Reasumując, propozycja Krzywego Kreta wygląda IMO dobrze.
Bedziemy przechowywać hashe 6 ostatnich haseł i nowe hasło będzie musiało być inne niż 6 ostatnich. A te badanie podciągów będziemy realizować tylko na ostatnim haśle. Brzmi dobrze.

6

A jak by te poprzednie hasła zaszyfrować/zakodować, używając aktualnego jako klucza? Wtedy jawnie nie będą, a przy zmianie hasła bez problemu się je uzyska celem porównania, podmiany najstarszego na klucz, i zabezpieczenia z powrotem nowym hasłem.

0
sig napisał(a):

Sprytne, takie proste rozwiązanie a najlepsze, chyba nie ma luk.

4

zawsze można kazać userowi podać wszystkie 6 podczas zmiany hasła :D :D :D

0

@sig jest to jakieś rozwiązanie, ale też nie jest idealne, bo jeśli nie zrobisz tego odpowiednio to będziesz wyciekał informację o długości hasła.

0

oprócz hasha całego hasła musisz przechowywać hashe poszczególnych cześci hasła. Np użytkownik wprowadza hasło AB12345678, a niepowtarzalna fraza to 5 znaków robisz hashe AB123, B1234, 12345, 23456, 345678. To samo robisz dla nowego hasła i porównujesz ze starymi. To tak na szybko co mi przychodzi do głowy.

0
hauleth napisał(a):

@sig jest to jakieś rozwiązanie, ale też nie jest idealne, bo jeśli nie zrobisz tego odpowiednio to będziesz wyciekał informację o długości hasła.

Owszem, ale jeśli klient się uprze, to jedyna sensowna propozycja czyli haszowanie podciągów będzie miała "hasła" o stałej, z góry znanej długości co sprawi że będzie warto zrobić tęczowe tablice i łamać te hashe celem złożenia z nich poprzednich haseł.

0

"będziesz wyciekał informację o długości hasła." - słuszna uwaga, można to spróbować obejść wpisując zawsze np 50 podciągów. Pierwszych X byłyby to rzeczywiste podciągi, a 50-x generowane losowo. Oprócz hashy hasła i podciągów musiałaby zostać zapisana zaszyfrowana jakimś stałym kluczem informacja o liczbie X.

2

Wracając do pytania: tak, musiałbyś mieć hashe dla podciągów.

Przy czym to też nie ma sensu, bo równie dobrze wtedy można trzymać całe hasło plaintextem. Jeśli ktoś ma 13znakowe hasło, i mamy hashe z 10 trzyznakowych podciągów to zagadka, jak trudno będzie zbrutować wszystko? ;] Hint: wystarczy zgadnąć chociaż jeden hash, a reszta pójdzie jak z płatka. Hash trzyznakowego podciągu.

Jeśli podciągi mają być krótsze niż 7 znaków, to naprawdę, w tym przypadku cokolwiek poza trzymaniem plaintextu będzie w najlepszym wypadku security theatre (i to zakładając mocną funkcję hashującą, np. jakiś scrypt). Oczywiście, możecie trzymać hashe, żeby klient myślał że jest bezpieczniej, ale nie będzie.

A jak by te poprzednie hasła zaszyfrować/zakodować, używając aktualnego jako klucza? Wtedy jawnie nie będą, a przy zmianie hasła bez problemu się je uzyska celem porównania, podmiany najstarszego na klucz, i zabezpieczenia z powrotem nowym hasłem.

No nie jest idealne, ale faktycznie najlepsze z podanych tutaj. Wtedy faktycznie (jeśli dobrze się zrobi szyfrowanie), najwyżej będzie można poznac wszystkie hasła użytkownika, łamiąc jego obecne.

oprócz hasha całego hasła musisz przechowywać hashe poszczególnych cześci hasła. Np użytkownik wprowadza hasło AB12345678, a niepowtarzalna fraza to 5 znaków robisz hashe AB123, B1234, 12345, 23456, 345678. To samo robisz dla nowego hasła i porównujesz ze starymi. To tak na szybko co mi przychodzi do głowy.

Nie, to dramatycznie zły sposób. Patrz wyżej.

Owszem, ale jeśli klient się uprze, to jedyna sensowna propozycja czyli haszowanie podciągów będzie miała "hasła" o stałej, z góry znanej długości co sprawi że będzie warto zrobić tęczowe tablice i łamać te hashe celem złożenia z nich poprzednich haseł.

Czemu wszyscy często mówią o tęczowych tablicach, nikt od dawna nie używa tęczowych tablic :P.

@sig jest to jakieś rozwiązanie, ale też nie jest idealne, bo jeśli nie zrobisz tego odpowiednio to będziesz wyciekał informację o długości hasła.

Niby tak, ale 1) wyciek długości hasła to w sumie żaden problem 2) szyfry blokowe i tak zaokrąglą długość danych do 16.

0

teraz po spokojnym przeanalizowaniu tematu zgadzam się z argumentacją msm, że pomysł z podciągami wręcz osłabia bezpieczeństwo hasła (o tak bez zastanowienia napisałem co pierwsze przyszyło mi do głowy). Podciąg musiałby mieć z 8 znaków aby zachować bezpieczeństo więc traci to zupełnie sens.

0

Jeszcze raz zastanowiłem się nad tymi cześciowymi hashami i przyszedł mi do głowy pomysł, który mógłby w jakimś stopniu obronić tą koncepcję. Gdyby hash'e cześciowe przechowywać tylko dla starych haseł. Hash'e cześciowe dla aktualnego hasła byłby wyliczne dopiero w momencie zmiany hasła, kiedy użytkownik wpisuje stare hasło (aktualnie obowiązujące) i podaje nowe. Hash'a częściowe aktualnie obowiązującego hasła byłby tylko w pamięci operacyjnej. jeżeli wszystko jest OK i system zatwierdziłby zmianę hasła to wtedy zostałyby one zapisane do tabeli. Słabą stroną tej koncepcji jest to, że łatwo można złamać stare hasła i znaleźć ewentualny wzór według którego pomysłowy użytkownik zmienia hasła np. Alicja123, Barbara234, Celina345 to należy spodziewać się imienia na D...456

0

@mdolata: przekonaliście klienta do zaniechania tego głupiego pomysłu, to może uda się Wam przekonać do wprowadzenia two-factor-auth? U mnie w firmie używamy kluczy yubico - bardzo wygodne i ze wsparciem dla Linuxa i Androida.

0

Wyciek zhasowanych podciągów można załatwić soleniem aktualnym hasłem. Wada taka, że przy każdej zmianie hasła trzeba by zmieniać hashe podciągów.

1 użytkowników online, w tym zalogowanych: 0, gości: 1