19:50
23/1/2024

Czy wiesz, jak niebezpieczna potrafi być funkcja przypominania hasła? Co prawda pozwala ona użytkownikom na dostanie się do serwisu w sytuacji, w której zapomnieli swoich danych dostępowych, ale jest też bardzo pomocna dla wszelkiej maści włamywaczy no i oczywiście testerów bezpieczeństwa aplikacji webowych. Zwłaszcza, jeśli zostanie zaimplementowana w nieodpowiedni sposób. W tym artykule przyjrzymy się najczęstszym wpadkom popełnianym przez programistów właśnie podczas implementacji mechanizmu przypominania hasła.

Zapraszamy do lektury kolejnego artykułu z serii “Poradnik Hackowania Webaplikacji“.

Aby nie przegapić kolejnych artykułów z tej serii, poświęconych błędom w serwisach internetowych i technikom testowania webaplikacji, zapisz się do naszego tematycznego newslettera — poza powiadomieniami o kolejnych artykułach otrzymasz od nas także dodatkowe przydatne materiały (linki, narzędzia i infografiki), które wysyłać będziemy tylko subskrybentom tego newslettera e-mailem (nie zostaną opublikowane na Niebezpieczniku).



Bez obaw, podanych e-maili nikomu nie przekazujemy i wykorzystamy je wyłącznie do przekazywania Ci treści związanych z cyberbezpieczeństwem. Jeśli lubisz czytać o RODO, kliknij tutaj.

Aby rozpocząć analizę tego, co może pójść źle, zacznijmy od rozpisania procesu przypominania hasła na etapy. Zazwyczaj wygląda on następująco:

  1. Aplikacja pyta użytkownika o maila
  2. Aplikacja wyświetla komunikat o wysłaniu maila
  3. Aplikacja wysyła maila z linkiem do zmiany hasła
  4. Użytkownik klika linka
  5. Użytkownik podaje dwukrotnie nowe hasło
  6. Aplikacja aktualizuje hasło użytkownika w bazie
  7. Użytkownik loguje się nowym hasłem do systemu

Każdy z tych etapów może posiadać błędy, które okażą się tragicznymi. Zacznijmy od bardzo częstego problemu:

Możliwość enumeracji kont użytkowników

Przy pomocy formularza “przypominania/resetowania” hasła spróbować sprawdzić, czy wybrany użytkownik posiada konto w danym serwisie. Nie postrzegasz tego jako zagrożenia? Nie jest niczym strasznym, że dowiesz się, o tym, że Twój sąsiad ma konto w popularnym sklepie? Wszystko zależy od kontekstu….

Być może informacja o posiadaniu konta na portalu w którym ma go miliony Polaków nie jest szczególnie wrażliwą informacją, ale jeśli uda nam się udowodnić, że wspomniany sąsiad posiada konto w jakimś mniej znanym i bardzo specyficznym serwisie, to może to być traktowane jako naruszenie prywatności. Wyobraźmy sobie, że mamy klinikę medyczną o nazwie “Radosny Medyk”, która specjalizuje się w leczeniu jednej, konkretnej dolegliwości, która do tego jest bardzo wstydliwa. Jeśli uda nam się potwierdzić, że nasz sąsiad posiada w tej klinice konto pacjenta, to w zasadzie dowiedzieliśmy się czegoś o jego problemach zdrowotnych a może nawet hulaszczym trybie życia.

Dlatego lepiej zabezpieczyć swój kod w taki sposób, aby przeprowadzenie wspomnianego ataku nie było możliwe. A żeby tzw. “enumeracja użytkowników” nie była możliwa, musimy zadbać o poprawne komunikaty z błędami przy resetowaniu hasła. Niedopuszczalne są komunikaty, które zdradzają istnienie lub brak istnienia konta w systemie, np.: “nie ma takiego konta”, “konto zablokowane”, “to konto nie zostało jeszcze aktywowane”. Komunikat zwracany przez funkcję przypominania hasła powinien być zawsze taki sam, niezależnie od tego, jaki status ma wybrane konto w systemie. Przykładowo, możemy poinformować użytkownika:

“Jeśli podany adres jest w naszej bazie, to otrzymasz od nas maila z linkiem do zmiany hasła”

Komunikat ten wyświetlamy dla kont zarówno istniejących, jak i nieistniejących.

Wariant z atakiem czasowym

Ale sama treść komunikatu, to nie wszystko. Może się zdarzyć, że atakujący wpisując istniejący adres mailowy widzi, że otrzymuje odpowiedź od backendu raz w 600ms, a raz szybciej, np. w 250ms. Wtedy mamy do czynienia z atakiem czasowym, który wynika z tego, że nasz algorytm może podążyć dwoma ścieżkami. Jedna droga to “jeśli użytkownik istnieje, wyślij maila i wyświetl komunikat”, a druga to “jeśli użytkownik nie istnieje, wyświetl komunikat”. Pierwsza z nich trwa dłużej, bo obejmuje zadanie wysyłki maila realizowane w tym samym wątku.

Aby pozbyć się tej podatności, najprościej będzie zaimplementować akcje asynchronicznie. W praktyce wygląda to tak, że adres mailowy podany przez użytkownika trafia (bez sprawdzania, czy istnieje, czy nie) na kolejkę adresów do przypomnienia, a zewnętrzny system (co pewien czas) sprawdza maile z kolejki i jeśli znajdzie tam adres istniejący w bazie użytkowników, to wysyła im linka do resetu hasła. Komunikat zaś pojawia się na front-endzie od razu.

Atak masowy

Może się zdarzyć, że atakujący oskryptuje nasz formularz przypominania hasła i przeprowadzi atak enumeracji kont na masową skalę, np. sprawdzając dziesiątki tysięcy adresów e-maili, niepotrzebnie obciążając nasze systemy i generując niepokój wśród użytkowników, którzy nagle otrzymają e-maile dotyczące resetu hasła, których się nie spodziewali. Ale i przed tym możemy się zabezpieczyć. Oto dwie metody, które powinny być zaimplementowane równocześnie.

Metoda pierwsza:

Zapisuj w bazie, kiedy (timestamp) wysłany był ostatni mail resetujący hasło dla danego konta oraz ile tych wiadomości wysłano. Jeśli atakujący użyje opcji przypominania hasła, prawdopodobnie zobaczy także linka w stylu “nie dostałeś maila? kliknij tutaj, aby wysłać go ponownie”. Link ten może być wywołany setki, czy nawet tysiące razy, powodując zaspamowanie ofiary wiadomościami z naszej aplikacji.

Trzymanie w bazie ostatniego znacznika czasowego kiedy wysłano maila pozwoli nam na implementację komunikatu mówiącego, że powtórne wysłanie wiadomości możliwe jest dopiero po np. 2 minutach od poprzedniej wiadomości. Ograniczy to problem spamowania, ale ktoś zdeterminowany wciąż może wysłać dziennie 1440 wiadomości (liczba minut w dobie) do nie jednego, użytkownika, a w najgorszym scenariuszu każdego z użytkowników!

Aby to ograniczyć, możemy dodać licznik wysyłanych wiadomości. Jego wartość powinna być zwiększana o 1 przy każdym wysłanym mailu do danego użytkownika (i resetowana po prawidłowej zmianie hasła). Jeśli licznik osiągnie wartość np. 5-10 (wybieramy w zależności od uznania), to na stronie możemy wyświetlić użytkownikowi komunikat:

“Liczba prób odzyskania hasła dla tego adresu została wyczerpana. Jeśli nie otrzymałeś żadnego z wiadomości, prosimy o kontakt mailowy lub telefoniczny z pomocą techniczną”

Ochronę pojedynczego konta przed spamem mamy załatwioną, ale co jeśli ktoś zacznie po kolei dla setek kont wykonywać funkcję, nawet z 2 minutowym opóźnieniem między “strzałami”? Tu z pomocą przyjdzie

Metoda druga:

Możemy zapisywać w bazie adres IP wraz z adresami mailowymi, dla których dany adres IP próbował zresetować dostęp. Jeśli zauważymy, że jeden adres IP odzyskuje hasła dla dziesiątek różnych kont, to nie jest to coś, co powinniśmy tolerować. Warto jednak pamietać, że za jednym IP może ukrywać się niekoniecznie jeden człowiek, a np. spora firma czy akademik. Blokada adresu może być więc kiepskim pomysłem. Lepiej narzucić limit (jak w metodzie pierwszej) dla konkretnego adresu IP, czyli sprawić, aby możliwe było np. uruchomienie procedury resetu hasła dla np. maksymalnie 2 kont w okresie 3 minut. To poważnie spowolni poczynania agresora, nie odcinając naszych użytkowników od funkcji resetu hasła.

Błedy w linku do resetu hasła

Czas na wysyłkę e-maila do użytkownika. Wewnątrz takiej wiadomości najczęściej znajduje się link z hashem do resetu hasła. Aby ten link był “bezpieczny”, musimy zadbać o kilka rzeczy.

  • Link powinien być losowy, co oznacza, że za każdym razem będzie inny (posolony hash z loginu, to naprawdę nie jest dobry pomysł)
  • Hash powinien mieć swoją datę ważności (np. 1 godzina) i być jednorazowy, aby po wycieku e-maili, np. miesiąc później, ktoś inny nie mógł wykorzystać tego linka do ponownej zmiany hasła

Kolejna warstwa ochrony?

Na dalszym etapie, użytkownik klika linka z wiadomości, ustawia nowe hasło i gotowe. Tylko skąd wiadomo, że osoba klikająca, to prawowity właściciel konta? Istnieje szansa, że agresor czyta pocztę ofiary lub wyłudził od niej linka do zmiany hasła np. w trakcie ataku phishingowego. Jak zweryfikować tożsamość klikającego? Możemy zrobić to na dwa sposoby.

A. Pytanie o login

Jeśli do Twojej aplikacji użytkownik loguje się czymś innym niż mailem, czyli np. ma nadany losowy i niepowtarzalny identyfikator użytkownika, to możesz o niego zapytać podczas zmiany hasła. Zadajesz więc użytkownikowi pytanie: “Dla jakiego loginu chcesz przeprowadzić zmianę hasła?”. Atakujący może tam wpisać co zechce, ale mechanizm po stronie serwisu WWW powinien zareagować jedynie, gdy wpisany ID użytkownika będzie poprawny. Musimy tutaj oczywiście limitować liczbę nieudanych prób i np. po trzech niepoprawnych identyfikacjach unieważnić linka.

B. Pytania bezpieczeństwa

Jeśli podczas zakładania konta prosiłeś użytkownika o wybranie lub ustalenie pytań pomocniczych (nazwisko panieńskie matki, nazwisko przyjaciela z podstawówki, itp.) to teraz masz szansę o to zapytać. Podobnie jak w przypadku poprzedniej metody, tak i tutaj musimy zaimplementować limit prób wypełnienia formularza, ponieważ atakujący może próbować zastosować atak siłowy na pole z odpowiedzią. Sprawdzenie wszystkich możliwości dla pytania “Twój ulubionych kolor?” nie jest trudne, szczególnie gdy mamy do czynienia z przeciętnym mężczyzną, który umie ich nazwać osiem.

Czy chcesz wylogować wszystkie swoje sesje?

Załóżmy, że hasło zostało zmienione. To nie koniec potencjalnych problemów. Warto zadać sobie pytanie, dlaczego użytkownik skorzystał z funkcji przypominania hasła? Oczywiście, najprostsza odpowiedź brzmi “bo zapomniał hasła”, ale istnieje jeszcze drugi przypadek. Co jeśli ktoś przejął konto użytkownika i właśnie prawowity właściciel walczy o jego odzyskanie, a włamywacz dalej jest na to konto stale zalogowany?

Po zmianie hasła powinniśmy zapytać użytkownika, czy życzy sobie, aby unieważnić wszelkie zalogowane na jego konto sesje. Jeśli właściciel konta odpowie twierdząco, włamywacz straci sesję.

Czas się zalogować

Zmieniliśmy hasło, pozbyliśmy się zalogowanego atakującego, więc czas, aby użytkownik zalogował się na konto i znów spokojnie z niego korzystał. Wielu programistów decyduje się, aby nie utrudniać życia użytkownikowi i po ustawieniu hasła po prostu zalogować go na konto. Brzmi to bardzo rozsądnie, ale może doprowadzić do powstania nowej luki.

Najbezpieczniejszym rozwiązaniem będzie przekierowanie użytkownika na klasyczny panel logowania, aby nie tworzyć oddzielnego mechanizmu uwierzytelniania dla sytuacji po resecie hasła. Każdy nowy mechanizm wejścia do systemu musi być odpowiednio zabezpieczany, testowany i uaktualniany. W skrajnym przypadku może zdarzyć się, że klasyczne okno logowania będzie miało inny profil bezpieczeństwa niż procedura logowania po resecie hasła, ponieważ programiści zapomnieli zaktualizować drugą ze ścieżek. Nie mnóżmy dróg wejścia do systemu – pozostawmy jedną.

Poinformuj użytkownika o zmianie hasła!

Do zamknięcia całego procesu brakuje nam już tylko jednego kroku. Poinformowania użytkownika o fakcie zmiany hasła. Można zadać pytanie, “ale w jakim celu? Przecież użytkownik chyba wie, co przed chwilą zrobił?”. Ale czy mamy pewność, że cała procedura została faktycznie wykonana przez użytkownika? Warto wysłać na adres mailowy przypisany do konta (i ewentualnie wszystkie pozostałe kanały komunikacji, jeśli takie są dostępne) informację o zmianie hasła.

Jeśli użytkownik nie wykonał tej operacji samodzielnie, a został zaatakowany, to będzie miał jeszcze szansę skontaktować się z pomocą techniczną aplikacji i zatrzymać kolejne akcje na swoim koncie.

Podsumowanie

W tym artykule omówiłem jeden – mogłoby się wydawać, prosty – mechanizm dostępny w aplikacji webowej. Temat nie został całkowicie wyczerpany, bo można tu jeszcze poruszyć np. kwestię wstrzykiwania nagłówków e-mailowych i przejmowanie wiadomości z linkiem do resetu hasła. Ale to może zostawmy na kolejne odcinki cyklu Poradnika Hackowania Webaplikacji, albo na wiadomość tylko dla subskrybentów naszego technicznego newslettera poświęconemu bezpieczeństwu webaplikacji (wink, wink ;) na który możesz się zapisać poniżej:



Bez obaw, podanych e-maili nikomu nie przekazujemy i wykorzystamy je wyłącznie do przekazywania Ci treści związanych z cyberbezpieczeństwem. Jeśli lubisz czytać o RODO, kliknij tutaj.

Na przykładzie tylko tego jednego mechanizmu resetu hasła widać ile pomyłek może zaliczyć osoba implementująca lub projektującą taki system. A “standardowych” mechanizmów w typowej aplikacji mamy znacznie więcej i przy każdym czają się kolejne pułapki. Jeśli chcesz je wszystkie poznać i podnieść bezpieczeństwo swoich serwisów internetowych, to zapraszamy do udziału w naszym szkoleniu z Atakowania i Ochrony Aplikacji Webowych — w trakcie szkolenia większość czasu spędzamy przed labami, w ramach których nauczymy Cię jak wykrywać błędy bezpieczeństwa w webaplikacjach i jak najsensowniej je usuwać. Oto najbliższe terminy tego szkolenia:

Poznań: 12-13 czerwca 2024r. — UWAGA: zostało tylko 1 wolne miejsce
Ostatnio ktoś zarejestrował się 20 maja 2024r. → zarejestruj się na to szkolenie

    2399 PLN netto (do 4 czerwca)
    2699 PLN netto (od 5 czerwca)

Gdańsk: 17-18 czerwca 2024r. — UWAGA: zostały tylko 4 wolne miejsca
Ostatnio ktoś zarejestrował się 22 kwietnia 2024r. → zarejestruj się na to szkolenie

    2399 PLN netto (do 7 czerwca)
    2699 PLN netto (od 8 czerwca)

Kraków: 15-16 lipca 2024r. — zostało 7 wolnych miejsc
Ostatnio ktoś zarejestrował się 23 maja 2024r. → zarejestruj się na to szkolenie

    2399 PLN netto (do 7 czerwca)
    2699 PLN netto (od 8 czerwca)

ZDALNIE: 23-24 lipca 2024r. — zostało 9 wolnych miejsc
Ostatnio ktoś zarejestrował się 17 kwietnia 2024r. → zarejestruj się na to szkolenie

    2399 PLN netto (do 7 czerwca)
    2699 PLN netto (od 8 czerwca)

Warszawa: 19-20 sierpnia 2024r. — zostało 9 wolnych miejsc
Ostatnio ktoś zarejestrował się 06 marca 2024r. → zarejestruj się na to szkolenie

    2399 PLN netto (do 14 czerwca)
    2699 PLN netto (od 15 czerwca)

Wrocław: 09-10 września 2024r. — zostało 9 wolnych miejsc
Ostatnio ktoś zarejestrował się 27 maja 2024r. → zarejestruj się na to szkolenie

    2399 PLN netto (do 14 czerwca)
    2699 PLN netto (od 15 czerwca)

Dowiedz się, jak zabezpieczyć swoje dane i pieniądze przed cyberprzestępcami. Wpadnij na nasz kultowy ~3 godzinny wykład pt. "Jak nie dać się zhackować?" i poznaj kilkadziesiąt praktycznych i przede wszystkim prostych do zastosowania porad, które skutecznie podniosą Twoje bezpieczeństwo i pomogą ochronić przed atakami Twoich najbliższych. Uczestnicy tego wykładu oceniają go na: 9,34/10!

Na ten wykład powinien przyjść każdy, kto korzysta z internetu na smartfonie lub komputerze, prywatnie albo służbowo. Wykład prowadzimy prostym językiem, wiec zrozumie go każdy, także osoby spoza branży IT. Dlatego na wykład możesz spokojnie przyjść ze swoimi rodzicami lub mniej technicznymih znajomych. W najbliższych tygodniach będziemy w poniższych miastach:

Zobacz pełen opis wykładu klikając tutaj lub kup bilet na wykład klikając tu.

38 komentarzy

Dodaj komentarz
  1. Błagam. Strona może błędy wyłącznie mieć, nigdy posiadać.

  2. A weźcie – nieraz przypominam sobie hasło do strony, na której nie pamiętam czy mam konto, a jeśli mam, to na którym z wielu maili. Wtedy taka informacja o resecie hasła/braku konta jest bardzo pomocna (wiem, mogę sprawdzić mail, ale jeśli reset hasła nie przychodzi to nie wiem, czy zawiódł system czy po prostu nie mam tam konta).
    Często też nie pamiętam nicku i przypominam go sobie dopiero po zalogowaniu się do systemu już po odzyskaniu hasła.

    • Dlatego właśnie warto korzystać z managerów haseł :-)

    • Dlatego należy zawsze wysłać e-mail na podany adres i w tym e-mailu napisać, że próbowano zresetować hasło, ale konta powiązanego z tym adresem nie ma (czy co tam innego chcemy napisać).

    • Opcja przypomnienia loginu? Lecz wymaga ona podania oprócz adresu email imienia nazwiska miesiąca i roku urodzenia. I konieczność potwierdzenia z maila. I większy delay.

    • Jeśli serwis przy resecie hasła nie podaje konkretnego info – to próbuje się założyć nowe konto, tam zwykle już tacy cwani nie są i jasno podają, że e-mail zajęty.

  3. Mogliście wspomnieć o ostatnim błędzie z bodajże gitlaba, gdzie dało się podać dwa maile w formularzu (poprawny i dowolny) a link do resetu szedł na oba ;)

  4. Mogliście jeszcze wspomnieć o niedawnym błędzie (bodajże w gitlabie) gdzie w formularzu można było podać dwa maile – poprawny i dowolny – a link do resetu hasła szedł na oba ;)

  5. To teraz artykuł dlaczego należy weryfikować mail, na który rejestrowane jest konto, bo wiele dzbanów z różnych instytucji i sklepików tego nie oharnia.

    • O, to, to! Zakładałem parę lat temu żonie konto Spotify i dowiedziałem się że na ten mail konto już istnieje. Zgłupiałem trochę – “a może kiedyś sama założyła i nie pamięta” – więc użyłem opcji odzyskania hasła. No i okazało się że to konto jakiegoś czarnego z USA, który słucha podcastów jakichś gangusów :D Szybka wymiana maili z supportem i usunęli konto, pozwalając na czysto założyć nowe. Nie wiem jak jest teraz, ale wtedy zasugerowałem im weryfikację maili.

  6. “szczególnie gdy mamy do czynienia z przeciętnym mężczyzną, który umie ich nazwać osiem.”
    Osiem?! A jaki niby jest ten ósmy?

    • Jak to jaki? Oktaryna.

    • burgundowy xd

    • amarantowy, chabrowy, eozyna, feldgrau, fuksja, grynszpan, kardynalski, lapis-lazuli, masz 8 więcej nie znam :D

    • A gdzie sjena palona?!

    • Fuksja!

  7. Z odzyskiwaniem hasla zawsze byla granda. Do tej pory pamietam, odzyskiwanie hasla na znanym powaznym portal:
    Miales sobie uzytkownika i haslo! Dlugie, losowe, litery wszystkiej masci oraz cyfry i znaki. Ale jesli hasla zapomniales, klikales w odzyskiwanie konta, konto pytalo o imie psa/nauczyciela/matki miesiac urodzenia czy inny banal – i po poprawnej odpowiedzi pojawialo sie okno resetowania hasla z dwoma polami:
    [nowe haslo] oraz
    [powtoz haslo] xD xD
    A najlepsze jest to, za calymi latami w jakiejs formie, opcja ominiedzia bezpiecznego logowania “logowaniem uproszczonym” byla dostepna na wielu portalach, zwlaszcza tych z gornej polki bo ich najbardziej zalezalo zeby zmniejszyc ilosc przypadkow kiedy dostep do konta byl odzyskiwany poprzez tickety – weryfikacje u pracownika.

    Od tamtej pory moj zwierzaczek, mial imie/alias ktore przyprawilo by nawet horrory z dziel Lovecrafta o bol glowy.

    • Tak, odpowiedzi na pytania pomocnicze lepiej traktować jako drugie hasło. Ale warto sprawdzić czy to działa. Kiedyś na jednej skrzynce wpisałem ze znakami specjalnymi (z klawiatury), zapisało się niby poprawnie – ale nie działało! Odpowiedź była “błędna”. Musiałem zmienić na same zwykle litery.

    • Celowe zepsucie odpowiedzi pomocniczej mogłoby wydawać się dobre, by ją zablokować, ale niekoniecznie. Zdarzał się wymuszony reset hasła po wysłaniu “podejrzanego” e-maila, filtrowali po języku, więc odpowiedź musiała działać, by nie stracić skrzynki.

  8. Jeżeli wysłanie wiadomości możliwe jest dopiero po 2 minutach od poprzedniej wiadomości, to można wysłać dziennie 720, a nie 1440 wiadomości :)

  9. Dziś korzystałem z pewnego serwisu (kupowałem pakiet badań) i przy resetowaniu hasła pokazał się komunikat: “Jeśli podany adres jest w naszej bazie, to otrzymasz od nas maila z linkiem do zmiany hasła” ale w formularzu rejestracji było: “Wartość jest już w bazie.” :]

  10. Mam pytanie o procedure resetu hasła dla gmaila z włączonym Google Advanced Protection Program. Podałem Pomocniczy adres email, który jest zabezpieczony aplikacją TOTP.

    Czy warto również podać Pomocniczy numer telefonu?
    Czy podanie numeru pomocniczego nie stwarza zagrożenia, że w przypadku utraty kontroli nad tym numerem, atakujący zresetuje hasło i przejmie kontrolę nad kontem?

    • Sam numer nie wystarczy

  11. A w tym “ataku czasowym” nie wystarczy zmienić kolejności JeśliEmailIstnieje na “sprawdź, pokaż komunikat, wyślij”?

    • Nie do końca – tutaj chodzi o to żeby wysyłka i sprawdzanie czy e-mail jest w bazie było poza requestem który ma tylko przyjąć ten e-mail i zwrócić http 200

  12. Kolejny błąd to słaba menedżerohasłowalność serwisów

    nie zawsze wiadomo czy hasło usługi zostało zmienione – i czy kliknąć zaktualizuj zapisane hasło. A trzeba zmienić oba albo żadne.

    bywa że “stare” i “nowe” hasło są autouzupełnianie tym samym zapisanym hasłem albo zaproponowanym nowym

    niektóre serwisy np apka mobywatel nie pozwalają używać menedżerów, a nawet wkleić ze schowka się nie da – trzeba przepisywać litera po literze

    niektóre witryny każą wpisywać każdą literę w oddzielne pole, a jak się komuś nie chce to sorry batory nie wdrożyliśmy jeszcze FIDO2/passkeys

    na koniec, stosowanie XX-wiecznych reguł złożoności, odrzucanie silnych haseł z menedżera (bo nie było cyfry) ale łykanie słabych albo wyciekniętych

    • Jak się nie da wkleić hasła (na kompie), to wklejasz je gdzie indziej, CTRL+A i przeciągasz myszką na pole z hasłem. Działa w 100%.

    • To jeszcze nic!

      Niektore serwisy maja ograniczenie dlugosci hasla i jest ono ukryte ;)
      Rozumiem przez to, ze w momencie wpisania za dlugiego hasla w formularzu, nadmiarowe znaki sa po prostu ignorowane – rozwiazanie zle, ale nie perfidne.

      Rozwiazanie perfidne, z ktorym tez sie kilka razy spotkalem (na powaznych portalach) jest prawie identyczne do powyzszego, z tym ze rozne formulaze maja inny limit dlugosci hasla xD
      Jest dlugosc ktora miesci sie w bazie (czesto najdluzsza, jest taka na ktora pozwoli formularz tworzenia konta, taka na ktora pozwoli resetowania hasla, taka na ktora pozwoli formularz zmiany hasla, taka na ktora pozwoli ci login ze strony logowania, i taka z okienka wyswietlajacego sie w rogu podczas przegladania strony, jesli wspierana sa inne protokoly to tez czesto maja swoje ustawienia. — oczywiscie nie kazde musi byc inne, ale wystarczy jedna czy dwa miejsca zmieniajace losowo twoje haslo zeby stworzyc problem dla uzytkownika.
      To samo zreszta (nawet bardziej) ma miejsce w przypadku znakow specjalnych – “chciales bezpiecznego hasla!? to ci go z wlasnej ciezkowypracowanej durnoty zmienimy…”

      A co jest rozwiazaniem? Banalne proste, krotkie hasla – a potem admini z ego wiekszym od Olympus Mons’a psiocza na uzytkownikow za problem ktory sam stworzyli…

  13. Największym błędem jest to, gdy na mail zamiast formularza przychodzi po prostu: “Twoje hasło zapisane w naszej bazie brzmi…”.

  14. Ogólnie wszystko fajnie i super a na końcu mamy ficzer że na sklepie nie można złożyć zamówienia jako gość jak już ktoś się na takiego e-maila zarejestrował xD

  15. To ja wskażę jeden błąd, którego tu nie opisano.
    Otóż zalecono zliczanie prób (w tym wypodku prób resetu hasła, ale dotyczy to też wprowadzania hasła), lecz nie zalecono by te zliczone próby się przeterminowywały. I tu jest właśnie problem.
    Taki mObywatel, który blokuje korzystanie z managerów haseł (a co, “niech użytkownik pamięta swoje skomplikowane hasło”), pamięta liczbę pomyłek przy wprowadzaniu BEZTERMINOWO. W efekcie, można mieć nagle zablokowane konto przy pierwszej od roku omyłce (niech się palec omsknie na klawiaturze ekranowej), bo w bazie jest, że dwa lata wcześniej była omyłka i pół roku później druga. Nic to, że później był kilkadziesiąt prawidłowych logowań.
    Ktoś napisał specyfikację by nieudane logowania zliczać i przy trzecim blokować konto. I nie napisał nic o zerowaniu, więc zrobiono bez zerowania.
    Ani upływ czasu, ani prawidłowe zalogowanie nie resetuje tam licznika prób nieudanych, a “wsparcie” uważa, że to prawidłowe.

  16. Niektóre menedżery haseł na przykład Samsung Pass albo Keepass dostarczają wirtualną klawiaturę z guzikami “wpisującymi” login, hasło i tego typu rzeczy.

  17. Enumeracja adresów email jest i tak prawie zawsze możliwa poprzez formularz rejestracyjny – nie da się założyć konta na adres email który już istnieje w systemie.

  18. Pamietam pewna strone, gdzie odzyskiwalem haslo – po podaniu maila przychodzilo zapomniane haslo, a nie link do zmiany :) Czaicie co to oznaczo – ze hasla w bazie nie byly zahaszowane…

    • Najgorsze jest to, że takich stron było więcej. Nawet po rejestracji dostawałeś hasło plain textem. Ciekawe ile takich kwiatków trwa do dzisiaj ;)

  19. A ja z tego co wiem to faceci znają tylko 3 kolory: czarny, biały i ch…wy.

    • Jest jeszcze czwarty: “pedalski”, co prawda tylko u niektórych mężczyzn.

  20. “Po zmianie hasła powinniśmy zapytać użytkownika, czy życzy sobie, aby unieważnić wszelkie zalogowane na jego konto sesje. Jeśli właściciel konta odpowie twierdząco, włamywacz straci sesję.”

    Albo straci ją prawowity użytkownik, jeśli włamywacz skorzystał z procedury zmiany hasła w celu przejęcia konta. No i pozostaje pytanie, jak wielu użytkowników wie, o co chodzi z “wylogowaniem ze wszystkich aktywnych sesji”. Nie zdziwiłbym się, gdyby w niektórych przypadkach ludzie celowo nie wybierali tej opcji, no bo przecież oni chcą się zalogować, a nie wylogować ;)

Twój komentarz

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

RSS dla komentarzy: