Kilka znaków zamiast całego hasła - jak to działa? Opcje

[NetBeans]

Cześć.
Pewnie większość z Was kojarzy metody logowania na stronach banków. Jest to wykonane w ten sposób, że musimy podać tylko kilka znaków naszego hasła (reszta jest zablokowana, tak jakby już były wpisane). Zastanawiam się w jaki sposób to działa. Zakładam, że hasła są hashowane, więc w jaki sposób porónywane są ciągi, skoro są niekompletne. Nie jest chyba możliwe, że system wie jakie znaki hasła mamy pod daną cyferką (widoczne na obrazku) i uzupełnia ciąg do porównania z hashem. Do tego "szare" pola są generowane losowo. Interesuje mnie zasada działania, nie proszę o żaden gotowy kod etc.
Pozdrawiam. (IMG:style_emoticons/default/smile.gif)

Wspomniany obrazek:
(IMG:http://i.imgur.com/Dbb16Z6.png)

[sowiq]

Koledzy, wtrącę się i ja, bo kiedyś myślałem o takim rozwiązaniu. Wybaczcie, ale trochę kupy nie trzyma się Wasze rozumowanie. Najpierw napiszę dlaczego, a później opiszę moje rozumowanie.

1. Hashowanie pojedynczych znaków

1.a. Wspólna sól trzymana w kodzie.
Przypadek trywialny, bo sami sobie robimy szyfr słownikowy. Każdemu znakowi będzie w bazie odpowiadał jeden, taki sam ciąg. Mało tego - po znalezieniu soli dla jednego znaku znamy ją globalnie. Czas złamania - kilka minut na znak w zależności od długości soli. Ewentualnie można polecieć algorytmem statystycznym, jak to robili już w czasie II wojny światowej (IMG:style_emoticons/default/wink.gif)

1.b. Każdy znak solony inną solą.
W tym przypadku nie ma innej opcji jak trzymanie każdej soli w bazie. Przypadek jeszcze łatwiejszy niż poprzedni, bo niewiadomą jest już tylko szukany znak. Ile milisekund potrzebowałby w miarę szybki komputer na wygenerowanie n hashy (n - liczba dostępnych znaków)?

1.c. Sól generowana dynamicznie w kodzie dla każdego usera.
Rozwiązanie najlepsze z tych 3. Ale domyślam się, że po złamaniu pierwszych 1000 haseł bez większego problemu można znaleźć klucz, który określa w jaki sposób generowana jest ta sól. Bo oczywiście nie może to być losowanie, bo za każdym razem dla danego usera musi być wygenerowana ta sama sól.


2. Moje rozumowanie

2.a Generowanie n kombinacji
Jak dla mnie najbezpieczniejszym rozwiązaniem byłoby wygenerowanie n kombinacji dla danego hasła. Załóżmy dla uproszczenia, że hasło składa się z 5 znaków, a user musi wpisać co najmniej 3. Daje to 26 kombinacji (poprawcie mnie jeśli się mylę). Zapisujemy każdą z nich w bazie jako posolony hash. Przy każdym rekordzie zapisujemy które znaki są w nim zawarte i zapisujemy też sól. Przed logowaniem system wybiera z bazy opcję hasła (które znaki trzeba wpisać), a później hashuje hasło i porównuje z informacją w bazie, podobnie jak przy "normalnym" logowaniu.
Wady:
- przy dłuższych hasłach hashy będzie dosyć sporo
- przy algorytmach lepszych niż md5/sha1, czas generowania kombinacji może być dosyć długi (kilka/naście sekund?)
- trochę skomplikowana implementacja generowania kombinacji
Zalety:
- kombinacje generowane tylko podczas zakładania konta i zmiany hasła
- IMO całkiem bezpieczne rozwiązanie

Ten post edytował sowiq 17.07.2013, 08:29:24

[gitbejbe]

@sowiq

tak przeczytałem, Twój post również. Stwierdzenie w pkt.1b, że losowy token dla każdego hasła jest jeszcze łatwiejszy do złamania od stałego, sparaliżowało mi chęć odpisania na to do końca dnia. Co do Twojego pomysłu w pkt 2a, nie wiem, nie rozumiem, czytam któryś raz i jedyne czego jestem pewien to to, że sam wymieniłeś więcej wad niż zalet takiego rozwiązania ; )

Jak dla mnie, najprościej i najbezpieczniej jest dla każdego znaku w haśle zrobić losowy token, przemieszać go ze stałym tokenem (+ jakieś inne dowolne stałe, np data założenia konta - ba,można zrobic i tak, że dla znaku 1 bedzie to data rejestracji, dla 2 będzie to login, dla 3 jeszcze coś innego). dodatkowo wszystkie te zaszyfrowane znaki połączyć jako całość i znowu przemieszać. Przy logowaniu - 3 nieudane próby i captcha po 10 próbach ban. Wątpie aby autor wątku pisał system bankowy. Jeśli chce mieć niespotykane logowanie to fajnie, ale nie popadajmy w paranoje. To w zupełności wystarczy

[sowiq]

@gitbejbe,
Na początku zaznaczę dla pewności, że pisałem o zapisywaniu każdej litery hasła oddzielnie, jako osobny hash.

Stwierdzenie w pkt.1b, że losowy token dla każdego hasła jest jeszcze łatwiejszy do złamania od stałego, sparaliżowało mi chęć odpisania na to do końca dnia

Bardzo chętnie dowiem się dlaczego. Jak dla mnie, jeśli token jest losowy i zapisany w bazie (nie generowany z niczego - ten przypadek opisałem w punkcie 1.c), to masz wręcz trywialną sytuację. Do sprawdzenia wszystkie jednoznakowe możliwości dla jednego hasha. Na standardowej klawiaturze możesz wprowadzić 98 znaków, więc na złamanie każdego hasha potrzeba max 98 prób. IMO średnia będzie oscylowała w okolicach 50.
Jeśli coś opisałem nielogicznie/niejasno to bardzo chętnie wyjaśnię Ci mój punk widzenia.

Co do Twojego pomysłu w pkt 2a, nie wiem, nie rozumiem, czytam któryś raz i jedyne czego jestem pewien to to, że sam wymieniłeś więcej wad niż zalet takiego rozwiązania ; )

Opisałem to trochę dokładniej tutaj: http://forum.php.pl/index.php?s=&showt...t&p=1056210 Sorry, źle przeczytałem.
Jeśli bierzesz pod uwagę liczbę wad i zalet, a nie zwracasz uwagi jakie one są, to sorry. Wady to skomplikowana implementacja i czas generowania, a zalety to (przynajmniej moim zdaniem) bezpieczeństwo. Jeśli komuś bardzo zależy na bezpieczeństwie, to ta zaleta przebija wszystkie wady. Czaisz?

Wytłumaczę to na przykładzie.
Załóżmy, że masz 5-znakowe hasło: abcde
Załóżmy, że musisz wpisać co najmniej 3 znaki hasła przy logowaniu. Wobec tego będą takie kombinacje ciągu przychodzącego od usera:

Kod

1. abcde
2. _bcde
3. a_cde
4. ab_de
5. abc_e
6. abcd_
7. __cde
8. _b_de
8. _bc_e
...
26. abc__

Dla każdej z takich kombinacji tworzysz w bazie hash (oczywiście dla 20-znakowego hasła, z którego musisz wpisać co najmniej 10 znaków, kombinacje nie będą tak trywialne, ale też będzie ich więcej). Dzięki temu złamać pojedynczy hash nie będzie tak łatwo (duża ilość znaków szukanego ciągu), każdy hash będzie miał swoją losową sól zapisaną w bazie. O wadach i zaletach pisałem już wcześniej.

Jak dla mnie, najprościej i najbezpieczniej jest dla każdego znaku w haśle zrobić losowy token, przemieszać go ze stałym tokenem (+ jakieś inne dowolne stałe, np data założenia konta - ba,można zrobic i tak, że dla znaku 1 bedzie to data rejestracji, dla 2 będzie to login, dla 3 jeszcze coś innego)

To jest metoda, którą opisałem w punkcie 1.c.

dodatkowo wszystkie te zaszyfrowane znaki połączyć jako całość i znowu przemieszać.

Tutaj rozwaliłeś mnie po raz pierwszy. Pomieszaj, pomieszaj i poproś swój skrypt logujący, żeby później to magicznie odmieszał i sprawdził poprawność wpisanych literek. Tak jak pisałem już wcześniej - zaciemnianie != poprawa bezpieczeństwa.

Wątpie aby autor wątku pisał system bankowy. Jeśli chce mieć niespotykane logowanie to fajnie, ale nie popadajmy w paranoje. To w zupełności wystarczy

Ale to nie ma nic do rzeczy. Dyskutujemy tutaj na temat jak najbezpieczniej rozwiązać problem. Może ktoś z nas w przyszłości będzie robił podobne logowanie, gdzie nacisk będzie położony na bezpieczeństwo i będzie musiał zmierzyć się z tym?

Przy logowaniu - 3 nieudane próby i captcha po 10 próbach ban.

Najlepsze zostawiłem sobie na koniec. Wyjaśnij mi, proszę, co ma captcha i ban bo łamania haseł w wykradzionej bazie danych, a stawiam browara.

Ten post edytował sowiq 18.07.2013, 08:34:33