GoldenLine
Zaloguj się
Jarosław Żabówka

Jarosław Żabówka Administrator
Bezpieczeństwa
Informacji (ABI).

Temat: SSO

Organizacja postanowiła rozwiązać problem zbyt dużej ilości haseł które muszą zapamiętać użytkownicy. Wdrażany będzie system jednokrotnego logowania (SSO) – po zalogowaniu się do systemu, system będzie automatycznie wpisywał nazwę użytkownika i hasło w poszczególnych aplikacjach. Użytkownik w ogóle nie będzie znał tych haseł - będą generowane przez system – będą długie i skomplikowane.

Oczywiście, jeżeli ktoś zaloguje się na konto użytkownika do systemu, będzie miał dostęp do wszystkich aplikacji, ale przy pewnej ilości aplikacji i haseł do zapamiętania, wydaje się, że jednak podnosi to bezpieczeństwo, a na pewno rozwiązuje problemy związane z zapamiętaniem haseł.

Rozporządzenie mówi jednak – „W przypadku gdy do uwierzytelniania użytkowników używa się hasła, jego zmiana następuje nie rzadziej niż co 30 dni.(...)”. Czy Państwa zdaniem, oznacza to, że również hasła wykorzystywane do logowania do aplikacji powinny być zmieniane co 30 dni?
(Oczywiście, zamiast hasła do systemu może być np. wykorzystana karta)

Pytanie ma drugie dno – bywają aplikacje, które np. uwierzytelniają się do bazy danych korzystając z zaszytego na stałe hasła. Użytkownicy i administratorzy, jeżeli w ogóle o tym wiedzą, to i tak nie mają możliwości ich zmiany... Czy Waszym zdaniem, takie hasła również powinny być zmieniane co 30 dni?
Link do wypowiedziLink
Piotr K.

Piotr K. Ochrona danych
osobowych,
Bezpieczeństwo
informacji, Inte...

Temat: SSO

Moim zdaniem (i tak też do tego podchodzę u klientów) hasło należy zmieniać w każdej aplikacji, w której przetwarzane są dane osobowe. Wynika to z definicji jaka jest zapisana w Ustawie tzn. "systemie informatycznym – rozumie się przez to zespół współpracujących ze sobą urządzeń, programów, procedur przetwarzania informacji i narzędzi programowych zastosowanych w celu przetwarzania danych"i dalej podążając za definicją hasła – rozumie się przez to ciąg znaków literowych, cyfrowych lub innych, znany jedynie osobie uprawnionej do pracy w systemie informatycznym.Piotr K. edytował(a) ten post dnia 23.07.12 o godzinie 14:39
Link do wypowiedziLink
Jarosław Żabówka

Jarosław Żabówka Administrator
Bezpieczeństwa
Informacji (ABI).

Temat: SSO

Tylko, że w tym wypadku, osoba uprawniona nie zna hasła. Czy w takim razie możemy w ogóle mówić o haśle w rozumieniu rozporządzenia (gdyby autor rozporządzenia podszedł od strony systemu i napisał "(...)umożliwiający dostęp do sytemu", byłoby inaczej)?

Ja się zgadzam, że takie, znane tylko systemowi "hasła" też powinny być zmieniane, ale czy na pewno obowiązują nas te same rygory co w wypadku hasła zmienianego przez użytkownika.
Link do wypowiedziLink
Leszek K.

Leszek K. Zarządzanie
bezpieczeństwem
informacji. Dane
osobowe.

Temat: SSO

Takie hasło, to hasło techniczne -- nie służy ono do uwierzytelniania użytkownika, ale do uwierzytelniania usługi, użytkownik natomiast uwierzytelnia sie w systemie SSO. Takie techniczne hasło powinno być "mocne" (ok. 14 lub więcej znaków ze wszystkich grup) i gdy takie będzie, to można sobie odpuścić jego zmianę lub zmieniać ale w dużych odstepach czasu.

Zauważmy, że wg rozporządzenia hasło — rozumie się przez to ciąg znaków literowych, cyfrowych lub innych, znany jedynie osobie uprawnionej do pracy w systemie informatycznym .

Zgadzam się, że zmiana wszystkich haseł co jakiś czas jest OK. Ale zmiana haseł technicznych co 30 dni, to byłoby... niepraktyczne. Ogólnie zmiana hasła co 30 dni, to zbyt czesto, ja bym ten czas wydłużył do 60 dni - co byłoby w miarę dobrym kompromisem między bezpieczeństwem a funkcjonalnością. A tam gdzie stosuje się blokowanie konta po kilku nieudanych próbach logowania - może nawet zrezygnowałbym całkiem z konieczności zmiany haseł. No ale cóż, dura lex sed lex.Leszek K. edytował(a) ten post dnia 23.07.12 o godzinie 16:19
Link do wypowiedziLink
Grzegorz Krzemiński

Grzegorz Krzemiński 600+ projektów w
bezpieczeństwie |
Trener | RODO | HSSE
|...

Temat: SSO

Leszku, są dwie szkoły. Standardowo - Otwocka i Falenicka ;-)))

Jedna mówi o długich i rzadko zmienianych, druga o krótszych a zmienianych częściej. Mimo wszystko ja jestem za krótszymi i częściej zmienianymi bo zabawki do brutforce mają jeden główny atrybut na którym wyliczana jest skuteczność łamania - czas.

Nie ma hasła nie do złamania, zasada jak przy danych osobowych. Przyjmuje się, że hasło jest nie do złamania jeśli nadmierny czas oraz koszty. Dlatego wprowadzane są okresowe zmiany, przy czym progiem wyliczenia nadmierności czasu jest czas do złamania brutforce podzielony na x (zależy jaka organizacja).

Co do problemu Jarka. Jarku, a jakby tak systemowo i nieco definicyjnie podejść? Np tak, że systemem informatycznym, zgodnie z definicja z 7 ust 2a UODO jest to wszystko co jest ze sobą połączone. A uwierzytelnienie jest traktowane jako powiązania między aplikacjami. Tym bardziej, że jak piszesz, użytkownik nie ma wpływu, leci automat, dlatego tym bardziej według mnie wygląda to na powiązania a nie uwierzytelnienie.

W takim podejściu użytkownik ma jedno hasło - do całości, żeby się zalogować do jednego systemu, złożonego z wielu aplikacji. I tu trzymamy się zasady, reszta - to już powiązania. Przy założeniu, że nie da się tych aplikacji samodzielnych odpalić (powiązań), jeśli nie będzie logowania usera na wejściu.
Link do wypowiedziLink
Piotr K.

Piotr K. Ochrona danych
osobowych,
Bezpieczeństwo
informacji, Inte...

Temat: SSO

Panie Leszku, problem w tym, że jak mamy trzymać sie literalnie definicji to w rozporządzeniu nie występuję definicja hasła technicznego. To o czym Pan pisze to już jedna z dobrych praktyk, choć zapewne można rozwinąć dyskusję co to są "duże odstępy czasu". Znam takie osoby, które robią bądź robiły to raz do roku, raz na 2 lata :).
Przychylam się do szkoły Grzegorza, częściej i krótsze hasła.
Swoją drogą jestem ciekaw, czy istnieje orzecznictwo, które odnosi się do tego problemu?
Link do wypowiedziLink
Leszek K.

Leszek K. Zarządzanie
bezpieczeństwem
informacji. Dane
osobowe.

Temat: SSO

Zmiana haseł do kont technicznych to zazwyczaj ryzykowna operacja - są to rozmaite usługi systemowe, skrypty, połączenia między bazami danych, etc. Im częstsze zmiany takich haseł, tym większe ryzyko przestoju dla organizacji. I im większa organizacja, tym więcej powiązań między systemami, wtedy to ryzyko jest jeszcze większe. Są takie branże (np. bankowa) w których każda minuta przerwy w funkcjonowaniu systemów informatycznych to spore i mierzalne pieniądze. Czy - nawet jeśli uznamy, że rozporządzenie obejmuje konta techniczne (a więc takie, na których osoby upoważnione nie pracują) - zgodność z rozporządzeniem jest warta takiego ryzyka?

Dla mnie to kolejny dowód na to, że rozporządzenie do ustawy o ochronie danych osobowych jest archaiczne i zupełnie nie pasuje do obecnych czasów i możliwości techniki. W IT każdy rok przynosi zmiany, a cóż dopiero kilka lat - a przecież rozporządzenie ma już prawie 8 lat :(
Link do wypowiedziLink
Grzegorz Krzemiński

Grzegorz Krzemiński 600+ projektów w
bezpieczeństwie |
Trener | RODO | HSSE
|...

Temat: SSO

Leszku... w grudniu śnieg pada ;-)))

My to chyba wszyscy wiemy. Jest to oczywista oczywistość. I poszedłbym dalej, UODO też wraz z innymi regulacjami nie nadąża.

Niemniej naprawdę, w tym przypadku technicznych bym nie ruszał, określając w Instrukcji, ze są to powiązania, a uwierzytelnienie nie jest związane z DO. DO - zgodnie ze wszystkim, logowanie do sieci/systemu na wejściu, reszta automatem, więc hasło do logowania do "pierwszej" aplikacji.

Nie wiem, jak to u was, ale pamiętam casus gdzie w firmie (też finanse) za hasło w rozumieniu rozporządzenia traktowane było to, które służyło do odpalenia aplikacji "dostępowej" - czyli tej technicznej, która otwierała resztę furtek.
Link do wypowiedziLink
Roman Janas

Roman Janas Tech. Sup. & Opr.
Supervisor, Amway
Polska Sp. z o.o.

Temat: SSO

Oj Panowie. Najpierw chcecie wszystko regulować paragrafem a następnie ułatwiać sobie życie.

Po pierwsze coś takiego jak hasło techniczne nie istnieje. Hasło jest zawsze ciągiem znaków powiązanym w danym systemie z konkretnym profilem. Czyli jeżeli już mówimy o czymś technicznym to profilu nie haśle. Co do zmiany to przychylam się do stanowiska, że dla profili technicznych haseł nie powinno się zmieniać ponieważ może to spowodować problemy techniczne głównie dla administratorów. Chociaż nie jest to bezpieczna i dobra praktyka pozwala jednak zachować pewien margines bezpieczeństwa. Osoba która "używa: profilu technicznego nie zna hasła ponieważ jest ono odczytywane bezpośrednio ze zbioru do którego nie ma dostępu.

Natomiast co do SSO. Rozwiązanie w teorii dobre. W praktyce w systemach heterogenicznych bardzo kłopotliwe. Dla osób zafascynowanych tym rozwiązaniem polecam test w postaci integracji przy tego typu systemie powiedzmy serwerów Microsoftu z usługami, IBM-owskiego AS/400, Lotus Notes (z tej samej stajni) i powiedzmy aplikacji webowej na serwerze Linux-owym. Dodam, że zadanie wcale nie teoretyczne lecz jak najzupełniej praktyczne.

Ponadto jest jeden problem. Zamiast wielopoziomowego uwierzytelniania użytkownika w systemie w wyniku zastosowania SSO dostajemy system jednopoziomowy. Czyli włamywacz zamiast łamać hasła do kolejnych systemów udostępnionych użytkownikowi musi złamać tylko jedno. To tak jak z zamkami w drzwiach. Łatwiej otworzyć u użytkownikowi i włamywaczowi te gdzie jest jeden czy więcej niż jeden zamek.

Co do problemu "długości". Problem nie jest do końca w długości lecz w częstotliwości zmian i ilości dopuszczalnych znaków. Jeżeli mamy hasło powiedzmy 5 znakowe zmieniane co 30 dni w którym możemy używać wszystkich liter alfabetu łącznie z narodowymi i znaków specjalnych to będzie ono silniejsze od hasła 8 znakowego zmienianego również co 30 dni ale umożliwiającego użycie wyłącznie dużych liter w standardzie ASCII bez znaków narodowych i specjalnych.

Oprócz kwestii długości, czasu i ilości znaków są jeszcze polityki zawartości haseł i socjotechnika. Także nie ryzykowałbym prostego formułowania reguł "życia" hasła.

A co do czasu życia hasła zgodnie z rozporządzaniem to zamiana co 30 dni (ciekawe czy stosują to pracownicy GIODO) nie jest najlepszym rozwiązaniem ponieważ niezależnie od stopnia skomplikowania polityki zmiany haseł kończy się to przysłowiową zmianą z 12345 na 23456. W końcu ludzie są tylko ludźmi.

Generalnie przychylam się do opinii że uodo i rozporządzenia trzeba zmodyfikować. Tylko muszą to być rzetelne modyfikacje a kierowanie się modą.
Link do wypowiedziLink
Jarosław Żabówka

Jarosław Żabówka Administrator
Bezpieczeństwa
Informacji (ABI).

Temat: SSO

Zgadza się, że po wdrożeniu sso uwierzytelnianie staje się „jednopoziomowe”. Dlatego ma to sens tam, gdzie ilość aplikacji jest na tyle duża, że użytkownicy zaczynają sabotować system, np. notując hasła. Inaczej mówiąc, gdy ryzyko związane ze złamaniem pojedynczego hasła będzie mniejsze, niż te wynikające ze zbyt dużej ilości haseł które pracownicy muszą zapamiętać.

Oczywiście, w tym konkretnym wypadku, system został najpierw przetestowany, w bezpłatnej wersji jednostanowiskowej.

W wypadku systemu sso, automatyczna zmiana haseł, również tych których użytkownik nie widzi, nie stanowi większego problemu. Trudniejsza może być zmiana haseł „technicznych” wykorzystywanych przez systemy. Uważam jednak, że nie powinno to być niebezpieczne dla systemu. To znaczy należy dążyć do tego, żeby było jasno udokumentowane, które hasła są gdzie wykorzystywane. Brak takiej dokumentacji, prędzej czy później źle się skończy. I nie musi to być atak hakera, a zwykła zmiana wersji systemu.

Trudniejsza jest sytuacja gdy takie hasło nie może być zmienione, bo np. jest narzucone przez dostawcę. A z tym mamy do czynienia na co dzień np. w wypadku aplikacji dostarczanych dla administracji publicznej – ministerstwo zamawia system, oczywiście każdy z użytkowników ma własne konto i hasło, ale aplikacja łączy się do bazy już tylko jedną kombinacją konto-hasło, taką samą we wszystkich urzędach.

Przy okazji – może ktoś ma jakieś poufne informacje, o jakiejś zmianie rozporządzenia? Czy będziemy musieli jakoś przeżyć do rozporządzenia unijnego?
Link do wypowiedziLink
Grzegorz Krzemiński

Grzegorz Krzemiński 600+ projektów w
bezpieczeństwie |
Trener | RODO | HSSE
|...

Temat: SSO

A może zamiast czekac, nieco popracować i zaproponować? Niejawne mają swoje, nawet z metodologią do ryzyka i zagrożeń. Może w tym kierunku?

Ja mogę ogarnąć zapisy integracji z innymi zakresami bezpieczeństwa, co wpływ na model oceny ryzyka i zagrożeń będzie miało. Ale to może juz kto inny?
Link do wypowiedziLink
Krzysztof W.

Krzysztof W. adiunkt, Uniwersytet
Wrocławski

Temat: SSO

A ja trochę z innej beczki - zmienianie haseł zależy od przyjętych przez ADO ustaleń formalnych poczynionych w polityce i instrukcji. Jeśli nie ma żadnych to może swobodnie uznawać, iż wystarczy zmiana jednego (będzie twierdził że ma jeden system informatyczny z wieloma funkcjonalnie wyspecjalizowanymi elementami programowo/sprzętowymi a definicja ustawowa może być jak najbardziej czytana jako wymagająca zmiany hasła dopuszczającego do systemu jako całości - giodo w tym zakresie nie zgłaszał nigdy większych obiekcji). Jeśli w opisie zbiorów strzelił sobie w stopę i zdefiniował nie tylko je ale i oficjalnie zastąpił jeden system informatyczny wieloma systemami to albo będzie zmieniał wszystkie hasła w tych "odrębnych" systemach albo zmieni politykę w tym zakresie ;)).
Link do wypowiedziLink
Piotr K.

Piotr K. Ochrona danych
osobowych,
Bezpieczeństwo
informacji, Inte...

Temat: SSO

Pytanie tylko czy jeżeli podejdziemy do tego problemu w ten sposób a nasz system informatyczny będzie składał się z różnych elementów (od różnych producentów) to jak do tego ustosunkuje się osoba przeprowadzająca potencjalną kontrolę i nie zakwestionuje takiego podejścia? Dlatego pytałem o istnienie orzecznictwa do tej problematyki.
Link do wypowiedziLink
Roman Janas

Roman Janas Tech. Sup. & Opr.
Supervisor, Amway
Polska Sp. z o.o.

Temat: SSO

Panie Jarku,

Ponieważ jest Pan specjalistą od ochrony to uznam pierwszą część Pana wypowiedzi jako żart.

Przede wszystkim stopniowanie ochrony nie zależy od ilości systemów a od stopnia poufności danych w nich zawartych. Ponadto system w pełni funkcjonalny, a takim jest system z wdrożonym sso, jest z definicji niebezpieczny. I jeszcze jedno. Sugestia Pana Piotra jest bardzo słuszna. Trochę to masło maślane ale system informatyczny firmy składa się ze wszystkich systemów w niej pracujących.

Co do zmiany haseł wewnątrz sso to owszem mogą być zmieniane ale psu to na budę ponieważ do wejścia do systemu potrzebne jest tylko i wyłącznie hasło użytkownika. Reszta z definicji działa z automatu.

Generalnie sso nie jest nową ideą. Ponad 15 lat temu to był topowy temat wszystkich marketingowców branży IT. O ile dobrze pamiętam najdalej zaszedł Novell. Rozwiązanie jednak się nie przyjęło z powodów różnych głównie technicznych i bezpieczeństwa a także zmiany mody. Choć kilka dużych firm wdrożył je dla części używanych przez siebie systemów.

Generalnie nie jestem przeciwnikiem zmniejszenia ilości koniecznych do zapamiętania haseł. Ale sso z punktu widzenia bezpieczeństwa jest najgorszym rozwiązaniem. Ale oczywiście dla systemów nie zawierających danych wymagających ochrony (choć trudno już takie znaleźć) jest to dobre narzędzie.

Natomiast wracając do haseł technicznych. Zapisywanie na "twardo" jakichkolwiek haseł w oprogramowaniu jest kardynalnym błędem zarówno z punktu widzenia bezpieczeństwa jaki i administracji czy samego programowania. Jeżeli już coś na "twardo" to tylko i jedynie nazwa profilu tak by administrator systemu mógł sam ustawić hasło do systemu czy aplikacji.
Link do wypowiedziLink
Jarosław Żabówka

Jarosław Żabówka Administrator
Bezpieczeństwa
Informacji (ABI).

Temat: SSO

Jeżeli nie damy użytkownikom odpowiednich narzędzi, to znajdą sposób żeby poradzić sobie z zapamiętywaniem haseł. Ktoś, kiedyś nazwał to „identity chaos”… Jak poradzi sobie, wracający z urlopu pracownik, który ma sobie przypomnieć ~10 haseł? Spojrzy do notatek? A może we wszystkich systemach ma takie samo, pracowicie zmieniane hasło? Nie jestem wielkim fanem sso. Uważam jednak, że w pewnych organizacjach, może być to system podnoszący bezpieczeństwo (również w sensie - dostępność).

Zgadzam się, że polityka haseł jest ważna. Jeżeli skonfigurujemy system w ten sposób, że w haśle wymagana jest cyfra i nie może być ona ostatnim znakiem – wycinamy zmieniane co 30 hasła typu: „Ania1”, „Ania2”, … I tu dla mnie jest również siłą sso – bo nawet jeżeli aplikacja nie pozwala nałożyć żadnych wymogów na hasło, nie pozwala wymusić jego okresowej zmiany, to ciągle możemy mieć mocne, jedyne hasło znane użytkownikowi.
Roman Janas:
Co do zmiany haseł wewnątrz sso to owszem mogą być zmieniane ale psu to na budę ponieważ do wejścia do systemu potrzebne jest tylko i wyłącznie hasło użytkownika. Reszta z definicji działa z automatu.
Nie zgadzam się. Hasła mogą być losowe – trudno o atak słownikowy, hasła mogą być długie – trudno będzie bruteforce. Ale już np. dla sniffowania zastosowanie sso niczego nie zmieni. Dlatego, moim zdaniem, warto również te hasła zmieniać. Jak często, to inna sprawa. Ale skoro i tak robi to program, to co nam zależy – niech zmienia codziennie ;)
Link do wypowiedziLink
Leszek K.

Leszek K. Zarządzanie
bezpieczeństwem
informacji. Dane
osobowe.

Temat: SSO

Nie widzę powodu, dla którego należałoby demonizować SSO. Wszak i tak ono w wielu organizacjach jest w sposób prawie że naturalny, a przez to niezauważalny. Wystarczy, że wewnątrz firmy jest AD, intranet oparty o IIS lub SharePoint i aplikacje uwierzytelniające się w AD.
Link do wypowiedziLink
Roman Janas

Roman Janas Tech. Sup. & Opr.
Supervisor, Amway
Polska Sp. z o.o.

Temat: SSO

Panowie,

Przede wszystkim nie demonizuję sso. Jak sam napisałem można to rozwiązanie stosować. Ale nie może być tak, że system obejmuje wszystkie systemy i aplikacje.

Pomijając już problemy techniczne to jest to po prostu niebezpieczne rozwiązanie. To tak jakbyśmy chcieli zamknąć skarbiec banku tym samy kluczem co drzwi do tegoż banku.

Jeżeli już posługujemy się przykładem AD to proszę zauważyć, że nawet w tym przypadku przewidziana jest możliwość wymuszania autentykacji zarówno do aplikacji jak i grup dokumentów czy tematów. Mało tego system sam wymusza dodatkową autentykacje w przypadku modyfikacji krytycznych z punktu widzenia bezpieczeństwa parametrów.

Dlatego sso owszem ale z rozwagą i nie do wszystkiego.

A co do automatyczne zmiany haseł w ramach sso to się nie zrozumieliśmy. Chodziło mi o to, że aby wejść do wszystkich systemów wystarczy jedynie złamać pierwsze hasło znane użytkownikowi i ma się otwarte drzwi do wszystkiego do czego sso daje dostęp. I wbrew pozorom jest to hasło najłatwiejsze do złamania. W czasie wolnym polecam książkę Kevina Mitnicka "Łamałem ludzi a nie hasła". To naprawdę dobra lektura pokazująca gdzie właściwie tkwi problem w zabezpieczeniach wszelkich systemów. Technika jest przewidywalna i da się zabezpieczyć, ludzie nie i bardzo łatwo wbrew pozorom wydobyć z nich informacje. I o tym zapatrzeni w coraz doskonalsze zabezpieczenia techniczne zapominamy.

Dlatego moim zdaniem użytkownika należy odpowiednio przeszkolić by był świadomy jakie mogą być skutki jego niefrasobliwości, wprowadzić narzędzia zapewniające przestrzeganie rozsądnej adekwatnej do wagi danych polityki haseł i wprowadzenia adekwatnych do wartości danych zabezpieczeń. A nie na siłę ułatwiać mu życie i zwalniać z konieczności myślenia co robi. Nie trzeba zabezpieczać silnym, często zmienianym hasłem zbiorów do których mają dostęp wszyscy pracownicy firmy. Ale już dane stanowiące tajemnice firmy dostępne dla wąskiego grona warte są i dodatkowego hasła i dodatkowych zabezpieczeń.

I jeszcze jedna uwaga. SSO zawsze administruje człowiek. A człowiek się myli. Czasami przypadkiem czasami nie. O tym też warto pamiętać. Jeżeli mamy zabezpieczenie wielopoziomowe to prawdopodobieństwo i pomyłki, i nie zauważenia błędu jest po prostu mniejsze minimum o 50% a to dużo.
Link do wypowiedziLink
Wojciech Marciniak

Wojciech Marciniak Dyrektor IT, PZM
Autotour Sp. z o.o.

Temat: SSO

Baaaardzo ciekawa dyskusja. Dzięki, koledzy. Moje opinie (częściowo inspirowane niektórymi postami):

1. Zabezpieczenie zawsze adekwatne do ryzyka.
2. Hasło użytkownika samo w sobie, z definicji, jest ogólnie słabym zabezpieczeniem. Z powodów natury psychologicznej. Tam gdzie największe ryzyka - tam karty, odciski fragmentów kończyn, skany źrenic i innych organów i takie tam, zamiast haseł.
3. SSO jest świetnym rozwiązaniem przy powiązanych informacjach, choć funkcjonalnie odrębnie zarządzanych (podobny zakres, zbliżone grono uprawnionych, porównywalne ryzyko, ale odrębne aplikacje). I SSO ma więc swoje granice.
4. Kompletnie bez znaczenia dla istoty działań zabezpieczających jest cała Instrukcja. Traktować ją należy wyłącznie jako element formalny i zupełnie rozdzielić te dwa cele: zgodność z przepisami i rzeczywista ochrona informacji. W obecnym stanie prawnym nie są zbieżne.
5. Każdy pomysł z SSO da się obronić przed Giodo, o ile treści w kwitach będą konsekwentne.
6. Nie ma "haseł technicznych". Hasło to coś pozostające pod kontrolą użytkownika. Wszelkie inne cuda to mogą być klucze, frazy zabezpieczające i inne wymyślne terminy. Ale na końcu zawsze jest człowiek, z hasłem, nad którym ma obowiązek zapanować. I trzeba mu to ułatwić. W pewnych (ale bardzo częstych i typowych) sytuacjach SSO jest bardzo dobrym instrumentem.
7. Liczba haseł do zapamiętania w pracy to pikuś w porównaniu z tym, co musimy pamiętać prywatnie (same PIN-y to już niezła jazda). Nawet jak ktoś ma skłonność to powielania tych kodów i haseł, nadzieje się prędzej czy później na oryginalny serwis, który czegoś tam nie dopuści albo coś narzuci (długość zakres znaków, itp.) Więc ludzie są coraz bardziej wytrenowani i można ciut więcej wymagać, jeśli chodzi o inwencję przy hasłach.
8. Bardzo silnie minimalizującym ryzyko rozwiązaniem jest wysoka częstotliwość wymuszonej zmiany hasła, wraz z długą historią haseł i zabezpieczeniem przed powtarzaniem. Przy SSO - jak znalazł. Gdyby LDAP/AD nie miały tej funkcjonalności, to by nie istniały.

Tu już pytanie: Czy ktoś spotkał się z algorytmem walidującym siłę hasła nie pod kątem liczby wielkich liter i średników przeplatanych gwiazdkami, ale odrzucania nagminnie wykorzystywanych elementów (frazy słownikowe, daty, imiona itp.) oraz zbyt dużej zbieżności loginu i hasła (że przypomnę słynne "admin/admin1")? Skoro silniki oparte o podobną analizę pracują "w przeciwnym kierunku" dla hackerów to może by je częściej wykorzystywać w służbie ODO?
Link do wypowiedziLink
Roman Janas

Roman Janas Tech. Sup. & Opr.
Supervisor, Amway
Polska Sp. z o.o.

Temat: SSO

To z czym się spotkałem osobiście to:

- brak możliwości użycia hasła takiego samego jak 32 poprzednio wpisane;
- brak możliwości wpisania hasła takiego samego jak nazwa profilu użytkownika;
- wymuszenie minimalnej ilości znaków w haśle i równocześnie w pewnym stopniu składni (ilość dużych liter, znaki specjalne, cyfry).

Jeżeli chodzi o sprawdzanie składni hasła pod względem zbieżności z nazwą profilu lub języka naturalnego to raczej jest z tym problem. Praktycznie by działało to poprawnie trzeba by ułożyć słownik dla minimum czterech języków obsługiwanych domyślnie przez standard ASCII - angielskiego, niemieckiego, francuskiego i hiszpańskiego. A to nie dość, że trudne to jeszcze baza całkiem spora. No cóż, jeszcze żaden super komputer nie dorównał mózgowi człowieka więc na takie rozwiązania trzeba poczekać. Choć namiastki tego istnieją.

Co do "dopasowania" SSO do wymagań GIODO to na papierze zrobić da się wszystko. Tylko chyba nie o to chodzi by system bezpieczeństwa od którego zależy funkcjonowanie naszej firmy był dziurawy jak ser szwajcarski tylko po to by go nazwać serem szwajcarskim a nie polskim.

Tak a pro po parę lat temu jedna z największych firm amerykańskich ogłosiła bankructwo pomimo posiadania audytów potwierdzających jej wiarygodność finansową. No cóż papier papierem a w kasie były pustki. Oczywiście tak samo jak kreatywną księgowość można mieć kreatywną ochronę ale po raz wtóry czy o to nam chodzi?
Link do wypowiedziLink
Marek Popiel

Marek Popiel ochroniarz danych

Temat: SSO

Jako początkujący ABI dotąd nie zabierałem głosu, ale problem poruszony w tym wątku jest dla mnie nie tylko frapujący, ale i żywotny, przynajmniej w tym sensie, że w firmie dla której od jakiegoś czasu pracuję, kiedyś zdrożono SSO z wykorzystaniem tokenów i teraz muszę się z tym zmagać.
W związku z tym pozwalam sobie reaktywować wątek i proszę o wyrozumiałość ;-)

Pomijając liczne zagadnienia, które już tu opisano, problem z SSO mam taki, że - przynajmniej w moim przypadku - nie jest on zintegrowany z aplikacjami do których system ma pamiętać hasła, w stopniu umożliwiającym maszynowe generowanie haseł do tycb aplikacji i zapamiętywanie ich przez tą aplikację bez udziału człowieka.

Weźmy jako przykład np. program Płatnik. SSO z którym się zmagam, nie potrafi samodzielnie zmienić hasła do Płatnika użytkownikowi X. Hasło to musi być znane użytkownikowi, żeby podał je SSO przy piewszym uruchomieniu Płatnika. Ew. żeby uniknąc ujawnianie tego hasła użytkownikowi robi to administrator. Hasło to po zapamiętaniu na tokenie użytkownika nigdy (sic!) nie jest zmieniane.

W związku z tym, mam 2 pytania.

1) Czy faktycznie znacie Państwo systemy SSO, które same zmieniają użytkownikom hasła do aplikacji i potrafią sobie poradzić w różnymi aplikacjami bez konieczności jakiejś intergracji? Jeżeli tak, to bedę wdzięczny za przykłady.

2) Czy rozwiązanie, w którym administrator (informatyk) konfiguruje token, po to, żeby użytkownik nie poznał hasła do aplikacji (np. do tego Płatnika) można uznać za w jakimś stopniu poprawne (przy założeniu, że w ogóle akceptujemy stosowanie SSO)?

Z góry dziękuję za dobre rady typu wyrzuć chłopie to SSO na śmietnik (nierealne) lub zwalniaj się z tej roboty czym prędzej (w tej chwili nie mogę sobie pozwolić na zmianę pracy).
Link do wypowiedziLink
« Wróć do tematów
Odpowiedz

Podobne tematy


Następna dyskusja:

Sharepoint + Documentum SSO




Wyślij zaproszenie do
Anuluj