Monday, July 13th, 2009...12:19 am

Jak rozsupłać hasło, czyli alternatywne przemyślenia o haseł implementacji?

Jump to Comments

 

Czasami w ramach rozrywki jak i procesu informacji zdobywania czytam blogi. W szczególności lubię czytać te gdzie piszą sensownie i na temat (jaki, to już zależy od bloga). Dlatego, nawet pomimo tego że tematyka nie jest związana bezpośrednio z tym czym się zajmuję, lubię czytać blog Pawła

Paweł tenże ostatnio poświęcił sporo czasu i miejsca na swoim blogu tematowi haseł, a dokładniej ich testowaniu, projektowaniu aplikacji z nich korzystających oraz pewnych implikacjach korzystania z haseł w kontekście logowania działań użytkownika w aplikacji. Całość jak najbardziej interesująca i warta przeczytania, szczególnie przez tych którzy z tą materią mają do czynienia.  Ja po przeczytaniu całości miałem tylko jedną refleksję … strasznie dużo wysiłku kosztuje nas utrzymanie i kontrolowanie czegoś takiego jak hasło użytkownika.

(cc) Pensiero

I wcale nie zyskujemy dzięki tak bardzo wysokiego poziomu zabezpieczenia. Nie mówiąc już o tym, że para login \ hasło niekoniecznie spełnia swoją rolę jako poświadczenia tożsamości użytkownika jako takiego. Przy okazji tworzy to też szereg problemów związanych z zapewnieniem bezpieczeństwa aplikacji, utrzymaniem jej itp. A co gdyby podejść do tematu inaczej ???  Czy hasła to faktycznie najlepsze rozwiązanie? Czy możemy pozbyć se przynajmniej niektórych problemów (wszystkich napewno nie).

I tutaj stali czytelnicy wiedzą że wejdę na ścieżkę znaczoną claims czyli będzie o information card albo OpenID … albo i o obu naraz … z góry przepraszam :).

Na początek pomyślmy do czego tak naprawdę aplikacje używają logiu i hasła? Ciekawa dyskusja na ten temat znajduje się w wpisie Vittorio Bertociego The Tao of Authentication (Part I) (przy okazji polecam też części II i III), a że z wnioskami sie zgadzam to odsyłam tam do pełnej lektury a tutaj posłużę się tylko wnioskiem. Login i hasło, lub szerzej poświadczenia użytkownika (ang. credentials)  służy aplikacji tylko i wyłącznie do potwierdzenia, że użytkownik już kiedyś w tym miejscu był, zarejestrował się w ten lub inny sposób i powraca w celu skorzystania z aplikacji ponownie.

Teraz … tak jak to się utarło w sieci, każda z aplikacji przeważnie implementuje (lepiej lub gorzej) swój mechanizm uwierzytelnienia, tym samym w wiekszości przypadków własny skład danych uwierzytelniających i ich obsługę. Z własnego doświadczenia mogę tylko dorzucić, że nawet w ramach jednej organizacji rzadko się zdarza żeby mechanizm ten a tym bardziej baza danych użytkowników była wspólna. Przeważnie nawet gdy w środowisku istnieje centralne repozytorium takich danych (na przykład usługa katalogowa) to różnego typu bazy i mechanizmy ich obsługi są mnożone. O sytuacji w sieci publicznej nie ma co nawet wspominać – w końcu każda aplikacja musi mieć login i hasło. I w takich wypadkach uwagi Pawła są jak najbardziej sensowne i na miejscu. Użytkownik musi te hasła pamiętać i nimi zarządzać, aplikacje powinny poprawnie je obsługiwać, transmisja powinna być zabezpieczona i tak dalej.

Jak sytuacja się zmienia gdy na scenę wkracza IP (Identity Provider) \ Security Token Service (STS) a aplikacja zostaje Relaying party (RP) tokeny przez taki STS wystawione konsumująca? Rysunek obrazujący taką sytuację wyglądać będzie jakoś tak:

(Dokładniejszy opis komunikacji pomiedzy RP i STS można znaleźć w ramach specyfikacji Identity Metasystem na stronach OASIS).

Elementów na tym rysunku mamy conajmniej kilka, zaczynając od bytów grubych czyli aktorów:

  • Klient, który uzyskuje dostęp do aplikacji (RP) i dla którego ta aplikacja jest jak najbardziej zewnętrzna
  • IP\STS, który również znajduje się w sieci jako byt zewnętrzny, a do którego Klient może zwórcić się w celu uzyskania odpowiedniego tokenu
  • RP, czyli aplikacja do której Klient próbuje uzyskać dostęp, a która skłonna jest token wystawiony przez STS i przesłany przez klienta skonsumować.

W ramach STS możemy dodatkowo wyróżnić:

  • skład danych o użytkownikach
  • log związany z przechowywaniem danych nie tylko o akcjach użytkownika ale również  opcjonalnie o  RP występujących o token użytkownika.

W ramach aplikacji (RP ewentualnie może pojawić sie log aktywności użytkownika. Składowanie przez RP danych profilu użytkownika celowo dla uproszczenia sytuacji pomijam.

Schemat komunikacji pomiędzy Klientem  \ RP \ STS wygląda następująco:

  • Klient próbuje uzyskać dostęp do aplikacji (RP), która komunikuje mu swoje wymagania (akceptowane STS, zestaw wymaganych i opcjonalnych claims itp.)
  • Klient wybiera ze swojej kolekcji kartę odpowiadającą STS, który spełnia wymagania RP i wysyła prośbę o token. W tej fazie może wystąpić dodatkowo uwierzytelnienie Klienta względem STS.
  • Klient przesyła uzyskany token do aplikacji (RP), która korzysta z niego w celu odtworzenia profilu użytkownika na podstawie danych z tokenu (claims) oraz własnych danych (specyficznych dla danego RP).

Pytanie – co to tak naprawdę zmienia z punktu widzenia bepzieczeństwa aplikacji (RP) i interakcji użytkownika z tą aplikacją?

Po pierwsze aplikacja jako taka nie musi po swojej stronie utrzymywać bazy danych zawierającej poświadczenia użytkowników jak i niekoniecznie musi przechowywać wszystkie dane użytkwnika. Z tego powodu zmniejsza się ryzyko przejęcia tych danych poprzez potencjalny błąd w aplikacji. Ale to tak na marginesie.

Ponieważ aplikacja jako taka nie implementuje samodzielnie haseł nie ma miejsca na ataki mające na celu pozsykanie danych logowania, czyli na przykład zgadywanie loginów \ haseł poprzez próby logowania do aplikacji.

W takim układzie linia zaufania (trust boundary) pomiędzy klientem a aplikacja nie tyle zanika co zmienia swój charakter. Nie dotyczy ona bowiem wprost faktu wymiany poświadczeń a raczej wymiany informacji o użytkownik (claims), które  (teoretycznie, w zależności od tego do czego służy aplikacja) zostaną użyte do podjęcia w ramach danej aplikacji decyzji autoryzacyjnej (przyznaniu uprawnień) w ramach aplikacji. W takim schemacie uwierzytelnienia wyeliminowana zostaja natomiast wymiana danych uwierztelniających w formie tradycyjneh, login i hasła, pomiędzy użytkownikiem i aplikacją. Przez to wyeliminowane również po stronie aplikacji zostaje implementację elementów takich jak formularz logowania i zabezpieczenia sesji wymiany danych uwierzytelniających (elementy te w przypadku użycia Information Card objęte są zakresem specyfikacji).

Oczywiście również i w tym wypadku nadal należy zadbać o odpowiednie zabezpieczenie transmisji danych, tym bardziej, że zgodnie ze specyfikacją Information Cards w przypadku komunikacji z RP informacje o użytkowniku (claims) zabezpieczane są przy użyciu certyfikatu przez daną RP przedstawionego. Co prawda specyfikacja przyjęta przez OASIS dopuszcza i opisuje sposób interakcji z RP, które takowego certyfikatu nie posiadają, jednak w takim przypadku claims podróżują po sieci nieszyfrowane i tego należy mieć świadomość. Świadomość świadomością ale dodatkowym elementem układanki jest możliwość zablokowania przez IP możliwości przesłania tokenu do RP, które zabezpieczenia przy użyciu SSL nie stosuje poprzez wyspecyfikowanie tego w ramach karty (element ic07:RequireStrongRecipientIdentity).

Ciekawostką jest tutaj powstanie innej linii zaufania, pomiędzy RP a (pośrednio) IP, która nie jest linią bezpośrednią, ponieważ pomiędzy nimi w łańcuchu komunikacji znajduje sie użytkownik, który decyzję o zaufaniu takim podejmuje (The Law of Identity #1). Jednak i tutaj w tym modelu RP ma swoisty rodzaj kontroli nad tym zaufaniem poprzez specyfikacje polityki wymagan względem IP. Tym samym aplikacja (RP) może określić z którymi (spełniającymi jakie warunki) “dostarczycielami” informacji (IP) chce współpracować.

Mamy więc aplikację, która pełni rolę relaying party, użytkownika, który świadom swych praw i odpowiedzialności tej aplikacji przesyła odpowiedni token uzyskany od pewnego i zaufanego dostarczyciela  (identity provider) i we wszystkim tym jest tylko pewien szkopuł (nie wspominając już o tym że narazie IP nam brakuje w świecie realnym) – użytkownik żeby ten token uzyskać musi  zględem STS w sieci w jakiś sposób zostać uwierzytelniony. Czyli wszystko o kant … potłuc i wróciliśmy do punktu wyjścia ??? Niekoniecznie.

Faktem jest, że linia zaufania nakreślona przez Pawla pomiędzy aplikacją a użytkownikiem istnieje nadal jednak przesunięta została pomiędzy użytkownika a IP (STS). I do tego elementu komunikacji nadal jak najbardziej wszystkie uwagi przedstawione co do implementacji sposobu uwierzytelnienia się odnoszą.

Chyba że dany STS pozwoli użytkownikowi również na uwierzytelnienie się przy pomocy odpowiedniej karty 😉 … co jak najbardziej jest możliwe, a co mocno ogranicza (napewno nie eliminuje w całości ponieważ pomysłowość ludzka nie zna granic a software ma błędy, więc ktoś może kiedyś coś wymyśli) zagrożenie związane ze pishingiem w trakcie logowania, przejęciem uwierzytelnienia itp.

Podsumowując …

..ten trochę przydługi wywód. I gdzie w tym wszystkim są zalety względem bardziej tradycyjnego modelu … spróbuje je przedstawić tak jak ja je z grubsza widzę:

  • Dla developeerów piszących aplikację:
    • jednolity sposób implementacji mechanizmów uwierzytelnienia i autoryzacji, na wielu różnych platformach
    • brak konieczności implementacji składu danych uwierzytelniających, własnych mechanizmów uwierzytelnienia itp.
    • ogranicznienie zagrożeń związanych z przesyłaniem danych uwierzytelnienia pomiędzy użytkownikiem a aplikacją takich jak możliwość przejęcia poświadczeń itp.
  • Dla użytkownika
    • jednolity schemat interakcji z wieloma aplikacjami w zakresie uwierzytelnienia
    • kontrola nad danymi przesyłanymi do aplikacji (ok, może tutaj przesadzam ze świadomością użytkowników)
    • Ograniczona (nie zerowa i napewno nie pojedyncza ze względu na różne zestawy danych i cele wydawanych kart) liczba poświadczeń służacych do uwierzytelnienia w aplikacjach.

Czyli przez (mocno)teoretycznie  prosty zabieg zyskujemy (przynajmniej według mnie) dosyć dużo w kwestii bezpieczeństwa jednocześnie upraszczając projektowanie, implementację i utrzymanie aplikacji.

To czy podejście do uwierzytelnienia \ autoryzacji oparte na współpracy aplikacji z dostawcami informacji o tożsamości się przyjmie zobaczymy pewnie w przeciągu kilku następnych lat. Jak i kilka innych niegłupich pomysłów w przeszłości rozwiązanie to może umrzeć śmiercią naturalną. A dokładniej ze względu na przywiązanie użytkowników … i deweloperów … i architektów … i wszystkich … do ekranu z loginem i hasłem. Nie oznacza to jednak że nie należy tego pomysłu rozważyć. A nuż korzyści osiągniete w ten sposób korzyści będą większe niż koszty związane z przejściem na tą technologię i utowrzenie odpowiedniej infrastruktury.

A wszystko to bierze się stąd, że ktoś kiedyś rozwiązał pewien problem … problem brzmiał – jak sprawdzić czy dany użytkownik już u nas był … i tak powstał login\password i cookie … co wygenerowało kilka innych problemów. Chyba w naszej cywilizacji nazywamy to POSTĘP.

14 Comments

  • Wszystko pięknie i fajnie. Szkoda, że już od kilkunastu lat trwa bój o rozwiązanie tego problemu. Technologia jest, ciągle ją ulepszamy ale po dziś dzień duża część aplikacji nie potrafi jej wykorzystać. Developerzy ucieszeni, ich szefowie też bo mogą szybciej wytwarzać oprogramowanie, a mimo to aplikacje nadal korzystają z przestarzałych metod login, hasło, etc.
    Trochę mi to przypomina walkę nowych technologi zasilania silnika w samochodzie. Mamy super technologie, jednak jest ona zapychana na boczny tor przez producentów paliw.

  • Na początku zaznaczę, że zgadzam się iż implementowanie mechanizmów uwierzytelniania w każdej z aplikacji osobna jest pomysłem umiarkowanie sensownym i zgadzam się z dążeniem do centralizacji tej informacji.

    Popatrzmy jednak na taką bankowość internetową. Nagle proces uwierzytelnienia użytkownika jest przesunięty poza kontrolę aplikacji i banku. Udany atak na taką zewnętrzną usługę może skutkować tym, że atakujący uzyskają dostęp do wszystkich kont (w aplikacji, nie tych z pieniędzmi) klientów banku. Co prawda pozostaje wówczas jeszcze autoryzacja transakcji, ale to oddzielny temat. Klienci nie muszą zauważyć drobnej różnicy między podatnością w samej aplikacji bankowości internetowej, a podatnością (i udanym jej wykorzystaniem) w przypadku zewnętrznej usługi uwierzytelnienia. W rezultacie to bank “traci” (tu można by się nawet zastanowić, czy prawnicy nie podciągną takiego scenariusza pod outsourcing z wszystkimi konsekwencjami z tego faktu wynikającymi). Oczywiście można wówczas postawić własną usługę tego typu, tylko w takim scenariuszu (bankowości internetowej) zrobi się prawdopodobnie relacja 1-1 (jeden serwer OpenID, jedna aplikacja bankowości).

    Patrząc natomiast na aplikacje wewnętrzne podobną rolę może odgrywać AD.

    W sumie upowszechnienie wspominanych tu rozwiązań byłoby szybsze, gdyby skorzystały z nich serwisy typu Nasza-Klasa, Allegro, Blip, (…).

  • Powód, dla którego różne podmioty implementują własne schematy uwierzytelniania jest bardzo prosty – każdy ma inne wymagania wobec poziomu pewności oferowanego przez dany mechanizm uwierzytelnienia.

    W niektórych modelach (np. IDA-BC) każde uwierzytelnienie można podzielić na dwa etapy – rejestracja, którą robi się raz i uwierzytelnienie sesji, które powtarza się wiele razy.

    Różne wymagania dotyczące poziomu pewności dotyczą zwłaszcza tego pierwszego etapu tj. rejestracji. Sprawę komplikuje fakt, że każde zwiększenie poziomu pewności zwiększa koszty i odstrasza klientów.

    Dlatego różne podmioty kombinują jak osiągnąć rozsądny kompromis między tymi przeciwstwanymi wartościami. Zobaczcie jak różne sposoby stosują tutaj banki (dwa dokumenty ze zdjęciem), banki internetowe (dowód sprawdza kurier), Kokos.pl (przelew 1 gr), Allegro (list polecony) itd.

    Patrz też IPSec.pl “Porównanie mechanizmów uwierzytelnienia”.

    Z tego powodu jeszcze przez długi czas różne fajne protokoły będą znajdowały “nabywców” głównie wśród operatorów różnych portali społecznościowych itd, a 90% uwierzytelnienia będzie robione nadal hasłami. Problem nie jest w protokołach tylko w zaufaniu.

    Żeby bank zaczął korzystać z Infocard czy OpenID musiałby istnieć dostawca, który ZAGWARANTOWAŁBY tożsamość klienta na poziomie możliwym do obronienia w sądzie i zdjął z banku ODPOWIEDZIALNOŚĆ za ewentualne nadużycia.

  • Wiesz Pawle patrząc na stopień współpracy Allegro i Naszej-klasy może się okazać, że w niedalekiej przyszłości będzie istniała taka opcja. Kwestia jak szybko dołączyłyby inne portale.

  • @Paweł
    Zgadzam się w pełni, że dla takiego Banku uwolnienie tożsamości użytkownika może nie być łatwym krokiem. Może to jednak zależeć od dostępności IP z odpowiednio silnym poświadczeniem tożsamości użytkownika … patrząc jednak na to z drugiej strony to instytucja taka jak Bank dla swoich klientów jest idealnym kandydatem na Identity Provider. Zgodzę się że nie jest to jej “core business” ale … w szczególności jeżeli Bank świadczy więcej niż jedną usługę to mógłby takie podejście wypracować.
    Nie oczekuję jednak że w przypadku instytucji takich jak Banki itp taka zmiana nastąpi szybko.

    @Paweł i Kaarol w jednym
    Tak, zgodzę się że klucz do sukcesu leży w tym, żeby tego typu serwisy takie decyzje podjęły. I szczerze powiem, że dziwię się że tego nie robią – w szczególności na przykład taki Blip gdzie jeden z twórców mocno OpenID wspiera(ł).
    NK i Allegro to już bardziej ciekawy przypadek – nie znam szczegółów technicznych ale pierwsze co pomyślałem gdy ogłosili współpracę to że w tle powstał pewnie kawałek back-end, który taką współpracę umożliwia .. synchronizuje, wymienia itp – a wystarczyłoby żeby N-K została IP a Allegro zostało RP … i to by otworzyło drogę do tylu innych możliwości … w prosty sposób.

  • @Tomek

    Znów jedna uwaga trochę z boku. Jeśli bank świadczy więcej niż jedną usługę dla swoich klientów rzeczywiście powinien/może sam stać się dla nich Identity Provider. Problem(?) w tym, że oprogramowanie dla banku w przeważającej większości robią firmy trzecie, dla których zaproponowanie własnego SSO ma pewną wartość – zamknięcie klienta do własnych rozwiązań lub przynajmniej utrudnienie wejścia konkurencji. To, że takie implementacje SSO (tak wiem, że SSO to nie jest do końca to samo do IP) są często kulawe, to już temat inny…

    Sam jeszcze za czasów pracy w korporacji kilka razy wyrzucałem z umów zakup wspaniałych narzędzi od danego dostawcy do zarządzania użytkownikami i ich uprawnieniami zmuszając ich do stosowania się do naszej wizji jednego repozytorium informacji o użytkownikach, ich danych opisowych i uprawnieniach (choć to akurat chodziło o aplikacje dla pracowników a nie klientów).

  • @Wampir
    Tak, wiem że to tak wygląda 🙂 … co nie przeszkadza mi w wolnym czasie jaki poświęcam na tego bloga w tym temacie ewangelizować … z czego pewnie nigdy nic nie wyjdzie (powodów kilka, między innymi nie ta metoda nie ten target :), ale to nisko na liście powodów) ale cóż …

    … to co ważne z Twojego komentarza to ta “wizja” – wg mnie powinna ona przybierać bardziej formę strategii danej organizacji w zakresie Id&AM. Większość organizacji jej nie ma i stąd ta mnogość rozwiązań i implementacji.

  • Bankom i firmą finansowym to się akurat nie dziwie. U nich prawie każdy system jest wykonywany przez firmy zewnętrzne. Jeden system robi firma X drugi Y. Z tego co słyszałem bardzo często instytucje takiej wagi same do końca nie wiedzą czego oczekują. Tak więc jeśli nie potrafią sprecyzować wymagań dot. działania systemu to już na pewno nie będą pamiętały o czymś takim jak Id&AM.

    Dodatkowo firma developerska jest nastawiona na zarobienie jak największej ilości pieniędzy w stosunkowo krótkim czasie. Dlatego programiści mają zrobić konkretny system pod konkretne cele i nikt z dev nie będzie proponował rozwiązania, które na początku wymaga większego wkładu. Mają oni już swoje klocki, które kiedyś wyrzeźbili więc raczej wsadzą swój mechanizm niż stworzą coś nowego. Przynajmniej kiedyś takie zdanie mi zostało przedstawione jak pytałem jak to jest być programistą.

  • @kaarol
    To się zmienia – może nie jeżeli chodzi o dostawę oprogramowania do banków na przykład ale te instytucje właśnie, które najwięcej takich rozwiązań u siebie wdrażają pierwsze dochodzą do wniosku że coś z tym trzeba zrobić … i przynajmniej próbuja to ogarnąć w ramach zautomatyzowanych procesów (krok 1), pewnie krok 2 czyli jakaś wspólna strategia w zakresie usług uwierzytelnienia \ autoryzacji też się pojawi z czasem. Gdzieniegdzie już istnieje, nie zawsze w sensownej formie.

  • @Tomek
    Zgadza się tylko czy aby nie wydaje ci się, że jest to robione od tyłu?? Mamy systemy teraz wypełnijmy lukę między nimi czyli zatrudnijmy firmę, która to zrobi i bardzo często trafia się jakieś autorskie rozwiązanie, które potem znowu trzeba obłożyć dodatkową warstwą:/

  • @kaarol
    A to już przewrotnie powiem … zależy jak to jest robione :).

  • łolaboga – cusz za dyzqrz.
    takie pytanie z ciekawosci – jakiekolwiek nie byly poswiadczenia, zastosowany mechanizm – czy nie byloby rozwiazaniem problemu wymuszenie wykorzystania certyfikatow?
    czy ktos kiedys widzial firme, ktora ma cala siec oparta o jakies rozwiazania tego rodzaju? widzialem sieci gdzie mocniej lub slabiej wspiera sie logowaniem certem. zdazylo mi sie widziec nawet takie bliskie idealowi – gdzie karta byla wielosystemowa i dzialala na braki przy wejsciu, logowanie do kompa jak i do wejscia do kibla.
    ale zawsze gdzies trzeba bylo podawac jakies haslo – a to do bazy, a to do aplikacji web, a to do jakiegos innego systemu. czy przemawia za tym jakies ograniczenie techniczne? jaki jest narzut kosztow przesiadki na uwierzytelnienie certem/biometric czy innym takim wynalazkiem?

  • i jeszcze jedno – czy istnieja rozwiazania ‘bramki’?
    typu: jakas firma dostarcza nam gowniana aplikacje ktora jest nam niezbedna ale nie oferuje możliwości doboru uwierzytelnienia. więc stawiamy serwer który przechowuje -np. pary login/hasło i powiązane z nimi certy userów. user proxuje się do takiej usługi swoim certem, a serwer za niego podaje automatycznie odpowiednie credentialsy.

    troche tak jakby ‘keepass server’ (;

  • @Nexor
    Wymuszenie używania certyfikatów problemów nie rozwiązuje a nawet je tworzy. Dostępność tych certyfikatow, zaufanie do CA, dostepność urządzeń (czytnik, karta) , wielość rozwiązań chociaż niby to jedno … że o wsparciu od strony aplikacji nie wspomną … wszystko to powoduje że rozwiązania typu certyfikat \ smartcard nie wyjdą poza rozwiązania korporacyjne mocno. Przynajmniej wedlug mnie …
    Oprócz tego pozostaje kwestia zastosowania odpowiednich środków do potrzeb – certyfikat w zasadzie służy jako dodatkowy środek przy uwierzytelnieniu do mocniej chronionych zasobów \ informacji. IMO wymaganie użycia certyfikatu przy dostepie do strony typu “witryna o wszystkim” to lekka przesada.
    Ostatnim elementem jest “user expirience” – używanie kart jest z mojego doświadczenia postrzegane jako średnio wygodne przez użytkowników.

    Ale jakby trzeba bylo, to Information Card sa na to gotowe … karta może wymagać poświadczenia certyfikatem – jest to jedna z przewidzianych obecna specyfikacja metod uwierzytelnienia uzytkownika przy użyciu karty wzgledem IP.

    Co do rozwiazan typu “keepass server” to oczywiście takowe istnieja i sprzedawane są pod szumnym hasłem “single sign-on”.

Leave a Reply