Artykuły dotyczące tematu: uwierzytelnianie

dodany: 13.02.2013 | tagi: , ,

FIDO wprowadza wzmocnienie uwierzytelniania online

0

FIDO (z ang. Fast Identity Online) chce zrewolucjonizować system uwierzytelniania w Internecie. W tym celu opracowano nowy, otwarty i rozszerzalny protokół. Pomóc w tym ma FIDO Alliance, który powstał dzięki współpracy sektora prywatnego i przemysłu w walce, jaką stacza każdy, kto uwierzytelnia swoją tożsamość w Internecie.

No dobrze, ale po co?

Cały ten sojusz jest odpowiedzią branży na narodową strategię dotyczącą zaufanych tożsamości w cyberprzestrzeni, którą zaproponował prezydent USA, Barack Obama. National Strategy for Trusted Identities in Cyberspace (w skr. NSTIC) według Jeremy’ego Granta z Narodowego Instytutu Standardów i Technologii jest zaproszeniem sektora prywatnego do współpracy nad rozwojem otwartych standardów technologicznych, które pozwolą na uzyskanie bardziej zaufanego i bezpiecznego ekosystemu tożsamości w sieci. 

Samo FIDO twierdzi, że ich sojusz planuje zmienić charakter uwierzytelniania poprzez rozwijanie opartych na pewnych standardach specyfikacji definiujących otwartą, skalowalną i interoperacyjną grupę mechanizmów, które mogą zastąpić ludzką zależność od haseł i wzmocnić bezpieczne uwierzytelnianie użytkowników usług internetowych. Czyli w skrócie: dajemy wam nowy protokół, a wy zapominacie o czymś takim, jak hasło.

Jeszcze w tym roku FIDO chce wypuścić swój protokół, którego zadaniem będzie ujednolicenie wszystkich standardów uwierzytelniania proponowanych na przykład przez Internet Engineering Task Force czy World Wide Web Consortium.

Protokół jest przeznaczony do wzmocnienia interoperacyjności i wszechobecnej akceptacji wśród dostawców i użytkowników końcowych. Taką, przynajmniej, ma FIDO nadzieję.

Pozostaje tylko jedna kwestia. FIDO będzie musiało przekonać firmy, aby wrzucały ten protokół na swoje serwery i, co może okazać się znacznie trudniejsze, przekonać użytkowników końcowych do instalacji tegoż w swoich urządzeniach.

Technologia jest przystosowana do pracy z przeglądarkami i aplikacjami internetowymi, a sam protokół będzie wykorzystywał istniejący hardware jak czipy, NFC, tokeny czy wszelkie urządzenia biometryczne wspierające dwustopniowe uwierzytelnianie.

Dodatkowo, po stronie serwera FIDO wprowadzi do urządzenia tajne oprogramowanie, które następnie będzie wykorzystywane do budowy zaufania. W ten sposób sojusz FIDO jest zupełnie niepodobny do TLS, który zakłada tylko relacje wstępnego zaufania między klientami a serwerami.

Protokół ma być dostosowany do istniejących standardów uwierzytelniania i autoryzacji, w tym OAuth 2.0 i OpenID Connect.

Czy się to przyjmie? Nie wiemy. Jedno jest pewne: obecny system uwierzytelniania musi ulec jakieś zmianie. Skoro nasze dane nie są odpowiednio chronione za pomocą haseł, a ludzie są albo zbyt leniwi, albo niedoinformowani, to jedyną opcją jest rozwiązanie problemu przez technologię. Zmiany te często są dobre i potrzebne.

dodany: 21.01.2013 | tagi: ,

Pierścionek zamiast hasła?

2

Nie ma dnia, żeby komuś nie włamano się na konto. Zbyt słabe hasło, jego kradzież czy jakakolwiek inna przyczyna, włamy na nasze konta stają się coraz łatwiejsze.

I tu pojawia się Google ze swoją teorią, że hasła nie są już najlepszym rozwiązaniem dla wrażliwych czy jakichkolwiek kont. Pracownicy Google, Eric Grosse i Mayank Upadhyay napisali o tym w artykule, który zostanie opublikowany pod koniec miesiąca w IEEE Security & Privacy Magazine:

Stwierdziliśmy, że problemy z bezpieczeństwem i użytecznością są bardzo trudne do rozwiązania. Nadszedł czas, aby zrezygnować ze skomplikowanych zasad dotyczących haseł i poszukać czegoś lepszego.

Już mają pomysł: pierścień, który uwierzytelni tożsamość użytkownika, bez potrzeby angażowania hasła.

Pierwszy o ich pomyśle napisał Wired podając, że „coś lepszego” będzie zawierać się w sprzęcie. Google i tak przoduje w uwierzytelnianiu dzięki jego dwustopniowej odmianie, która łączy to, co użytkownik wie (hasło) z czymś, co użytkownik ma (jednorazowy kod wysyłany na podany przez niego numer telefonu). Jednak, jak zauważają Grosse i Upadhyay, pomimo używania tego sposobu uwierzytelniania przez miliony użytkowników, to ciągle odsetek osób, które nie są skore do zmiany sposobu uwierzytelniania jest ogromny.

Hasła i proste tokeny, takie jak ciasteczka nie wystarczają do utrzymania bezpieczeństwa użytkowników.

W artykule Grosse i Upadhyay proponują alternatywę: „Token USB” przypisany do użytkownika, który udzieli dostępu do jego kont bez potrzeby wpisywania jakiegokolwiek hasła. Nie trzeba pobierać i instalować żadnego oprogramowania. Google jest w stanie zmodyfikować swoje strony tak, żeby wszystko działało.

Google zaczęło już eksperymenty związane z nowymi sposobami na wyparcie hasła, jednym z nich jest mała karta kryptograficzna Yubico.

USB_token11

 

Źródło: Google

Autorzy artykułu zastanawiają się także nad innymi możliwościami: co jeśli taki sam efekt, jak przy pomocy tokena,można osiągnąć za pomocą NFC czy Bluetootha?

Można pomyśleć o integracji telefonów czy biżuterii, którą użytkownicy często i tak noszą ze sobą. Chcielibyśmy, aby wasz smartfon czy pierścionek z osadzoną kartą chipową umożliwiającą uwierzytelnienie za pomocą jednego tapnięcia, nawet w sytuacjach, w których telefon może pozostawać bez łączności z siecią.

Artykuł zostanie umieszczony w Internecie 28 stycznia w IEEE Security & Privacy Magazine. Warto przeczytać go w całości.

dodany: 28.12.2012 | tagi: , ,

SSO – ułatwienie czy przekleństwo?

4

Współczesne systemy operacyjne umożliwiają konfigurację wielu kont – profili użytkowników. Komputer przeciętnego śmiertelnika ma jednak skonfigurowane w systemie operacyjnym tylko jedno takie konto. Często włączone jest automatyczne logowanie na to konto po uruchomieniu systemu i nie myślimy o tym, że trzeba wpisać login i hasło. Wszystko po to, żeby można było rozpocząć używanie jak najszybciej i nie musieć pamiętać zbędnych danych (w końcu skoro sami korzystamy z komputera, to po co nam logowanie? :-))

Po uruchomieniu/wznowieniu systemu uruchamiamy aplikacje, otwieramy przeróżne strony internetowe i najczęściej pozwalamy przeglądarce zapamiętać dane logowania, żeby było szybciej, prościej i wygodniej. Całe szczęście większość usług czy aplikacji umożliwia zapamiętanie loginu i hasła albo nawet ich nie wymaga (z reguły dotyczy to programów instalowanych w systemie operacyjnym komputera). Zasada ta dotyczy komputerów prywatnych. Jak to wygląda w sprzęcie wykorzystywanym w pracy? Wielu z Was, pracujących w niedużych firmach, pewnie stwierdzi – „oczywiście wygląda tak samo, z tą różnicą że używam innych programów”. A jak ta sytuacja zmienia się w dużych firmach i korporacjach? Czy nadal jest to tak bezproblemowe?

Nie ma jednej odpowiedzi – wszystko zależy od infrastruktury IT w danej firmie, od wykorzystywanych aplikacji, systemów, polityki bezpieczeństwa i innych uwarunkowań. Może być tak, że korzysta się głównie z lokalnych programów, a systemy intranetowe są rzadko wykorzystywane. Może być odwrotnie – lokalne aplikacje są w mniejszości, a użytkownicy masowo muszą korzystać ze współdzielonych systemów lub portali intranetowych wymagających złożonych mechanizmów uwierzytelnienia i autoryzacji. Pierwszy wariant rzeczywiście mało różni się od użytku prywatnego. Drugi już wymaga dużo więcej zarówno od użytkowników, jak i działu IT w firmie.

Im więcej przeróżnych aplikacji i systemów dostępnych dla użytkowników, tym więcej może być odmiennych sposobów uzyskania uprawnionego dostępu do ich zasobów. Z reguły duże firmy i korporacje nie wykorzystują jednorodnych rozwiązań, a są one tworzone i dostarczane przez wielu dostawców na bazie rożnych technologii, a także mogą spełniać zupełnie rozbieżne oczekiwania poszczególnych działów organizacji. To powoduje, że nie jest łatwe (lub jest niemożliwe) opracowanie jednakowego sposobu logowania do wszystkich dostępnych systemów. Oczywiście, im więcej różnych systemów z odmiennymi metodami logowania, dopuszczalną składnią haseł, czy też częstotliwością wymuszenia zmiany hasła na nowe (co 30 dni, co 90 dni, a nawet wcale), tym więcej danych dostępowych do zapamiętania i tym większe ryzyko nieumyślnego ich ujawnienia, utraty, zapomnienia itd. Niektórzy użytkownicy w takiej sytuacji próbują sobie radzić z mnogością parametrów zapisywaniem wszystkich loginów i haseł na przysłowiowych żółtych karteczkach i dla ułatwienia trzymają je w pobliżu komputera. Jest to niewłaściwe zachowanie, ale jest wymuszone skomplikowaniem sposobów dostępu do aplikacji.

 

SSO jako kombajn do logowania

Jak poradzić sobie z takim zagmatwaniem dostępów i wdrożyć podejście ułatwiające życie użytkownikom? Nie zawsze można (i jest to bezpieczne) zrezygnować z wprowadzania danych dostępowych, a czasem spowodowałoby to jeszcze bardziej utrudnione korzystanie z systemów i aplikacji. Pomijając inne sposoby zmniejszania rygoru bezpieczeństwa, chciałbym szerzej wspomnieć o podejściu, które rozwiązuje wiele problemów opisanych powyżej, ale wymaga kompleksowej zmiany architektury i nie zawsze jest wykonalne w 100%. Rozwiązanie to zostało nazwane SSO – Single Sign-On („pojedyncze logowanie” lub też „jednokrotna rejestracja”) – czyli metoda uzyskiwania przez użytkowników dostępu do zasobów – aplikacji, systemów, które są odrębne i najczęściej mają różne mechanizmy logowania. Jest kilka rodzajów tego podejścia, ale chciałbym się skupić na jednym z nich wykorzystującym tickety do logowania. Jeżeli jesteście zainteresowani pozostałymi, zapraszam do Wikipedii, gdzie znajdziecie start do dalszych poszukiwań.

Rozwiązanie to polega na uruchomieniu centralnej usługi uwierzytelniającej (niektórzy zwą to „autentykacją” przenosząc zwrot wprost z języka angielskiego), która zostaje zintegrowana z najlepiej wszystkimi systemami, które są wykorzystywane. Użytkownik raz podaje login oraz hasło i dostaje się do każdej aplikacji zintegrowanej z SSO. Dzięki temu nie trzeba każdorazowo podawać najczęściej różnych loginów i haseł ani też pamiętać wielu kombinacji danych. W praktyce wygląda to tak, że po wejściu do aplikacji korzystającej z SSO użytkownik zostaje przekierowany do usługi uwierzytelniającej. Tam się loguje, a następnie zostaje mu przydzielony unikatowy identyfikator sesji (ticket), który następnie jest przekazywany do aplikacji. Na tej podstawie aplikacja jest w stanie stwierdzić, że osoba uzyskująca dostęp jest tym, za kogo się podaje, a także, że jej sesja nie wygasła i może być dopuszczona do zasobów systemu.

Powyższa ścieżka dostępu z wykorzystaniem tego podejścia może się wydawać prosta, jednak aby zadziałała, musi być przeprowadzona czasem trudna (lub nawet niemożliwa z różnych względów) integracja danego systemu czy aplikacji z usługą SSO. Usługa musi być świadoma istnienia systemu, do którego ma wpuszczać użytkowników, a dana aplikacja musi wiedzieć, że każde logowanie ma być uzgadniane z SSO. Trudność tu polega na tym, że w firmach często stosuje się naprawdę różnorakie rozwiązania i konieczność spięcia każdego z nich z osobna z centralną usługą może generować wysokie koszty i musi być mocno uzasadniona ekonomicznie. Pomimo oczywistej wygody rozwiązania może się okazać, że nakłady finansowe potrzebne na kompleksowe wdrożenie takiego rozwiązania są tak wysokie, że zarząd firmy lub dyrekcja działu IT nie podejmie się zmiany architektury. Dużo łatwiejsza jest integracja nowych planowanych i powstających aplikacji, które mogą już w założeniach przewidywać konieczność spięcia z SSO.

 

Zalety i wady stosowania w firmie

Pisząc o wygodzie użytkowników nie można zapomnieć o działach IT i wsparcia (Help Desk) – te grupy pracowników także dość mocno skorzystają z takiego rozwiązania. Nakład pracy konieczny na utrzymanie mechanizmów logowania jest dużo mniejszy, drastycznie spada liczba zgłoszeń użytkowników z prośbą o reset hasła, wygenerowanie nowego, pomoc przy dostępie do aplikacji itp. Obsługa interfejsów pomiędzy aplikacjami i usługą SSO można zautomatyzować, co nie wymaga wiele pracy już w trakcie utrzymania tych rozwiązań.

Trzeba pamiętać, że istnieje także zdecydowana wada takiego rozwiązania – jeden punkt dostępu do wszystkich możliwych (zintegrowanych) systemów i aplikacji – oznacza to, że potencjalny włamywacz musi pokonać tylko to jedyne zabezpieczenie, po czym ma dostęp do innych usług. Zadaniem poważnej usługi SSO jest oczywiście zapewnienie odpowiedniego poziomu bezpieczeństwa, ale jest to już większe wyzwanie i wymaga większej dbałości i monitoringu.

Nie chciałbym w tym artykule się odnosić do konkretnego rozwiązania SSO – istnieją zarówno komercyjne, jak i darmowe. Myślę, że najlepszym źródłem, z którego możecie zaczerpnąć sporo wiedzy na temat dostępnych opcji jest załączona tabela na Wikipedii – pomimo braku szczegółowych opisów z łatwością dotrzecie do szczegółów mając ten świetny zbiorczy materiał porównawczy.

To, czy wykorzystane może być rozwiązanie SSO płatne lub darmowe, zależy nie tylko od możliwości finansowych firmy – trzeba wziąć pod uwagę możliwości integracyjne, ograniczenia i współpracę z istniejącymi systemami i usługami. Może się okazać, że produkt komercyjny, kosztujący określoną kwotę, jest finalnie tańszy, niż pozornie darmowe rozwiązanie open source. Duży wpływ ma dostępna pula gotowych konektorów do rozwiązań, dzięki czemu nie ma konieczności ich tworzenia od podstaw. Wdrożenie SSO musi być poprzedzone analizą wszystkich rozwiązań, które mają być spięte, a dodatkowo testami. W zależności od firmy może się też okazać, że są kluczowe systemy, które są tak niesamowicie drogie w integracji z centralną usługą uwierzytelniającą, że nie będzie w ogóle fizycznej możliwości wdrożenia procesu logowania opisanego wcześniej.

W takiej sytuacji pomocne mogą być rozwiązania stosowane w dużych firmach i korporacjach, działające w nieco inny sposób niż powyższy. Nie wymagają integracji z systemami zastanymi, aplikacjami czy usługami, nie jest konieczne ich modyfikowanie i ponoszenie kosztów na dostosowanie do usługi SSO. Dla użytkownika są one dużo bardziej transparentne niż usługa wykorzystująca tickety i sprawiają wrażenie po wdrożeniu, jakby się prawie nic nie zmieniło – nadal używamy formularzy danej aplikacji czy usługi, nie ma osobnego i nowego ekranu logowania. W skrócie proces logowania działa następująco: użytkownik otwiera dany system czy aplikację, widzi formularz wprowadzania danych logowania, a w tym momencie rozwiązanie przechwytuje formularz i automatycznie wprowadza dane użytkownika, do którego należy jedynie zatwierdzenie ich i wejście do aplikacji. Rozwiązania takie wymagają utworzenia odpowiednich konfiguracji szablonów i definicji dla poszczególnych rozwiązań określających obsługę pól wprowadzania danych logowania. Oprócz automatycznego wprowadzania danych możliwa jest zmiana hasła po wygaśnięciu starego i wiele innych funkcji wymaganych przez procedury bezpieczeństwa w firmie.

W tym podejściu nie jest, co prawda, konieczna implementacja integracji z poszczególnymi systemami, ale trzeba skonfigurować samo rozwiązanie, aby wiedziało jak obsługiwać rozmaite formularze logowania w każdej usłudze i sposób działania może się wielu z Was wydawać nienaturalny – w końcu przechwytywanie wprowadzania danych przez użytkowników kojarzy się z keyloggerami i może sprawiać wrażenie rozwiązania „siłowego” a nie prawdziwej integracji. Takie systemy są jednak popularne z uwagi na właśnie brak ingerencji w istniejące usługi, które czasem zwyczajnie nie mogą być zmodyfikowane z uwagi na koszty lub fakt, że są mocno przestarzałe, ale nadal ważne i w użyciu.

Nie powinno raczej być problemu, aby zastosować łączone podejście – część systemów zintegrować z użyciem centralnej usługi uwierzytelnienia, część z wykorzystaniem innych sposobów zapewnienia jednokrotnego logowania. Wszystko zależy od aktualnej sytuacji i zastanych systemów – dlatego wspominałem o koniecznej analizie i testach – w ich trakcie można zidentyfikować najbardziej optymalne podejście. Z marszu można podjąć taką decyzję tylko w prostych sytuacjach i w małych firmach, gdzie jest niewiele systemów i z reguły od razu wiadomo, z czego warto skorzystać. Zachęcam jednak do poszukiwania nowych sposobów – jak wszystko w informatyce – także ta dziedzina zmienia się i trzeba być na bieżąco.

dodany: 06.10.2012 | tagi: , , ,

Spam kradnie token uwierzytelniania na Facebooku

0

Kilka dni po facebookowym spamie z Miley Cyrus w roli głównej, świat został zalany następnym. Nakłania on użytkowników do wprowadzenia tokena uwierzytelniającego. Sabari Selvan, z E hacking news, otrzymał dziś powiadomienie, że jeden z jego znajomych otagował go na jakimś zdjęciu. Po kliknięciu na powiadomienie ukazało się jego oczom zdjęcie z tytułem Zweryfikuj swoje konto na Facebooku na (i tu podany adres strony).

Oczywiście wiadomość okazała się podobna do wymienionej wyżej, ale zmienił się jej koncept. Zainteresowany tym, gdzie strona prowadzi dotarł o strony „50.0×11.0xcf?id=57421560”. URL go zaskoczył. Gdy go przekonwertował, otrzymał adres IP: 50.17.162.207.

Strona przekierowała go na stronę „ilovemyiphone.mobi/r” a później „facebook.com.cfbi.info”.

W końcu autor został poproszony o skopiowanie i wklejenie swojego tokena uwierzytelniania. Po jego podaniu otrzymał poniższą wiadomość:

 

Uważajcie na taki spam, bo łatwo można pozbyć się swojego cennego konta na „FB”.

dodany: 04.10.2012 | tagi: , , ,

Microsoft kupił PhoneFactor

0

Microsoft kupił za nieujawnioną kwotę PhoneFactor, dostawcę  opartego na telefonach, dwuskładnikowego uwierzytelniania.

Microsoft twierdzi, że zawarcie umowy z PhoneFactor jest formą pomocy firmie, która zapewnia szerszy zakres usług uwierzytelniania dla klientów Microsoft w chmurze, Technologia PhoneFactor może być także używana na produktach typu SharePoint, które również uruchamiane są na serwerze w domu.

PhoneFactor pracuje już z wieloma produktami Microsoftu, w tym Outlook Web Access and Internet Information Services, a także współpracuje z usługą Active Directory.

PhoneFactor zobowiązuje się nadal sprzedawać swoje istniejące produkty. Planuje także dalszą integrację z Microsoft Active Directory, Windows Azure Active Directory i Office 365.

Z FAQ firmy odnośnie przejęcia jej przez Microsoft czytamy:

Na razie będziemy sprzedawać rozwiązania PhoneFactor jako samodzielne usługi przy użyciu modelu wyceny PhoneFactor i dotychczasowych umów. Zamierzamy przenieść PhoneFactor na pokład Microsoftu i nadal sprzedawać jako osobny serwis dla naszych klientów korzystając z umów licencjonowania zbiorowego Microsoftu. Moment całkowitego przejścia nie jest jeszcze ustalony.

Obecna oferta PhoneFactor obejmuje uwierzytelnianie wtyczek i produktów dla IBM Tivoli, Citrix, PingFederate oraz m.in. VMware View.

Dodatkowo w ramach przejęcia dodano nowy akronim do rodziny Microsoft: MFA (multi-factor authentication). Mamy nadzieję, że będzie działać i nie zniknie po wchłonięciu przez firmę z doliny krzemowej.