Hasła maskowane ciąg dalszy

UWAGA, ruszył Humble Book Bundle: DevOps - jak zwykle pierwszy próg 5 książek od $1, cały komplet od $15.

Pod ostatnim artykułem dotyczącym wpadki jednego z polskich banków pojawił się komentarz:

Czy autor ma JAKIEKOLWIEK pojecia jak sa implementowane takie maski ?
Z technicznego punktu widzenia NIE SA TO LOSOWE maski, a “predefiniowane”. Czemu ? Bo haslo po stronie serwisu musi byc zaszyfrowane (a dokladnie zahaskowane – tak, ze nie da sie uzyskac wersji jawnej).
Najprostsza implementacja takiego podejscia to w momencie podania przez uzytkowanika nowego hasla wygenerowanie (i zapisanie w bazie dancyh) hasha dla hasel wszystkich mozliwych (zdedefiniowawnych w systemie) masek.
Czyli jak haslo to qwertyuiop, fynkcja skrotu to fs(‘xxxx’) i system ma 3 mozliwe maski (pozycje)
14689
23678
13579
to system zapisze w bazie danych:
fs(‘qryio’)
fs(‘weyui’)
fs(‘etuo’)

I dodanie kolejnej maski nie bedzie mozliwe (bo juz w systemie nie bedzie hasla w plan texcie)

Tak wiec kazdy taki system ma predefiniowane pare-parenascie masek i to wszystko. Beda sie powtarzaly, w pare logowan na 100% uda sie uzyskac 100% hasla.

W związku z tym postanowiłem przeprowadzić test, aby przekonać się czy faktycznie może być zastosowane takie rozwiązanie.
Przeprowadziłem 111 prób logowania do jednego z polskich banków w których posiadam ROR. Sposób przeprowadzenia testu – powiedzmy że manualnie 🙂

Wyniki

No to sprawdźmy (można sortować kilka kolumn naraz z użyciem klawisza SHIFT):

NR PRÓBYZnak 1Znak 2Znak 3Znak 4Znak 5POWTÓRZEŃ
12789131
225913161
310111215171
412515161
524910131
6561013151
713611151
845612151
92579141
108101113161
1117910121
12231114151
13191112161
14161416171
1547910131
1623910161
1746910171
1878910121
193567141
201369101
2126711131
22281416171
2358911121
241578161
2524614171
26281112151
2725614151
281379141
29461012131
3015711121
3146911131
321279111
3315810151
34471013161
35791213151
3624514171
37251012171
3834810111
39371015171
40691012161
41361012141
4212612161
4317914171
4446816171
4536710131
4634810161
47381012131
48231012151
4957812161
5012511121
5126813151
52141011161
5323711171
5423714171
551389101
562131415161
57161415171
581457171
59171116171
60371013161
6147912151
6236811161
633456141
6436814151
659131415171
66567891
67691213161
687111213161
6926811121
704121314151
711489161
722101215171
73235691
74891011131
7545910121
76691112171
77131015171
78481213151
79481112161
8015814171
8167910121
821357141
831257141
84571014161
8517815171
866101114161
8734515171
881569171
8956711171
9034612161
9178910161
9213914171
9314510141
94571114171
9513710151
9626712141
9747812151
9836815171
99371416171
10047910171
1015101112131
102124671
1031356151
1042789111
1053569171
1061458101
1073468101
10823710151
1095689131
110241114161
1111359101

Tutaj można również pobrać wyniki w arkuszu kalkulacyjnym.

Jak więc widać, podczas przeprowadzenia 111 prób logowania żadna z kombinacji maskowania nie powtórzyła się. Teoria o generowaniu kilkunastu masek podczas zapisu hasła użytkownika nie potwierdza się.

Sprawdźmy częstotliwość występowania kolejnych pozycji hasła:

wykres_czestotliwosc

Moje hasło liczy 17 znaków, podczas próby logowania wybierany jest zestaw pięciu znaków. Jest to kombinacja pięcioelementowa ze zbioru siedemnastoelementowego. A zatem wszystkich możliwości jest:

Ilość kombinacji maskowania

Zakładając posiadanie przez bank ok. 3 mln. klientów i chcący zapisać dla nich wszystkie kombinacje maskowanych znaków, należałoby przeznaczyć ponad 18 miliardów rekordów.

No to jak się implementuje hasła maskowane?

Nie znam technik wykorzystywanych w instytucjach tak bardzo wrażliwych na bezpieczeństwo danych jakimi są banki, jednak podejrzewam, że może to być HSM (Hardware security module). Czyli sprzętowe wsparcie.

Taki hardware mógłby przykładowo udostępniać dwie operacje:

  1. dodanie użytkownika (identyfikator, hasło)
  2. uwierzytelnienie użytkownika (identyfikator, znaki hasła i ich pozycje w haśle)

HSM jest odporne sprzętowo na działanie z zewnątrz mające na celu wydobycie informacji. W zasadzie sposób przechowywania danych przez urządzenie jest nieistotny, bo nie ma możliwości wydobycia ich na zewnątrz.

Zobaczcie

Cryptomathic.com, Product sheet.
Thales-esecurity

Podsumowanie

Dlatego podtrzymuję, że implementacja obsługi haseł maskowanych jest o niebo trudniejsza niż w przypadku standardowego rozwiązania, przy jednoczesnym znikomym zwiększeniu bezpieczeństwa i utrudnieniu operacji logowania użytkownikowi.

 

Autor: Georgia Weidman

ISBN: 978-83-283-0352-2

Format: , stron:

Data wydania:

Opis: Obroń Twój system — zaatakuj go! Chcesz sprawdzić, czy Twój system jest bezpieczny? Zaatakuj go! Najskuteczniej zrobisz to z wykorzystaniem testów penetracyjnych. W trakcie tych prób pentesterzy (osoby prowadzące testy penetracyjne) próbują wcielić się w rolę włamywacza i przełamać zabezpieczenia testowanego systemu. Jeż

Cena: 99.00zł

Autor: Peter Kim

ISBN: 978-83-283-0384-3

Format: , stron:

Data wydania:

Opis: Zweryfikuj bezpieczeństwo systemów informatycznych! Testy penetracyjne (pentesty) to najbardziej wiarygodny sposób zweryfikowania bezpieczeństwa systemów informatycznych. Specjaliści na zlecenie próbują włamać się do systemu. Stosują przy tym wyrafinowane techniki, z których prawdopodobnie skorzystaliby włamywacze. Pentester weryfik

Cena: 49.00zł

UWAGA, ruszył Humble Book Bundle: DevOps - jak zwykle pierwszy próg 5 książek od $1, cały komplet od $15.

To również może Cię zainteresować:

  • Wordpress i bezpieczeństwoWordPress i bezpieczeństwo Tę stronę renderuje WordPress. Nie da się tego ukryć - analizując źródła html, javascript czy style css szybko można to wywnioskować. Skoro tak łatwo zidentyfikować framework który został […]
  • Jak zabezpieczyć się przed iteracją przeglądania stron po ID?Jak zabezpieczyć się przed iteracją przeglądania stron po ID? Nierzadko w naszych systemach, czy zwykłych stronach internetowych stosujemy wyświetlanie zawartości na podstawie identyfikatora w postaci liczby naturalnej. Numerowi temu odpowiada id […]
  • Hasła maskowane – błędy implementacyjne polskiego bankuHasła maskowane – błędy implementacyjne polskiego banku Ten tydzień zapisze się w historii polskiego internetu i bankowości za sprawą włamania do jednego z polskich banków. Jak podaje Zaufana Trzecia Strona przebieg wydarzeń wyglądał […]
  • PHP i podobieństwo dwóch wyrazówPHP i podobieństwo dwóch wyrazów Trafiłem ostatnio na ciekawą sytuację. Blisko dziewięć lat temu napisałem system dla zarządzania awizacjami kierowców w magazynach dla największego w Polsce producenta wody. System do dziś […]
  • Wykonywanie kodu JavaScript w JavieWykonywanie kodu JavaScript w Javie Wraz z pojawieniem się Javy 8 został udostępniony nowy silnik JavaScriptowy dla JVM o nazwie Nashorn. Zastąpił on starszą implementację Rhino, dostępnego od Javy 6. JavaScriptowy silnik […]
  • Rozmowy kwalifikacyjneRozmowy kwalifikacyjne W tym tygodniu byłem na rozmowie kwalifikacyjnej w JCommerce SA. Generalnie nie szukam pracy, ale jeśli firma dzwoni do mnie bezpośrednio (bez pośredniczących head hunterów), lokalizacja […]

3 thoughts on “Hasła maskowane ciąg dalszy

  1. Jasne, że jest trudniejsza i ma znikome znaczenie dla bezpieczeństwa. Ale zdaje się, że jest zalecana jako jedna z metod i dlatego każdy (KAŻDY!) bank ją implementuje. Do tej rekomendacji powinien być przynajmniej dodany link do Twoich artykułów 😉

  2. zainteresowalem sie haslami maskowanymi ostanio.
    Zgodze sie z podsumowaniem, test tez ciekawy.
    Niemniej na dwoje babka wrozyla – patrzac na jeden z bankow i 2 rozne uslugi z niezaleznymi ID i passwd widze ze kombinacje powtarzaja sie czesto ostanie 5 prob zalogowania to 3 powtorzenia maski w jednej usludze i 2 w drugiej. No albo ja mam szczescie albo byc moze akurat ta oranizacja finansowa stosuje X wyrywkowych znakow do zahaszowania i tyle.

    Co do podsumowania – w poprzednim wpisie pokazales ze jednak wad jest wiecej niz pozytywow – szczegolnie jesli ktos odwali fuszerke podczas implementacji.
    Przyklad ograniczenie dlugosci hasla przy mniejszej ilosci znakow zazwyczaj bedzie to mniej prob zeby odkryc wszystkie znaki (np max 15 vs max 32)

    Haslo jak podaje kazda strona (nawet tak malo znaczaca jak forum o niczym stojace na jednym z popularnych skryptow) sa odpowiedzialnoscia uzytkownika. Mozna wyznaczyc pewne sugestie ale jesli ktos bedzie chcial miec haslo Maciek1988# to co mu zrobisz?
    Tylko edukacja!
    moim zdaniem dluzsze haslo jest na chlopski rozum bezpieczniejsze bo trudniej jest odgadnac caly ciag znakow, a takie haslo moze byc jednoczesnie latwe do zapamietania.
    Do tego algorytm szyfrujacy gdzie tworzymy hash i porownuje sie hashe a nie tekst.

    Ze juz nie wspolne o korpo bo to dopiero smiech na sali z ludzmi ktorzy maja hasla w stylu SlowoKluczowe17Q2 i zmieniaja tylko rok i kwartal, a hasla AD sluza do dostepu do wzystkich tresci (lub prawie wszystkich).

    Nowe technologie nowe zagrozenia.
    🙁
    ze sie powtorze – tylko edukacja!

  3. Czy ja wiem czy implementacja jest taka skomplikowana? Owszem zakładając, że każda z kombinacji masek będzie osobnym rekordem to przy kilku milionach kont powoduje znaczny rozrost bazy. Ale wystarczy, że zapisze się rekord o długości 4096 znaków przy założeniu maksymalnie 32 znaków w haśle (128*32=4096). Dodatkowo potrzebny jest drugi rekord z szumem. Szum powinien być dosyć długi i najlepiej aby wynosił x*31. Następnie do każdego ciągu o długości x-znaków doklejany jest jeden znak z hasła lub znak zastępczy i jest liczony skrót dla każdego takiego zestawu. Całość wystarczy skleić w jeden ciąg i sprawdzać jego fragmenty.

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *