Kryptografia – dobre praktyki odnośnie haseł

Dzisiaj chcemy Wam opowiedzieć o dobrych praktykach odnośnie haseł, a dokładniej o ich przechowywaniu, zapisywaniu i polityce haseł jaką możecie zaimplementować w swojej firmie. Jeśli jesteście zainteresowani to zapraszamy!

Niebezpieczeństwa na każdym kroku

Niestety środowisko komputerowe pełne jest podatności, a hakerzy wykorzystując błędy programistów, procedur czy starając się wpłynąć na człowieka starają się przełamać zabezpieczenia. Należy pamiętać, że każdy może stać się ofiarą, czasem nawet nie z własnej winy. Przedstawione porady nie uchronią Was od niebezpieczeństwa, ale pozwolą zminimalizować ryzyko związane z tematyką haseł.

Dobre praktyki

Jeśli chcemy, aby nasze hasła były przechowywane i zarządzane w bezpieczny sposób powinniśmy się zastosować do kilku zasad:

1. Powinniśmy stosować odpowiednią politykę haseł to znaczy odpowiednie wymagania co do złożoności hasła, które wybiera użytkownik. Zamiast pozwalać na dowolne hasło można na przykład wymagać aby hasło zawierało małe i duże litery, lub znaki specjalne. W świecie cyberbezpieczeństwa istnieją spory co do tego jak powinno wyglądać bezpieczne hasło. Część badań pokazuje, że jeśli zmuszamy użytkownika do wybrania hasła z cyfrą i znakiem specjalnym, to oba te znaki zostaną przez niego prawdopodobnie umieszczone na końcu hasła. Warto, żeby hasło było nieoczywiste i miało przynajmniej między 8 a 14 znaków. Dla 12 znaków możliwe jest  6.13 * 10^23 kombinacji przy założeniu, że stosujemy małe i wielkie litery, cyfry i znaki specjalne. 
   
   
2. Jeśli polityka haseł wymaga zastosowania znaków specjalnych to nie należy posługiwać się tzw. leet speek tzn. pisać p@ssword zamiast password, ponieważ istnieją gotowe skrypty generujące takie kombinacje w ramach ataków słownikowych. Lepiej podać znak specjalny na początku i nie zamieniając go na żadną literę np. #*thisiscaptainjackspeakingtoyoupassengers
   
   
3. Warto zachęcać użytkowników do wybierania haseł typu passphrase zamiast password, czyli całych zdań. Zdania są długie i mają znaki interpunkcyjne. więc spełniają wymagania co do złożoności. W środowiskach o nie tak dużych wymaganiach bezpieczeństwa warto polecić wybranie cytatu z mało znanej piosenki lub z ulubionej książki. Decyzje pozostawiamy administratorom.
   
   
4. Rotacja haseł – w temacie stosowania wymogu cyklicznych zmian haseł wśród ekspertów np. każdy pracownik musi raz na miesiąc zmienić hasło na inne od lat toczy się debata. Teoretyczny zamysł polega na tym, że jeśli czyjeś hasło zostanie złamane to napastnik będzie miał tylko ograniczony czas, by skorzystać z uzyskanego dostępu zanim hasło zostanie zmienione. Jest to jednak mało skuteczne z kilku powodów. Po pierwsze atakujący zwykle działają szybko i zanim hasło zostanie poddane rotacji to haker zdąży już coś zrobić w infrastrukturze, albo nawet uzyskać trwały dostęp poprzez tzw. backdoor. Po drugie rotowane hasła są zwykle łatwe do odgadnięcia. W jednym z badań uniwersyteckich przeprowadzonych University of North Carolina naukowcy pokazali, że 41% rotowanych haseł da się złamać w ciągu kilku sekund znając poprzednie hasło. Po trzecie niektórzy eksperci wskazują, że polityka rotacji zachęca użytkownika do wyboru słabych, łatwych do zapamiętania haseł. Jeśli administrator nastraszy użytkownika, że ma wybrać odpowiednio silne hasło, to za pierwszym razem na pewno się postara. Z każdą kolejną wymaganą zmianą hasło będzie prawdopodobnie słabo. Podsumowując, dzisiaj ludzie z branży skłaniają się ku przekonaniu, że rotacja haseł nie jest najlepszym pomysłem na zapewnienie ich bezpieczeństwa dopóki nie ma podejrzenia, że dane hasło wyciekło.
   
   
5. Dbaj o to, aby Twoje hasło było unikalne. Jeśli posiadasz inne hasło do każdego serwisu, to wyciek z jednej firmy informatycznej nie powoduje utracenia konta w innej platformie.
   
   
6. Jako użytkownik warto korzystać z menedżera haseł czyli programu, który generuje i przechowuje nasze hasła do logowania do różnych serwisów internetowych. To pozwala zachować unikalność i odpowiednią losowość generowanych haseł, ponieważ większość wiodących menedżerów ma wbudowane generatory haseł.
   
   
7. API check – podczas rejestracji użytkownika programista może zaimplementować wysłanie zapytania do zewnętrznego serwisu zajmującego się wyciekami danych, aby zobaczyć, czy hasło wybrane przez użytkownika nie znajduje się w wycieku lub na jakiejś znanej liście wykorzystywanej do ataków słownikowych. Dzięki temu programista jest w stanie wyeliminować zagrożenie już na początku rejestracji użytkownika.
   
   
8. Do hashowania haseł w bazie danych wybieraj algorytmy zoptymalizowane w taki sposób, aby były powolne jak np. bcrypt. Rejestracja użytkownika następuje stosunkowo rzadko i jeśli będzie to nawet operacja bardziej obciążająca CPU serwera i wolniejsza to nie będzie to miało wpływu na Twoją aplikację. Jeśli użytkownik będzie musiał poczekać pół sekundy dłużej to nie jest to dla niego większa różnica. Natomiast dla atakującego, który chciałby łamać hashe uzyskane w ten sposób straty czasowe są gigantyczne na każdym hashu, który musi wygenerować.
   
   
9. Jako deweloper stosuj mechanizm soli w swojej aplikacji. W kontekście przechowywania haseł, „sól” to losowa wartość (inna dla każdego z użytkowników) dodawana do hasła przed jego zahaszowaniem i zapisaniem w bazie danych. Ten krok sprawia ma dwa pozytywne skutki w bezpieczeństwie. Po pierwsze użytkownicy, nawet jeśli wybrali takie samo hasło, to w przypadku wycieku mają różny hash i nie następuje żadna kolizja z innym użytkownikiem. Każdy użytkownik ma unikatowy hash. Dodatkowo, zmusza to atakującego do sięgania po metody ataku bruteforce lub słownikowego, a uniemożliwia korzystanie z tęczowych tablic, które znacząco przyspieszają i ułatwiają hakerowi jego działanie.
   
   

    

   Rysunek 1 – mechanizm soli, źródło: geeksforgeeks

10.  Jako deweloper stosuj mechanizm pieprzu w swojej aplikacji. Mechanizm ten różni się od soli tym, że pieprz jest wspólny dla wszystkich użytkowników trzymanych w bazie, ale on sam przechowywany jest w innym źródle np. w kodzie samej aplikacji lub module HSM (ang. Hardware Security Module) Ma to dwie implikacje dla bezpieczeństwa. Po pierwsze sprawia, że wygenerowanie nowych tęczowych tablic (jeśli sól jest zastosowana) jest niemożliwe. Jeśli nawet haker pobierze sól dla każdego użytkownika i wygeneruje dla każdego z nich wszystkie hasła 8-literowe lub hasła w oparciu o słowniki to nie da mu to absolutnie nic. Zostaje mu tylko atak bruteforce i wygenerowanie każdej możliwości po kolei, co w przypadku wieloznakowego pieprzu jest niemożliwe. Druga implikacja to fakt, że pozyskanie pieprzu wymaga innego wektora ataku. Istnieją ataki (np. SQL injection) pozwalające na uzyskanie dostępu do bazy danych a nie do samej aplikacji, co sprawia, że odzyskanie pieprzu staje się dla hakera zadaniem bardzo trudnym jak nie niemożliwym. Odzyskanie hasła z aplikacji też może nie być zadaniem trywialnym i wymagać zastosowania inżynierii wstecznej.
    
    

    

    Rysunek 2 – Mechanizm pieprzu i soli, pieprz powinien być przechowywany w hardware’owym module HSM (ang. Hardware Security Module) jeśli taki istnieje na serwerze. źródło: codesigningstore.com
    
    

11. Pamiętaj, żeby nie umieszczać żadnych haseł czy sekretów w publicznie dostępnym repozytorium w systemie kontroli wersji np. na GitLabie. Wiele razy zdarzało się, że pewne ataki były możliwe przez przypadkowe wrzucenie kluczy prytwanych czy tokenów na publiczne repozytorium. Github od niedawna wprowadził skanowanie publicznych repozytoriów pod tym względem. Więcej o tym można przeczytać pod tym linkiem: https://docs.github.com/en/code-security/secret-scanning/about-secret-scanning 
    
    
12. W aplikacjach warto stosować limit prób zalogowania po którym następuje lockout konta lub timeout na dany adres ip. Możemy wtedy łatwo powstrzymywać ataki na konta naszych użytkowników. Jeśli alarm był fałszywy użytkownik powinien mieć możliwość przywrócenia dostępności własnego konta, o co także należy zadbać.
    
    
13. Samo hasło jest słabym sposobem zabezpieczenia konta, więc powinno się stosować MFA (ang. Multifactor authentication) polegające na podaniu dodatkowego hasła z SMS, aplikacji uwierzytelniającej czy potwierdzeniu na telefonie. Więcej o tym przeczytacie we wpisie sprzed paru tygodni o metodach uwierzytelnienia.  Pamiętaj, że najlepszym rodzajem MFA jest klucz U2F, czyli klucz sprzętowy, który dodatkowo chroni Cię przed phishingiem drugiego składnika.
    
    

Haveibeenpwned

Jeśli chcesz dowiedzieć się czy i jak twoje hasło wyciekło polecamy Ci stronę https://haveibeenpwned.com/ w której po podaniu swojego adresu e-mail aplikacja sprawdzi czy byłeś częścią jakiegoś wycieku. Baza wycieków jest cały czas aktualizowana, więc warto co jakiś czas sprawdzać status swojego e-maila lub maili swoich bliskich. Może warto ich ostrzec, aby zmienili swoje hasło, jeśli nie są świadomi bycia częścią wycieku?

Podsumowanie

Mamy nadzieję, że kolejny artykuł z naszej serii Wam się podobał. Za tydzień zostajemy w temacie kryptografii i opowiemy wam trochę więcej o szyfrach. Jeśli jesteście zainteresowani, to zapraszam!

Źródła:

• https://codesigningstore.com/how-does-hashing-work
• Kyle Rankin – Hartowanie Linuxa we wrogich środowiskach sieciowych
• https://www.geeksforgeeks.org/how-to-hash-passwords-in-python/