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.