Zauważyłem, że w znacznej części aplikacji webowych przy uwierzytelnianiu użytkownika zamiast hasła przekazywany do serwera jest rezultat funkcji hash(haslo+login), gdzie hash to albo md5 albo sha1. Pytanie - po co?
O nadużywaniu funkcji skrótu
Nie jestem w stanie znaleźć żadnej "wartości dodanej" wnoszonej przez to rozwiązanie. Owszem, hasło nie jest wówczas przesyłane w postaci jawnej, ale przesyłany hash jest zawsze taki sam, więc zamiast zgadywać hasło, wystarczy po prostu przechwycony hash przesłać ponownie do serwera. Klasyczny przykład ataku typu replay. Mam wrażenie, że autorzy tego rozwiązania (stosowanego dość konsekwentnie przez jedną z moich ulubionych firm) nie do końca przemyśleli to, co robią. Być może intencją było ukrycie hasła w przypadku, gdy dane uwierzytelniające przesyłane są bez szyfrowania (czyli bez SSL). Jeśli miałoby to rzeczywiście spełniać swoją rolę, wówczas serwer powinien przy wygenerowaniu dowolnej strony logowania, generować token (unikalną wartość), która powinna być ujęta przy generowaniu skrótu, coś postaci hash(token+hash(haslo+login)), a nawet bardziej coś postaci hash(token+hash(hash(haslo)+login)). Wówczas otrzymany rezultat byłby unikalny (z dokładnością do kolizji, ale to zupełnie inny temat) dla każdej próby logowania, ponieważ dla poszczególnych prób generowany byłby inny token.
Takie rozwiązanie dość dobrze spełniłoby rolę "ukrywania" hasła, tylko po co? Jeśli zakładamy, że atakujący może kontrolować transmisję (wystarczy, że może ją podsłuchać), to w 99% implementacji mógłby po prostu przejąć sesję użytkownika po jego uwierzytelnieniu. Dlatego uważam, że SSL jest dla aplikacji internetowych po prostu koniecznością.
http://www.lightbluetouchpaper.org/2007/11/16/google-as-a-password-cracker/