12:10
25/11/2014

Nasz czytenik, został podczas logowania do pewnego banku, poproszony o wpisanie …jednego znaku swojego hasła. Kto go przebije (w dół)? :)

Hasło maskowane do jednego z banków

Hasło maskowane do jednego z banków

Przeczytaj także:

Ten wpis pochodzi z naszego linkbloga *ptr, dlatego nie widać go na głównej.
*ptr możesz czytać przez RSS albo przez sidebar po prawej stronie serwisu.

81 komentarzy

Dodaj komentarz
  1. Get in to the bank :)

  2. czy system prosząc o znak/znaki oznaczające kolejną pozycję w haśle jest dla użytkowników bezpieczny? Pomijając, że prawdopodobieństwo trafienia 4 znaków a nie przykładowo 20 jest większe, to w jaki sposób są przechowywane te hasła po stronie banku?

    • Pewnie hash każdego znaku z osobna + salt. Na przykład w ing prosi minimum o 5 znaków.
      Wydaje mi się, że ma to głownie chronić przed keyloggerami i innymi programami przechwytującymi to co piszemy albo zapisujemy w przeglądarce. Na moje jest to dobre rozwiązanie ale uciążliwe..

    • Do Patryk: Skoro robimy hash dla każdego znaku oddzielnie to obojętnie jak duże będzie salt to złamanie tego brute forcem to ułamki sekund.

    • No, musiałbyś teoretycznie znać jeszcze sól i metodę mieszania tych stringów, choć mając te dane, faktycznie wydaje się to dosyć proste do złamania.

    • Nie musi to być czysty SHA256, można zrobić jakąś wariację wyniku tego hasha

    • Też mi się tak wydaje Kuba. Chociaż nie zagłębiałem się tak w temat ;D

    • Sebastian, można, ale znając metodykę tworzenia tych hashy, jesteś w stanie to odwrócić i złamać, skoro hash jest tworzony z jednego (tajnego) znaku, przy założeniu, że resztę znasz. Wiadomo, że jest to sytuacja nadzwyczajna, że przejmujesz bazę danych autoryzacyjnych klientów banku i do tego algorytmy tworzenia kluczy, ale jest to potencjalnie niebezpieczne przy takim założeniu, dużo bardziej niż standardowe pomieszanie hasła z solą. Jedynym plusem według mnie jest zabezpieczenie przed takimi atakami jak powiedział Patryk, mianowicie przejęcie pełnego hasła przez keyloggera.

    • No uznalem tutaj że nie zna sie algorytmu tworzacego, jesli ktos jest w stanie wyciagnac kod zrodlowy z banku to cos tu jest nie tak

    • Jeżeli ktoś ma dostęp do kodu to poco łamać hasła ;D
      A odnosząc się jeszcze do pojęcia salt to wcale nie musi to być stały ciąg znaków. Może w tym wypadku składać się z: asd + index znaku * 50 + id usera + md5(nr konta * 10) + haslo itd. już tak wyolbrzymiając. Jeśli nie znamy sposoby generowania salt ani mieszania ciągów znaków to wydaję się ciężko do ‘rozkodowania’

    • Oczywiście, że każdy rekord powinien mieć swoją unikalną sól, a z przejęciem kodu to przykład trywialny, ale już parę osób, które tworzyło ten system zna metodykę tworzenia tych kluczy, więc o ile to nie jest jakoś mega skomplikowany proces, to w przypadku przejęcia danych najsłabszym ogniwem może okazać się człowiek i wtedy leży wszystko. Idąc tym tokiem, wciąż wydaje mi się, że nie jest to rozwiązanie bezpieczne.

    • Zapewne przy ustawianiu każdego hasła wybiera się losowo pewną ilość “podhaseł” i dla każdego podhasła generuje hasha. Dla każdeho hasła trzeba wiec zapamietać zestawy typu lista pozycji do wpisania (np znak 1 , 3, 7, 12) + hash z tych pozycji. Potem przy autoryzacji bierze się losowe podhasło do weryfikacji. Ot i cała tajemnica

    • Mariusz, czyli według Ciebie, baza danych powinna zawierać hashe z każdej, możliwej kombinacji z tych pól? Przy założeniu, że system losowo wybiera ilość znaków (na losowych pozycjach) z przedziału powiedzmy 4-20 (1234,1235,…,1234(…)181920) to przecież ilość kombinacji wynosi ponad milion. No chyba, że Cie źle zrozumiałem bo to rozwiązanie jest kompletnie bezsensowne. No chyba, że jest też przechowywana informacja o jakie kombinacje pól może pytać i ograniczyć to do jakichś 20 haseł (lub innej, sensownej ilości).

    • Załóżmy, że ograniczymy ilość kombinacji do 40 (losowo wybierając z tego miliona) to i tak ilość miejsca zajmowanego przez hashe będzie znikoma do możliwości takiej instytucji jaką jest bank :)

    • Prosta matematyka pokazuje, że jakąkolwiek efektywną metodę by nie zaproponować do przechowywania haseł, to mając wiedzę o algorytmach i kluczach używanych do zaciemnienia danych, na wyciągnięcie treści potrzeba ułamków sekund.
      Jednocześnie nie ma to znaczenia, bo jeżeli ktoś jest w stanie dostać się do systemu bankowego, pobrać bazę danych i podejrzeć sposób w jaki dekodowane są hasła, to poznanie przez niego dodatkowo treści tych haseł to najmniejszy problem :P.

    • ^Mam na myśli oczywiście sytuację, kiedy bank pyta “przez telefon” o kilka cyfr na określonych pozycjach z dłuższego hasła.

    • Qba, niekoniecznie, bo mając np. minimalne hasło o długości 8 znaków i mieszając je z solą otrzymujesz hash, który jest dosyć ciężki do złamania, nawet mając wiedzę o metodyce mieszania tych wartości przed zaszyfrowaniem i znając skrót hasła i sól. Co innego jak jest to tworzone z jednego (1~7) znak(u,ów), wtedy mając te dane jesteś w stanie zrobić to w dość rozsądnym czasie.

      Na przykład:
      $pass = ‘abcd’;
      $salt = ‘055ac953bbb3a6ee2ac50373bd5afc44fdf89f39ea46d93086fe97ecd4fd228e’;
      $secret = sha1($pass.$salt);

      Zakładamy, że znasz wartości salt i secret i wiesz, że długość zmiennej pass jest nie większa niż 7 oraz znasz metodykę tworzenia klucza. I zakładając, że znaki jakie można wykorzystać do hasła to mixaplha-numeric. Taki przypadek jest dosyć prosty do złamania.

      Zakładając, że zmienna pass jest długości większej lub równej 8, wtedy jest to już dużo bardziej czasochłonne.

      Poza tym, bardzo wątpię, że nawet system bankowy ma funkcje dekodowania tych haseł bo i po co.

    • Kuba,

      Ale mówimy o przypadku, kiedy system bankowy prosi klienta o podanie kilku znaków (zakładamy właśnie że mniej niż 7) z dłuższego hasła. Nie wiele można zrobić, żeby uniemożliwić komuś mającemu dostęp do bazy i znającemu algorytm weryfikacji oraz klucze, odtworzenie pierwotnej treści.
      Wydaje się, że jedyny sensowny sposób ochrony to właśnie przechowywanie kluczy w bezpieczny sposób – #comment-432537

  3. Tak, bardzo wierzę czytelnikowi…
    Może z konkurenkcji?

  4. …bo widocznie loguje się tam z tego komputera co chwile.
    To logowanie do Getinu i jest “intelignentne” – licbzę znaków do wpisania uzależnia od historii logowań na tej maszynie.

    • Ciekawe; być może dałoby się oszukać stronę, że obecny komputer jest tym najczęściej używanym.

  5. Ostatnio spotkałem się w banku Pekao właśnie z takim bzdurnym podejściem do hasła:
    1. Hasło może mieć max 16 znaków (sic!), ale wpisać w polu tworzenia hasła dało się więcej (sic!) i jeśli hasło było 2x dobrze wpisane, to zostało takie przyjmowane przez system (SIC!!!!).
    2. Przy logowaniu już tylko 16 okienek na literki (policzyłem te kratki dopiero, gdy hasło musiałem resetować telefonicznie, bo w ostatnią komórkę wpisywałem po prostu ostatnią literę hasła – a nie szesnastą, bo do głowy by mi nie przyszło, że moje hasło zostało cichaczem przycięte do 16 znaków).
    3. Podczas rozmowy telefonicznej wyraziłem swoje niepochlebne zdanie na temat takiego sposobu wpisywania hasła. Pani uparcie twierdziła, że to dla bezpieczeństwa, bo wirus i keylogger. Zająkneła się i po pauzie wyklepała formułkę, gdy powiedziałem jej, że:
    a) jak się ma tak posrany system wpisywania hasła, to połowa ludzi musi je sobie niemal na głos literować i wpisywać po literce – co łatwo podejrzeć
    b) BARDZO to zniechęca do tworzenia silnych haseł – krzaki z rożnymi znakami się jeszcze ciężej tak wpisuje
    c) jak im tak zależy na bezpieczeństwie, to po jaką cholerę ograniczają hasło do 16 znaków?!
    d) wirus/keylogger sobie podpatrzy kilka razy różne maski i i tak ma kompletne hasło, pfff…

    Po prostu szczęka mi opadła, jak zobaczyłem ten system bankowy i jeszcze potem usłyszałem ich małomądre wyjaśnienia, które były ewidentnie wyuczonymi formułkami, a więc ktoś z wyższego stołka lub działu bezpieczeństwa musiał je opracować.

    • Niczemu niewinna pani Grażynka w banku pojechana.

      Na pewno łatwiej podsłuchać całe hasło niż po kawałku. Mi się podoba ten pomysł z nie-wpisywaniem całego hasała, ale tylko 16 znaków to głupota.

    • @Meltdown – tylko teraz dochodzimy do takiego absurdu ze wszystrkie moje konta, wliczajac najwieksze pierdoly, sa chronione ~150bitowymi kluczami jak nie wyzej, a najslabsze haslo w calej wsi mam wlasnie w banku, bo logowanie sie przy pomocy Keepassowego makaronu wklepywanego recznie jest szczytem niepraktycznosci.

    • @Meltdown: do pani Grażynki nic nie mam, i tak ma ciężki kawałek chleba. Chodzi raczej o to, że ktoś taką bzdurę 1) wymyślił 2) próbuje usprawiedliwiać przygotowując konsultantom gotowe, naiwne, pseudo-techniczne formułki.

    • kolega też pewnie wychowany na Secret Service, gdzie łacińskie “sic” (dosłownie) często było traktowane jak angielskie “sick” (chore/obłędne). spoko, sam trochę tego nadużywałem, zanim wyhamowałem :)

    • To samo jest w mbanku.
      Wydaje się że długość pola hasła w formularzu ma się nijak do pola w bazie danych.. i leci obcina “końcówkę”

  6. Czekamy teraz na logowanie bez hasła ;)

  7. Jak oni śmieli napisać “Logowanie do bezpiecznej bankowości elektronicznej”?
    Przebić mogło by wpisanie samego loginu, ale takich cudów chyba jeszcze nigdzie niema.

  8. Ale to jest chyba ustawialne, w ustawieniach po zalogowaniu się?

    Czy nie?

  9. wszystkich którzy mają konta w ich systemach proszę o zgłoszenie tego jako błędu, zrobienie z igły widły, to najlepszy sposób, żeby ktoś tam raz jeszcze spojrzał na kwestie bezpieczeństwa

  10. Fake :)

  11. Czy wiecie może jak trzymane są te hasła w bazie danych?

    Hash całego hasła chyba nic nie da przy prośbie o wpisanie kilku znaków, trzymanie hashy wszystkich możliwości (2^20) jest kosztowne, a do tego ma taki sam sens jak trzymanie plain textu – w przypadku wypłynięcia bazy łatwo odhashować takie hasło.

  12. Właśnie sobie uświadomiłem, że jak hasło jest maskowane, to w bazie musi być przechowywane… otwartym tekstem! SIC!

    PS: AA, jednak nie, można zhashować i posolić każdy znak.

    • I co to by dało hash+posolenie?

    • Co był dał hash+solenie? To, że zamiast całego hasła w plaintextcie przechowywanego w jednej kolumnie bazy, masz tam przechowywaną np. tablicę hashy, z których możesz wyciągnąć bez problemu losowy, pojedynczy znak. Tym samym po wycieku bazy jest on teoretycznie bezpieczny. Dodatkowo bezpieczeństwa dodaje owa sól, która przecież może być różna dla znaków na poszczególnych pozycjach. Solenie uniemożliwia skorzystanie z tablic tęczowych.

    • A ile prób trzeba żeby znaleźć z jakiego znaku byłby hash nawet jakby był posolony?

  13. Niekoniecznie fake. Sam kiedyś miałem podobną sytuację w Aliorze, ale zdarzyło się to tylko raz. Pamiętam, że miałem niezłe WTF na ustach. Odświeżyłem stronę i odmaskowało już poprawnie, kilka znaków, więc pohamujcie od razu z tym fake’em.

  14. A czy jesteśmy pewni, że podał dobry identyfikator użytkownika?
    Spotkałem się z tym, że przy podaniu błędnego identyfikatora system pytał mnie o znaki z hasła, które po prostu nie istniały (np. z dalszych pozycji niż liczba znaków w haśle). W pierwszym formularzu wysyłany jest nr użytkownika, a dopiero po jego podaniu – system wysyła, których liter hasła potrzebuje. W tę stronę bym sprawdzał :).

    • Gratuluję :)
      Jako pierwszy rozwiązałeś zagadkę!

      Janusz w kategorii rozwiązywania fake’ów wędruje do Ciebie :)

      A reszta niech się daje spuszcza i snuje domysły.

    • Jeśli tak jest (niewykluczone), to pewnie dwustopniowość ułatwia walkę z webinject’ami. Przynajmniej część rozwiązań próbujących wykryć tego typu zagrożenia wymagała rozdzielenia podania loginu od hasła.

    • W bankowości jest taka zasada, że na zły (nie istniejący) login trzeba odpowiedzieć żądaniem o hasło. Oczywiście hasło to nie działa, ma to tylko zapobiec budowaniu sobie przez włamywaczy bazy poprawnych loginów. Dla tego też przy podaniu złego loginu nie wyświetla się komunikat “Błędny login”, zawsze wyświetli się hasło. Sprawdźcie sami. Oczywiście login musi mieć kilka znaków numerycznych – “dupa”, czy “1234” nie przejdzie).
      A w tym wypadku uznałbym to za fejk. Albo ktoś użył firebuga, albo photoshopa. System na pewno nie wyświetli tylko jednego pola na hasło.

    • @on:
      W żadnym dobrym systemie – nie tylko w bankowości, nawet na głupich systemach blogowych, w części publicznej (co najmniej) system nie ma prawa udzielić użytkownikowi informacji czy błędny jest login czy hasło.

  15. Jedyna edycja w gimpie to przycięcie.
    http://i.imgur.com/D1OVNNU.png
    Html inspector FTW. =]

  16. To że jak ktoś się dobierze do bazy to i tak nie pozna hasła.

    • Do samej bazy nie, ale jak dostanie się jeszcze do …

  17. Przecież można hashować całe zestawy znaków. Np. z hasła wyciągnąć ok 50 kombinacji znaków. Zahashować każdy zestaw (min. 8 znaków, hasło min. 14 znaków) osobno. Z jednym tylko znakiem to przesada, ale myślę że podany przeze mnie przykład powinien utrudnić używanie keylogerów bez proszenia się o bruteforce.

    • Alior wymaga np 5 liter z 12, założmy że jak wklepię hasło wygenerują sobie kilka hashów z kombinacji 5 znaków z hasła. Ile sekund trwałoby łamanie bruteforcem hasła z 5 znaków choćby były posolone?

    • Jeżeli bez soli to cholernie i nieopłacalnie długo :D

    • Poprawka: z solą

    • @ Marcin i inni, 5 znaków (+salt) zostanie złamane natychmiastowo. Nie wprowadzajcie ludzi błąd.

    • Jeśli zna się salt – a nie zawsze zapisywany jest on obok hasła (w bazie ;)

    • Lub jeżeli salt jest idiotycznie krótki, w przeciwnym razie będzie trwało to nieskończenie długo…

    • A takie techniczne pytanie, a gdzie i w jaki sposób miałby być trzymane informacje dla systemu z jakich kombinacji ma skorzystać w danej chwili w końcu musi wiedzieć co z czym porównywać? N+1 to raczej nie najlepszy pomysł :-)

    • Po prostu gdzieś musiałaby być informacja, że któryś hash zawiera w sobie literki 2,5,6,8,9 itd. Istnieje duże ryzyko, że pewnie literki powtórzyłby się zbyt często, co gorsza gdyby pewna na sztywno wygenerowana sekwencja zawierała identyczne litery, bo użytkownik ma w haśle np. 5 liter a. Oczywiście można to kontrolować, ale w sytuacjach stresowych dla dużej liczby generowanych haseł serwer mógłby obliczeniowo nie dać rady.

  18. Po nutce poproszę :)

    • haha :)) wybieram kategorię “polska bankowość” :)

    • Odpowiadam: The PussyCat Dolls – “Hush hush” :-)

  19. Można to zrobić symetrycznie (zaszyfrować hasła), tylko wtedy trzeba się zatroszczyć o klucze.

  20. Jakiś krawat zobaczył kiedy coś takiego i bez żadnego zastanowienia stwierdził, że też tak chce bo “bezpieczniej”.
    Tak to jest jak decyzje o bezpieczeństwie podejmuje ktoś kto o nim pojęcia nie ma, ale cóż na prince2 go uczyli, że biznes ma zawsze racje, a z programistami rozmawia się wyłącznie w trybie rozkazującym, no chyba, że ma się dobry humor to w oznajmiającym.

    Nawet sobie nie wyobrażacie jak mnie wkurza ten durny hype na maskowanie haseł.
    Jedyny plus tego jest w przypadkach pojedynczych logowań na danej maszynie.

  21. tiaaaaaaaaaaaa ;
    Zbadaj element -> Inspektor-> edytuj jako html -> PRTSC

  22. hashe, s**sze. Mnie zastanawia, kto normalny to wymyślił. 16 znaków, system prosi o kilka, losowych, jeżeli jest silne to trudne do zapamiętania dla przeciętych i mniej rozgarniętych. Ciekawi mnie ile osób zrobiło sobie karteczkę z hasłem i ponumerowanymi znakami i pewnie jeszcze trzyma razem z kodami jednorazowymi :)

    Kto komu chciał tak utrudnić życie?

  23. Ograniczenie długości hasła zawsze musi wystąpić jeśli hasło jest trzymane jawnym tekstem lub kodowane symetrycznie. W takim wypadku wystarczy wybrać rozsądną długość hasła, która zadowoli wszystkich.
    Hasła w bazie bez problemu moga być albo trzymane w postaci jawnej lub zakodowane symetrycznie. Jednak żeby to było bezpieczne trzeba dobrze to zaprojektować. Nic nie stoi na przeszkodze żeby zrobić coś w rodzaju czarnej skrzynki do autoryzacji, w której trzymane są tylko identyfikatory i hasła (zakodowane symetrzynie bądź jawnym tekstem). Taka czarna skrzynka powinna być dostępna (w wydzielonej sieci lokalnej / wirutalnej) tylko dla innych systemów, które potrzebują autoryzować użytkowników. Jej proste api pozwoli wykluczyć błędy w 99%. W przypadku kompormitacji właściwego systemu hasła użytkowników będą bezpieczne.
    Tyle teori, a w praktyce każdy wie jak to wygląda. Jednak twierdzenie, że hasła jawnym tekstem lub zakodowane symetrycznie to zawsze zło, jest błędne, bo da się to zrobić tak żeby było wystarczająco bezpieczne.

  24. Hasła maskowane w bankowości internetowej są przechowywane sprzętowo w tzw. HSM ( hardware-security-module ) i porównywane z zapytaniem otrzymanym od autoryzowanego serwera. HSM jest sprzętowo zabezpieczony ( zakodowany na sztywno klucz wraz z odpowiednim algorytmem szyfrującym ), na zewnątrz udostępnia API zawierające zazwyczaj dwie metody ( addData, verifyData ) zwracające odpowiednio T / F.

    np. 3 litery hasła maskowanego ( PT ) -> SSL -> Server -> HSM ( verifyData( id, [ 0a, 5x, 8u ] ) )
    (

  25. Phi…ja się loguję bez hasła :P

    • Niestety rozwiązane oparte o Shamir’a ma z góry ustaloną ilość maskowanych liter i nie może ona ulec zmianie. Oznacza to, że albo wszyscy użytkownicy mają taką samą ilość znaków do wpisania lub każdy użytkownik ma różną, ale zawsze stałą ilość znaków przypisaną do konta ( potencjalne słabe ogniwa ). Wzmocnienie takiego rozwiązania jest równe tradycyjnemu wpisywaniu całego hasła, z przewagą na rzecz drugiego ponieważ sam hash wymaga mniej obliczeń i pamięci.

    • Minimalną liczbę znaków. Nic nie stoi na przeszkodzie podawania większej, nadmiarowej ilości.

    • Przy nadmiarowej ilości znaków ( dodatkowych ignorowanych podczas logowania ) musisz trzymać w bazie dodatkowy rekord określający długość hasła użytkownika.

      np. 6 wymaganych znaków + nadmiar od 2 do 6 wymusza na użytkowniku hasło nie mniejsze niż 12 ponieważ mniejsze będzie równało się praktycznie całemu hasłu klienta. Dodatkowo 6 pozycji mus być we właściwym przedziale hasła ( więc musisz mieć zapisaną jego długość ) inaczej nie wygenerujesz klucza K’.

  26. Długie hasło można rozbić na sekcje i policzyć hashe tylko dla kombinacji w poszczególnych sekcjach. Np. ilość kombinacji 5-cio literowych dla hasła 15-sto literowego to 3003. Natomiast ilość kombinacji od 1 do 5 liter dla tekstu 5-cio literowego to zaledwie 30. Razy 3 (dzielimy haslo 15 na 3 bloki po 5 i trzymamy hashe wszystkich podzbiorow tych blokow) to 90. Wygląda o wiele lepiej.

    Pojawia się problem minimalnej ilości wymaganych do weryfikacji znaków – trzymanie hasha z pojedynczych znaków to bzdura, więc zakładając, że trzymamy tylko hashe 6 znaków i więcej, należy jeszcze pomyśleć o ile znaków pytamy.

    Idealne to to nie jest ale pokazuje jak w prosty sposób zejść o dwa rzędy wielkości :)

    • Teraz pomnóż to przez bazę zawierającą 10 mln klientów i załóż, że np. 1mln klientów zechce zmieniać swoje 16-32 znakowe hasła na nowe.

      PS.
      Nie wspominając już, że ograniczając liczbę kombinacji wymaganych znaków osłabiasz znacząco hasło. Każdy system jest tak bezpieczny jak jego najsłabsze ogniwo.

  27. Kilka osób słusznie zauważyło, że hasła maskowane są przechowywane w mniej bezpieczny sposób, niż niemaskowane (nie, nikt nie tworzy miliona hashy kombinacji podciągów, po prostu zakłada się że dostęp do bazy jest bezpieczny, tam są dużo ważniejsze informacje niż hasła).

    Znacznie więcej osób nie zrozumiało, dlaczego jest to mniej niebezpieczne (utrzymywanie w tajemnicy algorytmu nie jest metodą podnoszącą w istotny sposób bezpieczeństwo).

    Nikt nie zwrócił natomiast uwagi, że Getin/Openfinance (jako jedyny znany mi bank) pozwala na WYŁĄCZENIE logowania maskowanym hasłem – i wówczas nowe hasło może być normalnie (tzn. bezpiecznie) trzymane w formie salt+hash.

    A dlaczego tak jest? To proste – lepiej maskować hasło i odpowiedzialność za bezpieczeństwo jawnego tekstu wziąć na siebie (bank), niż mieć setki zahashowanych ‘jadzia69’, które i tak padłyby w pierwszym przebiegu crackera. A ryzyko, że pani Jadzia (oczywiście urodzona w 69) zostanie zaatakowana keyloggerem jest mniejsze, niż ryzyko wycieku bazy danych z hasłami z banku. I bardzo miło z ich strony, że secparanoikom udostępnili możliwość ustawienia sobie hasła generowanego metodą upuszczania kota.

    • Oczywiście zagrożenie zaatakowania keyloggerem jest większe, a nie mniejsze.

  28. Ale się uśmiałem. Hahahahah jaki mądralala.
    Jakbyś przeczytal to z zastanowieniem to pewnie byś tego posta nie przesłał. ..aż nie chce mi się odnosić do tych punktów ;-)

  29. W tym polu należy zalogować się wężykiem?

  30. :) Ciesze sie niezmienirnie, ze ktos zauwazyl, iz hasla maskowane psuja doskonale bezpieczenstwo wewnetrzne przechowywania hasla w systemie (w tym przypadku banku) ;)

    Tym, ktorzy namietnie ogrzewaja sie mysla, jak to haslo maskowane doskonale chroni przed keyloggerem przypomne, ze keylogger jest cierpliwy – moze poczekac ;D
    I polecam poczytanie analizy jak to doskonale ta ochrona wyglada:
    http://wampir.mroczna-zaloga.org/archives/235-o-haslach-maskowanych.html

    A wszystkim chcialbym zwrocic uwage, ze hasla maskowane sa pewna “modą”, ktora niestety dajac iluzje podniesienia bezpieczenstwa, tak naprawde je oslabia: pierwsze co zrobil po otrzymaniu od banku w prezencie ‘maskowanego’ zarowno moj tata, jak i znacznie od niego mlodszy brat, to zapisali sobie haslo ‘gdzies’, zeby latwiej potem te literki wybierac do tego pogiętego szablonu :D
    Tak – doskonale wiedza czym to grozi, ale uznali, ze inaczej haslo beda wprowadzac tak dlugo, ze nic z tego nie bedzie :)
    Tata nie uzywa banku poza domem i skupil sie na pilnowaniu miejsca zapisania, a brat przeniosl sie do innego banku, bo uznal, ze przypadkiem moge miec racje, ze to slaby pomysl zapisywac haslo gdziekolwiek :D

    • Jak się nie wie, czemu ma służyć hasło maskowane, to potem opowiada się takie głupoty. W myśl wszelkich regulaminów bankowych, itp. tylko właściciel konta może znać hasło do tegoż konta. Co za tym idzie, hasło maskowane ma chronić nie tylko przed keyloggerami (np. uruchomionym na niezaufanym komputerze lub jeszcze nie wykrytym na swoim przez antywirusa), ale również przed wścibskimi podglądaczami zza ramienia. Sam hasło powinieneś zmieniać co pewien okres czasu, w miarę często i na dosyć bezpieczne, no i oczywiście, nigdzie go nie zapisywać. Osobiście posiadam 10 znakowe hasło złożone z małych i dużych liter, cyfr oraz znaków specjalnych, zapamiętanie go nie jest trudne, bo jest to słowo, które da się wypowiedzieć… A że trzeba wpisywać konkretne literki i trzeba się nad tym zastanowić? No cóż, w zagadkach też nie dają od razu odpowiedzi, bo tak byłoby łatwiej i tutaj też nie powinno się iść na łatwiznę… Twój ojciec i brat najwidoczniej uznali, że są albo zbyt głupi, by zapamiętać hasło, albo zbyt leniwi… Wpisanie 4-8 znaków nawet z 16 znakowego hasła nie będzie trwało nawet pół minuty, tylko trzeba chcieć je zapamiętać, a nie iść na łatwiznę i zapisywać…

    • @Przemyslaw:
      > Jak się nie wie, czemu ma służyć hasło maskowane, to potem opowiada
      > się takie głupoty.

      Czyli mam rozumiec, ze zgadzasz sie, ze maskowanie hasla nie zabezpiecza przed keylogerami, i jednoczesnie postulujesz, ze poniewaz klienci maja tendencje, do wpisywania hasel w sposob ktory umozliwia ich podgladanie, to powinno sie poswiecic jakosc przechowywania hasla, oraz odpornosc na wkurzonego pracownika firmy przechowujacej hasla, na rzecz wzmocnienia w zakresie, w ktorym uzytkownik sam moglby chronic haslo? (przez nie wpisywanie hasla w miejscach narazonych na podgladanie, przez zasloniecie klawiatury w trakcie wpisywania hasla itp).
      Jednoczesnie obrazasz mojego tate – po prostu z racji wieku pamiec jest jaka jest, oraz brata, sugerujac ze …
      Tylko zauwaz, ze robisz cos takiego:
      – zabezpieczeniem przed podgladaczami obciazasz uzytkownika, zmuszajac go do lamiglowki,
      – wykluczasz mozliwosc, w ktorej ten sam uzytkownik, moglby zabezpieczyc sie przed tym sam, zaslaniajac na przyklad klawiature, co bylo by znacznie latwiejsze dla kazdego uzytkownika, lacznie z tymi, ktorych chcesz wykluczyc przez te pierwsza metode.

      czytales: http://wampir.mroczna-zaloga.org/archives/235-o-haslach-maskowanych.html
      ?

      > Osobiście posiadam 10 znakowe hasło złożone z małych i dużych liter, cyfr
      > oraz znaków specjalnych, zapamiętanie go nie jest trudne, bo jest to słowo,
      > które da się wypowiedzieć…

      Ciesze sie, ze masz taki zajebisty algorytm na haslo. Ja tez.

      Nie spodziewaj sie jednak, ze wszyscy tak maja – po prostu nie maja i projektujac system musisz sie z tym pogodzic.

      Mowisz o nie chodzeniu na latwizne? Zgoda: w jakosci hasla zgoda, w czasowym go zmienianiu – tak, ale tylko przez przekonanie usera, ze ma sens czasem zrobic taki manewr i ze czasem trzeba na wszelki wypadek, ale nigdy przez wymuszenie (klasyka korporacyjna: zbyt krotko ustawiony okres zmiany hasla skutkuje …. roznymi dziwnymi skutkami ubocznymi :D).

      Tak samo jak powinienes sie pogodzic z tym, ze wlsciciel systemu potencjalnie kiedys wkurzy jakiegos admina i bedzie go korcilo zeby wyniesc baze danych.

      Tak samo jak powinienes byc pewien tego, ze wiekszosc uzytkownikow bedzie miec latwe hasla – czy to znaczy, zeby wymuszac trudniejsze? chyba tak, ale czy ultratrudne i co okreslony czas? nie wiem, im dluzej to robie, tym mniejsza mam pewnosc, bo to zawsze jest wylewanie dzieci z kapiela.

      Tak samo mozesz byc pewien, ze znakomita wiekszosc posiadaczy dlugiego hasla, grzecznie wymyslonego zgodnie z fajnymi algorytmami, potrafiacych je odtworzyc bez zajaknienia mimo nie pamietania, zalamie sie, jak im kazesz wpisywac wybrane literki: obserwowalem to niejednokrotnie: wielokrotne zawracanie, sprawdzanie, powtarzanie – koszmar i meka.
      Nie latwiej przekonac do zaslaniania klawiatury podczas pisania, wymyslenia trudniejszego i dluzszego hasla, czy po prostu zrezygnowania z uzycia systemu w miejscach o watpliwej reputacji?
      Efekt ten sam, a nie utrudnia sie zycia uzytkownikowi – a to on jest na ogol w tym wszystkim najwazniejszy!

    • A gdzie ja napisałem, że nie chroni przed keyloggerami? Napisałem “nie tylko przed keyloggerami”, a to jest znacząca różnica… Poza tym, nie chciało mi się, w sposób tak dokładny jak Ty to robisz, opisywać wszystkich zależności. Ale odpowiem Ci na Twoje pytania.

      Niczego nie postulowałem, zauważyłem tylko pewne fakty. Ludzie nie dbają o swoje hasła i konta, więc trzeba robić to za nich, bo nikogo nie zmusisz do tego, by zaczął myśleć o tym, że może robić coś złego, a może nawet nie mieć do tego wiedzy. Dlatego wymyślane są różne systemy bezpieczeństwa, a nie ufamy ludziom na słowo…

      Nie pisałem również o żadnych poświęceniach, formularze do logowania się, mogą być dynamiczne, jeżeli ktoś chce mieć 32 znakowe hasło, proszę bardzo, kto komu broni, formularz może pokazać 32 pola z czego 6 będzie wymaganych do uzupełnienia – kwestia implementacji.

      Pamięć jest jaka jest, dlatego wymyśla się tak zwane mnemoniki. I naprawdę, da się wymyślić tak skomplikowane hasła, że niezgadnie ich nawet żona, a jednocześnie ich składowymi elementami będzie nasze codzienne życie.
      “Mam czwórkę dzieci i mieszkam w Warszawie” – M4d!mwW
      “Jestem żonaty, mam eleganckie auto, zarabiam 2 kafle i jest mi dobrze” – ]zM3a2@k!]Md
      Naprawdę, wystarczy poćwiczyć trochę i każdy się tego nauczy, a jak osoba jest naprawdę dużo starsza, to może ułożyć sobie zdanie i je zapisać w dozwolonym limicie znaków. 12 znaków? “Moja_babunia”. Jak dziadzio jest trochę sprytniejszy, to zastąpi “o” zerem, “i” jedynką i git. Ale nvm, każdy robi jak robi.

      Jestem programistą, ten podlinkowany wpis czytałem “wieki temu”, częściowo się z nim zgadzam, częściowo nie.

      Projektując system, muszę pamiętać o tych, którzy nie mają pamięci do haseł i dlatego wymyśla się różne wymogi, nie można oczywiście z nimi przesadzać (dobrym przykładem jest ustawa mówiąca o hasłach w firmach, gdzie trzeba je zmieniać właśnie co miesiąc i nie mogą się powtarzać w ciągu ostatnich 6 miesięcy), ale trzeba coś narzucić, bo inaczej ludzie poszliby na łatwiznę, bo taka jest natura człowieka. Ci mądrzejsi wiedzą, że aby coś zdobyć/mieć/nie_utracić trzeba się trochę napocić.

      Admin banku nie wyniesie sobie od tak bazy danych, ponieważ nie jest to takie proste jak wszyscy sobie wyobrażają. Raz, że to jest sektor finansowy, więc narzuconych jest od groma wymogów, dwa – bank chce dbać o swoje dane i swoich klientów, bo na nich zarabia. Hasła nie są przechowywane jak w skryptach PHP czy innych “bezpiecznych programach”, są do tego wykorzystywane specjalnie zaprojektowane systemy wraz z fizycznymi uządzeniami.

      Ja za to obserwuję na swojej osobie i moich znajomych, że nie mają problemów z wpisywaniem konkretnych znaków z trudnego hasła – tak, pytałem ich o to. Każdy z nich, który zadbał o bezpieczne hasło, nie narzeka na problemy z wpisywaniem. Jest wręcz odwrotnie – to ludzie z prostymi hasłami narzekają na problemy, bo muszą sobie literować lub zapisywać na karteczce – zwykłe, głupie i niewytłumaczalne lenistwo.

      Ludzie są jacy są i dlatego nie we wszystkich kwestiach powinno się ich słuchać. Dla ich własnego dobra czasami trzeba utrudniać im życie. W końcu życie to nie bajka, jak chcesz siedzieć na kasie, to musisz się pomęczyć, jak chcesz być pewien, że masz bezpieczne hasło – też musisz się pomęczyć…

      Na koniec, hasło maskowane może nie jest rozwiązaniem idealnym, ale jest rozwiązaniem dobrym, można byłoby to trochę ulepszyć i pozwolić na dłuższe hasła i byłoby prawie idealnie, bo z 32 znaków uzyskać całe hasło trochę by trwało, w końcu nie loguję się na konto codziennie… I tak btw. są jeszcze tokeny i sms-kody i z hasłem dają już dwie metody uwierzytelniania – coś co wiem i coś co mam.

    • No i teraz mozna rozmawiac: przynajmniej nie obrazasz mi taty i brata :)

      Tez programuje. Zawodowo. Ciesze sie, ze przynajmniej z czescia argumentow sie zgadzasz :)

      Co do zabezpieczenia przed keylogerami – haslo maskowane tego nie robi, daje tylko iluzje takiego zabezpieczenia: programik szpiegowski po prostu poczeka troche dluzej i tyle.
      Co do zapamietywania i literowania: fajnie, ze mozna z glowy jak sie ma wlasnie trudniejsze haslo.
      Ale:
      1. i tak trzeba cos tam sobie poprzeliczac w tej glowie zeby wpisac wybrane znaki z hasla, a nie cale. Jest to podatne na pomylki i jesli temu zaprzeczysz, to … chm, to dziwny jestes ;)
      2. jestes niekonsekwentny: mowisz, ze ludzie tak maja, wiec trzeba ich zmuszac, jednoczesnie dajesz im obietnice, ze dajesz im cos, co ich przed keylogerem zabezpieczy, nie sadzisz, ze wiekszosc z nich (tych zmuszonych), nie bedzie dzieki temu przypadkiem mniej uwazna? bo przeciez maja super duper haslo maskowane ? :)

      Ja w kazdym razie wole wpisywac nieskrepowanie cale dlugie haslo, nie zastanawiac sie ktore literki wybrac, nie przyzwyczajac sie do tego i nie dawac ludziom iluzji, ze maja zabezpieczenie przed keylogerem – bo sie rozleniwia i beda uwazac, ze nic im nie grozi.
      Lepiej dbac o nie zainstalowanie keylogera, zaslonic klawiature soba, reka, teczka itp, niz udawac, ze utrudnimy.
      Tym bardziej, ze niepodwazalne jeste tez to, ze na serwerze dzieki temu przechowywane jest slabiej. I bardzo Cie przepraszam, ale przy pomocy ustawy, ktora ogranicza cos tam w sektorze finansowym, to sie tego nie zabezpieczy :)

    • Nikogo nie obrażam, napisałem jak jest, nauczyć da się wszystkiego, więc problem z pamiętaniem haseł jest spowodowany albo przez lenistwo, albo przez bycie głupim (nie wliczam tutaj grupy osób chorych i mających problemy z pamięcią). A mogę założyć się, że Twojemu bratu nie chce się pamiętać hasła, a ojciec nawet nie próbował go zapamiętać, przy czym obaj pewnie zrezygnowaliby też z jakichkolwiek potwierdzeń przelewów kodem z smsa lub innych zabezpieczeń “bo to tylko utrudnia”. Znam ludzi, wiem jacy są i praktycznie każdy nie-informatyk ma problem z hasłami, bo się nie chce. Na taką łatwiznę idzie też masa ludzi związanych z informatyką, a nawet administratorzy i później dziwią się, że gdzieś był włam…

      Hasło maskowane chroni przed keyloggerami jak najbardziej. Z założenia i regulaminów, nie powinieneś logować się na niezaufanym komputerze. Co za tym idzie, jeżeli nie masz pewności, że komputer nie posiada keyloggera, to nie logujesz się na takim komputerze. Ponadto gdybyś dokładnie przeanalizował sposób w jaki działają hasła maskowane, to zauważyłbyś, że sam keylogger nie jest w stanie przechwycić całego hasła. Raz, że nie jest on inteligentny, przechwytuje klawisze jak leci i nie sprawdza co ktoś kiedyś wpisał (musiałby porównywać login i poprzednie hasło). Dwa – hasło maskowane nie zdradza pozycji wpisywanych znaków, pozycje można poznać tylko i wyłącznie po kodzie HTML, pola w formularzach są numerowane od 1 i bez przerw między znakami, więc jak masz wpisać 5 znaków, to masz pola od 1 do 5, a nie np. 2, 4, 5, 9, 11. Po trzecie – przy haśle maskowanym masz szansę, że nawet przy zarażeniu, przechwytujący nie zaloguje się za pierwszym podejściem. Musisz zalogować się przynajmniej kilkanaście razy, a atakujący musi ułożyć hasło w całość. Twój antywirus może przez ten czas rozpoznać keyloggera lub sam – ze zdrowego podejścia do bezpieczeństwa – zmienisz hasło jak co miesiąc i atak się nie powiedzie. Osobiście na konto loguję się z 5 razy w ciągu miesiąca. Oczywiście nie zmieniam hasła, nawet jak jest to na mnie wymuszane (jestem w tej kwestii leniwy i zmieniam na inne i zaraz z powrotem na poprzednie), ale stosuję inne środki bezpieczeństwa. Więc przy zmianie hasła co miesiąc lub nawet rzadziej (załóżmy, że robimy wszystkie opłaty jednego dnia lub maks. dwa dni w miesiącu – da się tak zrobić) atak nie będzie skuteczny.

      Gdybyśmy mieli zrezygnować z haseł maskowanych, to nigdzie poza domem nie chciałbym się logować na własne konto, pomimo posiadania drugiego zabezpieczenia w postaci tokenu. Każdy komputer znałby moje hasło, a to pół drogi do mojego konta. Za każdym razem musiałbym zmieniać hasła po powrocie do domu… Chciałbyś z tego zrezygnować? Obojętnie jak długie hasło miałbyś, byłoby bez sensu, bo gdziekolwiek byś go nie wpisywał, nawet na własnym komputerze, to już za pierwszym razem zostanie przejęte…

      Co do literowania i pomyłek – czy ta pomyłka sprawi, że Twoje hasło staje się mniej bezpieczne? Nie. Jedyne co powoduje pomyłka, to ponowną próbę logowania.
      Nie jestem niekonsekwentny. Zmuszam do stosowania bezpieczniejszych metod, ale nigdzie nie napisałem, że jakieś zabezpieczenie jest w 100% bezpieczne – w przeciwnym wypadku nie widziałbym sensu w stosowaniu dodatkowych zabezpieczeń. Dodatkowo same banki opisują zadanie hasła maskowanego jako “ma za zadanie w znaczącym stopniu podnieść bezpieczeństwo korzystania z systemów transakcyjnych.”, więc nikt tutaj nie pisze o 100% zabezpieczeniu. Trzeba rozumieć co się czyta, bo nigdzie nie napisałem, że hasło maskowane chroni (co by znaczyło, że w 100%), tylko że ma chronić (więc czasami może zawieść).

      Nie wiesz w jaki sposób hasła są przechowywane w bankach i nikt Ci tego nie zdradzi, bo jest to tajemnica. Ustawa nakazuje zapewnić odpowiedni poziom bezpieczeństwa danych, a nie reguluje w jaki konkretny sposób (“użyjcie md5 do hashy literek”) ma być to zrobione. Ma być zapewniony odpowiedni poziom. Jak taki poziom uzyskać? To też jest opisane. I uwierz mi, hasła te są lepiej przechowywane niż większość haseł przechowywanych w przeróżnych innych systemach. Jako przykład można podać w jaki sposób banki lub systemy transakcyjne przechowują swoje super wielkie liczby pierwsze stosowane do zabezpieczania transakcji internetowych (https://www.youtube.com/watch?v=usE0TwqPDME&t=1677 do 29:30). Nie każdy sektor i nie każda firma olewa ustawy i ich nakazy, bo wiąże się to z ogromnymi stratami albo całkowitym upadkiem instytucji. Słyszałeś kiedykolwiek o tym by z jakiegoś banku wyciekły hasła? Lub zostały złamane? Ja nie znam takiego przypadku, ewentualne “wycieki” haseł, to sprawka samych ich właścicieli, którzy nie dbają o bezpieczeństwo swoich kont. Za to nie jeden serwis miał problem z hasłami, które mogą być dowolnie długie i nie są maskowane, a szkody można wyrządzić o wiele większe, w końcu żeby utworzyć jakąś transakcję w banku potrzebujesz kodu (czy to z kartki, czy z smsa, czy tokenu), a na poczcie/serwisie społecznościowym/sklepie można zrobić niezły bajzel, nie wspominając o wycieku prywatnych danych (z poczty tym bardziej)… Czemu więc te serwisy, które nie posiadają haseł maskowanych i pozwalają na dowolnie długie hasła, są mniej bezpieczne niż serwisy bankowe z tymi ograniczonymi i maskowanymi hasłami, których tak bardzo nie lubisz? Czemu ofiarami ataków padają serwisy inne niż bankowe i czemu do serwisów bankowych trzeba stosować phishing, żeby mieć jakieś efekty, a do zwykłych serwisów wystarczy posiedzieć i znaleźć odpowiednią lukę pozwalającą wyciągnąć całą bazę?

      Jeżeli tego nie rozumiesz, to niestety, ale nic na to nie poradzę.

Twój komentarz

Zamieszczając komentarz akceptujesz regulamin dodawania komentarzy. Przez moderację nie przejdą: wycieczki osobiste, komentarze nie na temat, wulgaryzmy.