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]

Zastanawiałem się Nexis nad algorytmem, który dawałby odpowiedź na punkt 2 i myślę, że da się zrobić jeszcze większą zamotę z solą indywidualną. Na dodatek byłoby to jeszcze o kolejny "mnożnik" powiększone. Mianowicie pozycja litery do odczytu z hasła wskazywałaby na jakąś inną w odczytywalnym ciągu znaków i jej hash dodawany byłby do ciągu jeszcze przed hashowaniem jako kolejna sól. W ten sposób dochodziłaby sól zmienna. O co mi chodzi? Przykład
Mamy ciąg odczytywalny loginu (ale może to być dowolny inny ciąg znakowy, najlepiej taki, którego nie przechowujemy nigdzie w sesjach):
jakiś_tam_user
Mamy też hasło
haslo_usera
I chcemy poznać 8 literę hasła, czyli 's', więc pobieramy też 8 (możemy ustalić tutaj inną niż 8, na przykład (kolejność_litery + 5)%jakas_z_zakresu_[2,długość_loginu] ) literę loginu 'a'
teraz robimy hash('a').'s'.salt_jeszcze_jakiś
Co zyskujemy?
1. Dla dwóch userów z tym samym hasłem prawdopodobieństwo wystąpienia tej samej litery w określonym miejscu jest niższe co sprawia, że hashe będą różne, gdyż hasło 'kjlvkdfj' wygeneruje dla userów "mastah" i "gostek" częściowo inne hashe znaków.
2. Dla tej samej litery na różnych pozycjach prawdopodobieństwo wygenerowania hasha identycznego także znacznie spada, dzięki czemu ta sama litera u tego samego usera ale w różnych miejscach najprawdopodobniej wygeneruje inny hash, przez co zwykłe podstawianie zapewne szlag trafi (IMG:style_emoticons/default/winksmiley.jpg) Wystarczy spojrzeć na litery 's' i 'a' w haśle. 's' będzie miał hashe liczone od 'k' i 't'. Zaś 'a' hashe od 'a' i '_'. To daje o wiele więcej kombinacji niż n*n*n, bo też do jednego znaku może być przypisane kilka kodów nawet hasło "aaaaaa" wygeneruje inne hashe dla poszczególnych liter 'a' przy loginie typu "konwersja".

EDIT: Podoba mi się ten temat, bo lubię zajmować się ciekawymi zagadnieniami teoretycznymi. A pomysły tutaj rzucane myślę, że są ciekawym uzupełnieniem tematu o bezpieczeństwie (IMG:style_emoticons/default/smile.gif) W końcu ludzie zdają się zazwyczaj na domyślne algorytmy bezpieczeństwa, a my teraz zajmujemy się w sumie autorskimi metodami autoryzacji użytkownika.

Ten post edytował thek 4.09.2009, 09:42:54