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ć?

[blooregard]

Akurat dwukierunkowość szyfrowania to nie jest dobry pomysł.

Akurat zgodzę się z @thekiem. Masz rację @sztos, co do funkcji haszujących, jednak zauważ, jaki problem ma @nexis: chodzi mu o podawanie wybranych znaków z hasła (o długości 16 znaków). Powiedz mi, jak chcesz to rozwiązać stosując haszowanie? Tu nie ma wyjścia - gdzieś musi być zapisane hasło w takiej postaci, by dało się z niego "wyciągnąć" te 5 znaków oraz ich pozycje w całym haśle do porównania.

I tu może tkwi problem: nie w sposobie zabezpieczenia samego hasła (bo do tego mozna użyć, tak jak wskazał @thek, autorskiego algorytmu, który niczym nie przypominałby tych najpopularnieszych, ale byłby odwracalny), ale właśnie w sposobie jego przechowywania. Np. hasło podzielone na fragmenty i każdy fragment przechowywany w osobnej bazie danych, na fizycznie innej maszynie?

Swoją drogą, ciekaw jestem bardzo, jak te kwestie mają rozwiązane od strony programistycznej wspomniane banki. Bo mój też stosuje takie zabezpieczenie.