Pierwszy przykład to ta wypowiedź:

#fail #security rapidshare.com nie szyfruje haseł dostałem maila z moim hasłem. A nie link do zmiany jego ...

Pytanie – czy na podstawie otrzymania zapomnianego hasła można wyciągnąć wniosek, że hasło nie jest szyfrowane? A może jest tak:

Przypominam, że jeśli hasło jest ZASZYFROWANE, to można je ODSZYFROWAĆ i wysłać użytkownikowi. Może więc jednak szyfruje :)

Z dużym prawdopodobieństwem można przypuszczać, że rzeczywiście hasło po stronie serwera jest przechowywane w formie jawnej. Jest to jednak tylko przypuszczenie, przesłanka, którą w tym przypadku dysponujemy nie jest wystarczająca, by stwierdzić, że hasło nie jest szyfrowane. Wystarcza natomiast do tego, by stwierdzić, że hasło nie jest przechowywane w postaci hasha. W mojej ocenie pojęcie szyfrowania oznacza takie przekształcenie wiadomości, które umożliwia jej odzyskanie (odszyfrowanie). Nie jest więc wykluczone, że jakiś serwis przechowuje hasła w formie szyfrowanej, a gdy jakiś użytkownik hasła zapomni, jest ono odszyfrowane i wysyłane mu mailem. Temat przechowywania haseł poruszałem już wielokrotnie, zainteresowanych odsyłam na przykład tu: O przechowywaniu haseł.

Ktoś może uznać, że się czepiam. Pewnie coś w tym jest, ale moim zdaniem precyzja wypowiedzi jest istotna. Szyfrowanie hasła to nie to samo, co przechowywanie hasha hasła. Przechowywanie hasła w formie szyfrowanej jest prawie tak złe, jak przechowywanie go w formie jawnej, ale... Tu niespodzianka – istnieją protokoły uwierzytelniania, które wymagają hasła użytkownika w formie jawnej, jeśli więc są one stosowane, przechowywanie hasła w formie zaszyfrowanej może być uzasadnione. Taka funkcja istnieje nawet w Windows: Store passwords using reversible encryption.

Na zakończenie tego przykładu pytanie – czy fakt otrzymania linku do zmiany hasła pozwala na stwierdzenie, że po stronie serwera hasło nie jest przechowywane w formie jawnej lub szyfrowanej?

Teraz drugi przykład. Natknąłem się na niego, gdy szukałem komentarzy ludzi na temat wygody i bezpieczeństwa haseł maskowanych. Znalazłem między innymi ten wpis: Bezpieczne metody uwierzytelniania użytkowników, a pod nim następujący komentarz:

Krew się we mnie zagotowała jak przeczytałem ten wpis. Czy wie Pan o czym świadczy pytanie o losowe litery z hasła? O tym, że hasło trzymane jest w \*postaci niezaszyfrowanej\* co urąga wszelkim zasadom bezpieczeństwa, szczególnie w banku! (...)

Czy autor tego komentarza ma rację? Chodzi mi tu o cytowaną część komentarza, która dotyczy haseł maskowanych przy uwierzytelnieniu w systemach bankowości internetowej.

Odpowiedź na to pytanie brzmi: to zależy. Nie jest tak, jak sugeruje autor, że użycie hasła maskowanego zawsze oznacza przechowywanie hasła w postaci jawnej (lub zaszyfrowanej). To zależy od konkretnej implementacji. Są takie, które w chwili zmiany hasła generują pewną liczbę masek i wyliczają stosowne hashe. W tym przypadku hasło nie musi i nie jest przechowywane w postaci jawnej. Są również i takie rozwiązania, w których hasło w takiej postaci najprawdopodobniej jest przechowywane. Świadczą o tym przekształcenia wykonywane po stronie klienta (w przeglądarce) po wpisaniu hasła. Takim sygnałem może być przekształcenie typu:

sha1(token, pwd)

gdzie token jest losowy i unikalny dla każdej próby uwierzytelnienia, natomiast pwd to fragment hasła wpisany przez użytkownika. Ale jeśli przekształcenie przyjmuje formę:

sha1(token, sha1(pwd))

nie ma już konieczności przechowywania w bazie hasła w formie jawnej. Tu pozwolę sobie przypomnieć o jednym z udostępnionych przeze mnie wyzwań, w którym przekształcenia wykonywane na wpisanym przez użytkownika haśle przed wysłaniem go do serwera są dość istotne.

Dlaczego podaję te przykłady? Wyciąganie na podstawie istniejących przesłanek błędnych lub nieuprawnionych wniosków, może być szkodliwe. Jeśli dochodzimy do etapu wnioskowania, warto zastanowić się, które z naszych wniosków mają twarde dowody, a które opierają się w znacznej części na naszej intuicji. Być może warto przeprowadzić jakieś dodatkowe testy, które nasz wniosek potwierdzą, lub obalą.

Oryginał tego wpisu dostępny jest pod adresem Wyciąganie błędnych wniosków II

Autor: Paweł Goleń