Preorder drugiego tomu książki sekuraka: Wprowadzenie do bezpieczeństwa IT. -15% z kodem: sekurak-book
Poprosili freelancerów o zakodowanie prostej aplikacji przechowujących hasła użytkowników. Plaintext rządzi…
Badanie polegające na zatrudnianie realnych programistów do realnej pracy (nie pod pozorem „badania”). Prosta aplikacja miała m.in. przechowywać hasła użytkowników. Wypłata – do 200 EUR.
Z próbki 43 osób, 21 przesłało wyniki swojej pracy z hasłami przechowywanymi w bazie za pomocą „algorytmu” plaintext… Po zgłoszeniu problemu część przerobiła swój kod, ale i tak skutkował on np. użyciem algorytmu Base64 (!), sporo było też bezczelnych MD5().
Wyniki…
Finalne zestawienie tutaj:
8 – Base64
10 – MD5
3 – AES 3
3- DES
1 – SHA-1
5 – SHA-256
5 – PBKDF2
7 – Bcrypt
1 – HMAC/SHA1
10 – MD5
3 – AES 3
3- DES
1 – SHA-1
5 – SHA-256
5 – PBKDF2
7 – Bcrypt
1 – HMAC/SHA1
Autorzy pracy mają kilka ciekawych wniosków:
- Jeśli potrzebujesz mieć coś napisane bezpiecznie – wprost o to poproś w specyfikacji!
- O dziwo nie było wielkiej korelacji pomiędzy grupą studentów (wiedzieli że będą uczestniczyli w pewnym badaniu) a freelancerów:
„Freelance developers are aware that clients will use their solution in the real world. However, the quality of solutions was comparable to the solutions of students” - W bezpieczeństwie często panuje prowizorka. Tutaj objawiło to się literalnie – wizualnie „zaszyfrowany” wynik Base64, był traktowany czasem jako dobre rozwiązanie (klient się nie zorientuje?)
- Dużo osób deklarowało, że zakodowałoby bezpieczne rozwiązanie nawet bez extra tego typu wymogu, ale realnie różnie z tym bywa: „A number of freelancers reported they would store user passwords securely even without a security instruction. However, these participants sent insecure solutions as their first submissions.”
Dla pewności było też trochę dobrych rozwiązań tematu (Bcrypt lub PBKDF2 – 12 na 41 rozwiązań – część tych osób wykonała dobrą robotę dopiero w drugiej interacji, po zwróceniu uwagi na słabość np. plaintext).
W temacie polecamy również nasze nowe, gorące szkolenie mówiące o wdrożeniu bezpiecznego procesu wdrażania aplikacji webowych u siebie w firmie.
–ms
No spoko, ale w apce za 200 euro nie ma się co spodziewać bezpieczeństwa. Myślę, że na inne niefunkcjonalne obszary (seo, accessibility, wydajność, itp) też nie zwrócili uwagi.
pamiętaj że to była bardzo prosta rzecz do napisania – przez dobrego kolesia może i nawet w pół dnia :)
Czyli jeżeli coś jest za darmo, znaczy że w ogóle nie powinno być dobre? Przykładowo otwartoźródlowe oprogramowanie, które ktoś robi po godzinach?
Myślenie godne klepacza, lub studenta.
Dołączam się do kolegi @F
Może poza ofensywnymi twierdzeniami w dziedzinie oceny użytkownika. ;-)
Co Ty w ogóle porównujesz?
Kod otwartoźródłowy jest dla większego grona i jest Twoją wizytówką.
Kod dla jakiegoś łepka, który daje ogłoszenie na jakimś freelancer za parę euro to zupełnie inna para kaloszy…
Co nie zmienia faktu, że czegoś takiego bym nie odwalił, ale porównanie zupełnie bez sensu.
Najbardziej mniej rozczulil pierwszy pounkt „jeśli potrzebujesz mieć coś napisane bezpiecznie – wprost o to poproś w specyfikacji!”, ktory obowiazuje tez w swiecie duzego biznesu. Pamietam zlosc jednego z dzialow bezpieczenstwa duzej instytucji, ktory po zewnetrznym audycie dzialajacej wiele lat kluczowej aplikacji zorientowal sie, ze system jest dziurawy jak cedzak. Oczywiscie rownie wielkie bylo zaskoczenie osob odpowiedzialnych za sprzedaz i development produktu: „przeciez nie bylo w specyfikacji 8-O” ;-)
BTW zdarzaja sie tez instytucje z bardzie profesjonalnym podejsciem, gdzie wprost specyfikuja, jakie testy bezpieczenstwa system powinien przejsc oraz stawiaja wymagania odnosnie bledow wykrytych w eksploatacji
Czy SHA-256/512 faktycznie jest takie niebezpieczne?
nie, ale są lepsze rozwiązania (akurat w tym konkretnym celu – przechowywanie haseł).
Nikt chyba nie słyszał o PHC Password Hashing Competition i wygranym Argon2
ano. o tym pewnie też nie: https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Password_Storage_Cheat_Sheet.md
O Argon2 w ogóle mało kto chyba słyszał. Zawsze jak czytam jakieś artykuły dotyczące hashowania (lub jego braku) to wymieniane są pbkdf2 i bcrypt. Z scryptem już dużo gorzej, a artykuły gdzie przewija się Argon2 jestem w stanie na palcach jednej ręki policzyć. (aczkolwiek ja artykuły dla lamerów czytuję, więc to może dlatego ;))
Argon2 to bardzo fajna funkcja: pozwala na wymuszenie nie tylko interesującej nas złożoności czasowej, ale także pamięciowej, ponadto można wymusić czterowątkowość. Jedyne mi znane ogólnodostępne wdrożenie to wersja 2 narzędzia cryptsetup używanego w Linuksach do szyfrowania dysków (LUKS2). Działa naprawdę nieźle i jest wysoce konfigurowalne.
nie zgadzam się z kim mówi, że skoro 200 EUR nie ma mowy o bezpieczeństwu. To żart i poważny jakiś. Jeśli biorę zlecenie nieważne czy za 2 czy za 2000 EUR i tak jestem zobowiązany oddać bezpieczną apke bo po pierwsze świadczy o tym jaki poważni jesteśmy z tego względu a po drugie może będzie przez dobre praktyki mniej problemów u klienta bez leaków. Jak się nie chce dobrych praktyk stosować (przynajmniej te od bezpieczeństwa) nie brać w ogóle zleceń ludzie
ano… to tak jakby lekarz który bierze 200 euro za operację zostawiał tampon zaszyty w pacjencie :)
> jestem zobowiązany oddać
Jesteś zobowiązany oddać to do czego się zobowiązałeś w umowie. W przypadku security rozmawiamy z klientem o modelu zagrożeń, wspólnie ustalamy odpowiednie środki zaradcze i zapisujemy je w odpowiednim załączniku do umowy. 2FA też jest dobrą praktyką, implementujesz ją w każdym ze swoich projektów?
Gdybym miał w projektach stosować wszystkie możliwe dobre praktyki to klient by się nie wypłacił. Zawsze rozmawiam z klientem i próbuję go przekonać żeby zapłacił za implementację wszystkiego co dobre. Ale uczestniczę w projektach za miliony i rozumiem, że klienta może być po prostu nie stać. W takim wypadku umowa zawiera wpis, że na dany obszar nie zwracamy uwagi i klient bierze ryzyko na siebie.
Szczerze mówiąc, nie spotkałem jeszcze żadnej strony, która by miała zaimplementowane wszystkie możliwe dobre praktyki ze wszystkich możliwych obszarów.
Ok, ale nie w tym rzecz.
Np. jesli masz zaimplementować szyfrowanie i wybierasz md5 gdzie w dostępnym internecie pisze od jakiegoś czasu ze md5 jest niezalecane ze względów bezpieczeństwa to świadczy o zaniżonej wiedzy developera lub złych chęciach.
Albo o zaniżonej wiedzy internetu. Wiadomo od dekad że odporność na kolizje MD5 jest słaba. Ale jakie to ma znaczenie? W łamaniu hashy liczy się odporność na przeciwobraz i drugi przeciwobraz. A w tym MD5 do dzisiaj jest nie złamane.
tak na szybko to: https://www.theregister.co.uk/2018/11/23/knuddels_fined_for_plain_text_passwords/ tu nawet plaintext mieli i tylko 20k EUR kary ;)
Co do MD5 to największym problemem jest szybkość łamania. Jak ktoś ma sensowne, losowe hasło 20 znaków to i MD5 da rady i raczej tego nie złamiesz
„Albo o zaniżonej wiedzy internetu.”
Rece opadaja.
Proszę dokladnie poszukać i uzupełnić swoja wiedze.
– przeczytac dlaczego, kiedy kolizja wystepuje
– kiedy uznajemy ze dany hasz jest ” w miare ” bezpieczny
– w ktorym roku znaleziono kolizje dla MD5
Moze byc takze pomocne
http://valerieaurora.org/hash.html
Ale szkoda ze dziewczyna tego nie zaktualizowala do 2019 roku
Oraz mniej intuicyjne wiki, ale tam tez sa daty i czesto pisze czy dany hash jest nie bezpieczny.
https://en.wikipedia.org/wiki/List_of_hash_functions#Unkeyed_cryptographic_hash_functions
No dobra, przepraszam, masz częściową racje.
Internet jest tak mądry jak mądrzy są ludzie.
A teraz przeszukując internet pod katem md5 widzę pewien problem
Te braki wynikają:
– z daty artykułu / forum im starsze tym większe prawdopodobieństwo ze nieaktualne już trochę.
– tym ze nie każdy artykuł jest na bieżąco aktualizowany
– tym ze niektórzy ludzie posiadają wiedze z nieaktualnych już źródeł.
– tym ze niektórzy ludzie nie potrafią pisać lub przeczytać ze zrozumieniem.
Co do kolizji masz racje, ale nie w tym rzecz, gdy będziesz czytał dlaczego to jest uważane za bezpieczne i kiedy znaleziono dana podatność mam nadzieje ze wtedy zrozumiesz dlaczego to jest używane. Mam nadzieje ze się nie gniewasz ze każe Ci czytać zamiast napisać wprost :)
Chwała Tobie @mattblack za Twe słowa i Twoje podejście.
Ratujesz mój obraz człowieka.
Ale hashe nie służą do przechowywania haseł tylko do ich sprawdzenia czy aktualnie podane hasło jest takie samo jak to wpisane pierwotnie. Przechowywanie to możliwość jego ponownego odzyskania (bez łamania). I tylko kilka osób tak napisało aplikacje. Poza tym w umowie nie było nigdzie „bezpieczne przechowywanie”.
I tak. Od aplikacji za 200 euro (patrzenie na cene z perspektywy polaka to zły sposób) nie ma co oczekiwać cudów. Ci co twierdzą inaczej może robią za darmo.
Nie wiem.
Podejrzewam, że w umowie też nie było napisane „aplikacja musi działać”, tylko np. wykonawca zrealizuje aplikację z następującymi funkcjami: X, Y, Z.
Nikt nie pisał że mają to być „działające funkcje” ;-)
Tak samo jak zapewnie nie było zapisu, żeby nie dołączać backdoorów ;D
dokładnie :)
Hash ma co najmniej dwa zastosowania
– do sprawdzania czy plik jest taki sam (suma kontrolna)
– jako „algorytm szyfrujacy”
Zajmijmy sie tym
https://www.cyberciti.biz/faq/linux-md5-hash-string-based-on-any-input-string/
Jak doczytasz
http://algorytm.edu.pl/algorytmy-maturalne/szyfrowanie.html
” MD5 – algorytm szyfrujący w jedną stronę – takiej wiadomości nie można odszyfrować ”
(choc wiadomo ze gdzies sa kolizje, ale nie wiadomo gdzie)
i nagle w 2004 roku ktos je znajduje
http://valerieaurora.org/hash.html
Jeszcze cos dopowiem.
Pomijajac techniki np. slownikowe, teczowe, tworzenie bazy hashy, .itp. Krótkie haslo wydaje sie byc pozornie bezpieczne bo utworzony hash jest dluzszy od samego hasla. Tylko dluzsze hasla moga miec z tym problem.
Ale jesli ktos juz doszedl jak wynajdywac kolizje na podstawie hashy, to byc moze wie jak ograniczyc liczbe hasel ktore by pasowaly do tego samego hasha. Ja przynajmniej nie znalazlem przykladu jak mozna by uzywac kolizji do odgadniecia hasla.
( Swoja droga to jest straszne, ze ktos moze sie wpisac inne haslo i będzie pasować do tego samego hasha :D )
Nawet jeśli nikogo to nie przekonuje, to powinno przekonać ze
– algorytm który tworzy dłuższy hash teoretycznie powinien stworzyć tez większą bazę możliwych hashy
– a tworzenie tak długich hashy zajmuje także więcej czasu.
Niestety to tylko teoria, bo to zależy także od „prawdziwej siły” algorytmu.
– Ale powinno sie takze brac pod uwage wiek algorytmu.
MD5 jest tak stare ze w internecie napewno powstala juz dosc pokazna baza hashy.
Wniosek: skoro można skorzystać z „bezpieczniejszych” niz MD5 rozwiązań przy takim samym nakładzie pracy, to czemu ich nie użyć?
„Ci co twierdzą inaczej może robią za darmo.”
Masz racje, cześć ludzi na pewno pracuje dla społeczności w ramach Open Source.
Dzieki temu powstają poradniki, i w tym także poradniki odnośnie bezpieczeństwa.
Ale na pewno to tez jest podyktowane wielkością grupy,
im większa grupa developerów z chęcią szerzenia bezpieczeństwa i wolnym czasem tym więcej jest poradników odnośnie bezpieczeństwa, także w firmach.
Jeżeli są firmy których bezpieczeństwo nie jest priorytetem, a pewnie tez są takie, no bo rzeczywistość jest brutalna i może w pewnych aspektach firma zaoszczędzi, ale granica jest bardzo cienka. I w przypadku MD5 wątpię by przerobienie kodu kosztowało aż tyle czasu, a wpadka może się odbić na przyszłych zleceniach dla firmy, lub danego developera.