Bezpieczeństwo haseł przy użyciu soli Opcje

[nexis]

Zwykle, dla bezpieczeństwa, trzymamy w bazie danych skrót hasła, utworzony za pomocą md5() bądź sha1(). Z myślą o tęczowych tablicach dopisujemy zwykle dodatkowo tzw. sól, która jest trzymana poza bazą danych, zwykle na serwerze.

Chciałbym jednak zwiększyć bezpieczeństwo również po stronie użytkownika i zastosować mechanizm znany z banków internetowych, czyli odpytywanie użytkownika o wybrane znaki hasła. Aby zastosować taki mechanizm jestem jednak zmuszony zapamiętać każdy znak hasła osobno. Powiedzmy, że w tym celu narzucę maksymalną długość hasła na 16 znaków i stworzę w tabeli bazy danych 16 dodatkowych pól (po 1 dla każdego znaku). Jak ma się jednak w/w sposób do tej sytuacji? Sam skrót to praktycznie żadne zabezpieczenie. Zastosowanie soli już bardziej, ale jest to wciąż bardzo słaby mechanizm. Co zrobić?

[thek]

Wersja skrócona:
Problem: Algorytm się minimalnie zmienia. Pociąga to za sobą konieczność zmiany wszystkich hashy wszystkim użytkownikom bo inaczej każda autoryzacja za pomocą podania litery na pozycji X wywali błąd. Jak to zrealizujesz nie posiadając hasła w postaci, na podstawie której wygenerujesz nowe hashe dla każdej litery z osobna? Bo z hasha całego hasła takich danych nie uzyskasz w żaden sposób. Konieczne więc jest uniezależnienie się od znajomości tego hasła w postaci jawnej.
Taką zmianą mogło by być dodanie tokena losowego ważnego X godzin/dni. Po upłynięciu czasu konieczne jest ponowne generowanie hashy. Jak pobierzesz hasło usera i litery w nim by wygenerować nowe skróty? Odkodujesz z bazy hash hasła? (IMG:style_emoticons/default/winksmiley.jpg)
Ja dałem propozycję zastosowania kodu pośredniego, który jest hashem każdego ze znaków w haśle. I to on byłby bazą dla obliczeń by nie sięgać do jawnej postaci.
Założenie hasła (aktualizacja hasła) -> Tworzymy hashe liter hasła metodą do tej pory nie złamaną (przykładowo sha-2) -> reszta algorytmu z solami itp., itd
Gdy następuje zmiana tokena, algorytmu czy czegokolwiek używamy już nie liter hasła ale tych hashy, dzięki czemu nie musimy znać jawnej postaci.
Weryfikacja polega na tym, że tą samą drogą traktujemy podany przez usera w formularzu znak hasła i porównujemy z wyliczonym i gdzieś przechowywanym hashem dla litery na danej pozycji.

Wniosek wysunąłem więc taki, że ta zabawa jest bezsensowna z prostej przyczyny: porównywać możemy na etapie już pierwszego hasha (ten od sha-2) i reszta to tylko sztuka dla sztuki. Zabawa w algorytm jaki my proponujemy ma bowiem tylko sens gdy hasło w bazie jest jawnie, gdyż inaczej nawet tych hashy nie mamy jak wygenerować (IMG:style_emoticons/default/biggrin.gif) Bo skąd pobierzesz informację o tym jaka litera jest na jakiej pozycji do utworzenia hasha porównawczego?
Tylko po co w takim razie jeszcze dodatkowe algorytmy i tworzenie skrótów skoro hasło i tak mamy jawnie?
Dochodzimy więc do absurdu, w którym zwiększanie bezpieczeństwa, obniża je lub tworzy zupełnie zbędny kod.

Dlatego właśnie podstawowe pytanie dla Ciebie jako mojego partnera w dyskusji: Jak przewidujesz, i czy w ogóle masz zamiar, rozwiązać problem ewentualnej drobnej zmiany w algorytmie gdy masz już w bazie przynajmniej kilkuset userów? Jak w takiej sytuacji wygenerujesz im nowe hashe w sposób transparentny, bez zmuszania do ponownej zmiany hasła lub łamania ich haseł? Czy ustawisz w bazie flagę taką, że po zalogowaniu pierwszym, już po zmianie algorytmu, generuje im nowe hashe już zgodne z nowym algorytmem?