mina86.com

Login + hasło

Na początek jakie niebezpieczeństwa (poza możliwością odgadnięcia lub kradzieży hasła) kryją się za zwykłym logowaniem z hasłem. Oczywiście problemem jest atak typu man in the middle, tzn. jeśli komuś uda się podsłuchać komunikację przeglądarka-serwer to pozna hasło użytkownika.

OpenID

Teraz co się kryje za OpenID? W OpenID zalecane jest stosowanie delegacji, tzn. w dużym skrócie zapisanie adresu dostawcy usługi np. na swojej stronie (w taki sposób, że systemy logowania OpenID są w stanie ten adres odczytać), aby potem przy logowaniu podawać jako swój identyfikator adres np. naszej strony. Delegacja jest bardo pożytecznym mechanizmem, gdyż pozwala w szybki sposób zrezygnować z jakiegoś dostawcy usługi OpenID–wystarczy zmienić wpis na naszej stronie, zamiast zmiany ustawień na dziesiątkach serwerów.

Jak zatem wygląda uwierzytelnianie OpenID? W dużym skórcie, z wykorzystaniem delegacji,identyfikator wpisany przez użytkownika jest przekształcany na adres serwera, z którym strona się łączy (kanał A), aby zostać oddelegowanym do dostawcy usługi OpenID (kanał B), który uwierzytelnia użytkownika (np. hasłem) (kanał C) i odsyła informację o sukcesie bądź porażce stronie, która rozpoczęła całą zabawę.

Scenariusz pierwszy: Ktoś przejął kontrolę nad kanałem A, loguje się na stronie podając identyfikator ofiary, dzięki przejęciu kontroli nad kanałem A przesyła od razu informacje o tym, iż uwierzytelnianie się powiodło i kończy zabawę.

Scenariusz drugi: Ktoś przejął kontrolę nad kanałem B, loguje się na stronie podając identyfikator ofiary, strona pobiera adres dostawcy usługi i łączy się z nim, ale ponieważ kanał B jest skompromitowany atakującemu udaje się włamać do systemu.

Scenariusz trzeci: Ktoś przejął kontrolę nad kanałem C i  teraz tak samo jak w zwykłym ataku na hasło może je podsłuchać.

Wnioski

Owszem, można mieć wątpliwości czy te rozważania wystarczą, aby stwierdzić, iż OpenID jest trzy razy mniej bezpieczny od zwykłego logowania na podstawie nazwy użytkownika i hasła, ale pokazują jedną rzecz: Jeżeli nie używasz połączeń szyfrowanych z uwierzytelnianiem to jedyne co OpenID Ci daje to większa wygoda (jeden login, jedno hasło) za cenę mniejszego bezpieczeństwo.

Wynika z tego, iż zarówno serwer z zapisaną delegacją jak i dostawca usługi OpenID muszą posiadać wykupione certyfikaty u powszechnie uznawanych centrów certyfikacji. Musimy ponadto mieć nadzieję, że strona, na której chcemy się uwierzytelnić naszym bezpiecznym identyfikatorem będzie sprawdzać poprawność certyfikatów i nie przyjmie self signed certificates ani certyfikatów podpisanych przez jakieś centra, które nie sprawdzają tożsamości podmiotu.

To wszystko rzuca cień na ideę wielkiej otwartości standardu. Niby każdy może dostarczać usługi OpenID, a delegacja może być na dowolnej stronie, ale aby nie wpaść w pułapkę braku bezpieczeństwa należy wydać pieniążki na certyfikaty, a to troszkę utrudnia sprawę.

Co w zamian?

Kiedyś bardzo nie lubiłem mechanizmów zapamiętywania haseł w przeglądarkach internetowych, ale teraz dochodzę do wniosku, iż o ile hasła te są szyfrowane hasłem głównym, jest to całkiem dobry i bezpieczny mechanizm. Pozwala on na generowanie losowych haseł dla każdej strony (chociażby przez head -c 20 /dev/random | sha1sum) dzięki temu nawet jeżeli ktoś wykradnie hasło do jakiejś strony to wszystkie inne są bezpieczne, a my tymczasem musimy znać jedynie hasło główne naszego zarządcy haseł.

Innym ciekawym rozwiązaniem jest generowanie za pomocą JavaScript haseł na podstawie jakiegoś ciągu specyficznego dla danej strony (np. adresu) oraz naszego hasła głównego (np. sha1_hmac(adres, haslo). Skrypt do generowania możemy trzymać na naszym dysku lokalnym. Ma to tę zaletę nad zarządcą haseł, że jest przenośne pomiędzy przeglądarkami. Problemem jest to, że raz ustawionego hasła głównego nie można już zmienić, można to próbować obejść trzymając w skrypcie zaszyfrowany naszym hasłem głównym klucz służący do generowania haseł (czy zwiększy to poziom bezpieczeństwa jest jednak kwestią dyskusyjną).