Maskowane hasło Opcje

[Cliassi]

Witam, macie jakiś pomysł aby zrobić maskowane hasło ? tzn takie jak w bankach ze losowo trzeba wpisać oddzielnie znak w haśle. Pytanie teraz jak to umieścić w bazie? oddzielnie każdą literkę ?

[tehaha]

jeżeli już jesteś faktycznie pewien, że chcesz tak bardzo utrudniać życie użytkownikom i wyczerpałeś już wszystkie inne metody zabezpieczania, bo nie oszukujmy się ten sposób nie jest wygodny, to musi to być mniej więcej tak:
- haszujesz każdą literkę i zapisujesz w oddzielnej kolumnie;
- zapisujesz sobie też ile liter ma hasło i które znaki mają nigdy nie być sprawdzane, bo w bankach przeważnie nie są to losowe litery, a kilka zestawów liter, tak żeby nigdy nie dało się złożyć całego hasła przy dużej licznie prób;
- proces logowania musi być 2-etapowy, po wpisaniu loginu sprawdzasz ile ma liter hasło i w drugim etapie generujesz tą układanke z polami pustymi do wpisania;

[Cliassi]

Nie rozumiem projektu bazy. Mama tabele "users" i tam wszystkie dane usera i potem oddzielna tablica z id usera i literami z hasła ? co wtedy jeśli użytkownicy beda mieli inne dlugosci hasła ? wtedy bedzie nieparzysta ilosc kolumn ? (tak sie da?)

[tehaha]

możesz albo zrobić osobną tabelę, gdzie będzie: hasz litery, numer kolejności w haśle i info czy litera może być wzięta do losowania. Ewentualnie możesz to trzymać w jednej kolumnie tabeli user jako zserializowana tablica. Pamiętaj też, że w tego typu przypadkach nazwa użytkwonika musi być jako pole unique, bo tutaj nazwa użytkownika też jest kluczem dzięki któremu sprawdzisz ile liter ma hasło

[Riggs]

Mi do głowy przychodzi tylko osobna tabela w której będziesz przechowywał id użytkownika, nr litery w haśle (w sensie kolejność) oraz hash tej litery. Później to już prosta sprawa.

[mrWodoo]

users
user_id | user_pass_id


password
pass_id | pass_char_1 | pass_char_2 i tak do pass_char_32


przykład

users
1 | 1

password
1 | hash najlepiej bcrypt pierwszego znaku | to samo 2gi | i tak do 32

potem przy logowaniu pobierasz też hasło z `password` i wybierasz losowe litery, po stronie serwera np w sesji zapisujesz KTÓRE znaki wybrałeś np 1szy, 11ty, 12ty, 21szy, 28my itd.
i generujesz hashe znaków podanych w formularzu z hashami znaków z bazy

[Noidea]

Najpierw poczytaj nieco o hasłach maskowanych, zanim zdecydujesz się na konkretną strukturę tabel w bazie. Np pierwszy lepszy wynik z google: http://pentester.jogger.pl/2009/02/16/hasla-maskowane/ i już widzisz, że nie należy trzymać hasła plain-textem (PS.: hasowanie pojedynczych liter od plain-textu wiele się nie różni) i nie możesz przy każdym odświeżeniu strony pytać o inną maskę.
To by sugerowało konieczność utworzenia tabeli z maskami haseł i ich hashami:

Kod

+--------+--------------+--------------------+
| UserID | PasswordMask | MaskedPasswordHash |
+--------+--------------+--------------------+
|    1   |    1,3,4,7   |   7234hr32h87932   |
|    1   |    1,2,4,8   |   3498ty829r3428   |
|    1   |    2,5,6,8   |   tioj34ioh4j334   |
|    1   |    1,3,5,6   |   34gh3498ugh349   |
|    2   |   1,2,5,6,9  |   3j4g8934jg8j34   |
|    2   |   3,4,5,7,8  |   3j4g8934jg0893   |
...

+ informacja w tabelce z loginami, o którą maskę należy teraz pytać danego użytkownika (zmienia się dopiero po poprawnym zalogowaniu)
(Jeśli nigdy nie będziesz wyszukiwał: "masek zawierających trzeci znak hasła", to pole PasswordMask można uznać za atomowe, pomimo że trzymamy tam wartości oddzielone przecinkami)

Problem jest tylko taki, że wypadało by podczas rejestracji wygenerować trochę tych masek+hashy, żeby później mieć z czego wybierać i maski nie powtarzały się zbyt często. Gdy dochodzi co tego zalecenie, by hasła hashować stosunkowo powolnym algorytmem (np. 0.2 sekundy na hash), to może to być dosyć obciążające dla serwera. Z drugiej strony z tego co wiem, generowanie nowych masek przyrostowo (nowa maska po poprawnym zalogowaniu przy użyciu starej), wymaga dostępu do pełnego hasła w niezahashowanej postaci.
Tak więc jest to dobry moment, by przejść do kolejnych wyników w Google i czytać dalej.

Ja sam nie wiem jak taki typ logowania zaimplementować, żeby był bezpieczny. A jako że mieszanka szczytnych celów i braku wiedzy w dziedzinie zabezpieczeń spowodowałaby, że stworzył bym jedną, wielką, ładnie wyglądającą z wierzchu lukę bezpieczeństwa, to zdecydowałbym się raczej na standardowy sposób logowania.

Ten post edytował Noidea 23.08.2012, 12:05:48