Wszyscy znamy ten schemat: tabela z użytkownikami, user ID, username, hash hasła. Ostatnia z tych kolumn przechodziła powolną ewolucję: wpierw zamiast MD5 zalecano SHA(5)1(2), potem niezbędne okazywało się solenie hashy, następnie - okazało się, że skróty kryptograficzne są be i należy używać bcrypt lub podobnej funkcji przeznaczonej specjalnie do haseł. Ogólny schemat pozostawał jednak ten sam.
Jeremy Spilman w swoim artykule "A better way to store password hashes?" proponuje inny sposób przechowywania haseł. Zamiast łączyć informację o haśle z informacją o użytkowniku, można przechowywać hashe w osobnej jednokolumnowej tabeli (lub w innej strukturze danych o semantyce zbioru, np. Set w Redisie), posolone user ID bądź inną informacją specyficzną dla użytkownika.
Już sama taka operacja - rozdzielenie danych o użytkownikach i danych o hasłach - nastręcza trudności atakującemu który przejął dane z bazy. Spilman proponuje jednak dodatkowo wzbogacić nasz zbiór hashy o kilka miliardów losowych wartości o długości hasha. Pierwsze co nasuwa się na myśl to zwiększone prawdopodobieństwo kolizji, ale na przykład, przy wstrzyknięciu miliarda hashów i 128-bitowej długości hasha, zmienia się ono z 1:340282366920938463463374607431768211456 do 1:340282366920938463463374607431. Na pierwszy rzut oka, można przeżyć z takim ryzykiem.
Trzeba poczekać jeszcze miesiąc-dwa na odzew ze strony ludzi od security i w zasadzie można będzie zacząć stosować takie rozwiązanie. Może w ramach julython ogarnę jakiś moduł autoryzacji do Django?