Jak zabezpieczyć się przed skutkami wycieku bazy

[Frodo]

Do trzymania skrótów haseł użył bym SHA, np SHA256. Jednak co po długim skrócie gdy samo hasło jest krótkie? Wymusiłbym aby miało co najmniej 20 znaków. Wygenerowane hasło było by wysyłane na konto mailowe gdzie byłaby możliwość jego zmiany ale na równie długie.
A po co trzymać adres mailowy? Można mieć również jego skrót. Gdy użytkownik chce zresetować swoje hasło, podaje adres, obliczany jest skrót i wiadomo o jaki rekord chodzi. Niejasne dla mnie jest generowanie linku, na jaki ma się kliknąć aby zresetować hasło - w jaki sposób może to być bezpieczne?
Można by powiązać na sztywno adres bitcoinowy z kontem aby gdy ktoś się włamie nie mógł sobie przesłać monet. Ale tu powinny być wyjątki: może ktoś przesłać wszystko na konto, usunąć swój wallet i założyć nowy. Tak jak ja miałem wallet pod Windows i założyłem pod Linuksa. Wtedy powinna być możliwość zmiany adresu bitcoinowego ale z potwierdzeniem przez konto mailowe i np. z odczekaniem 24 godzin.

[M4v3R]

Email jest przydatny do powiadomień - na MtGox dostajesz np. powiadomienie o udanej sprzedaży lub kupnie. Na BitMarkecie email jest niemal niezbędny ze względu na sposób, w jaki serwis działa (kojarzenie ludzi chcących wymienić BTC ze sobą). Co do hasła to prawda - MD5 jest zdecydowanie za słabe. U nas używamy kombinacji SHA-256 z SHA-512 - kilka tysięcy rund. Dzięki temu złamanie nawet prostego hasła (6 liter, tylko małe litery) zajęłoby przynajmniej kilkanaście dni. Do tego rozsądne zasady typu minimum 8 liter, przynajmniej jedna cyfra i duże/małe litery i przy powyższym algorytmie bruteforce staje się bezużyteczny.

[Frodo]

A jak jest z tymi rundami? Bezpieczeństwo polega na tym że dla każdego badanego hasła trzeba powtórzyć je kilka tysięcy razy?

[maky]

A po co trzymać adres mailowy? Można mieć również jego skrót. Gdy użytkownik chce zresetować swoje hasło, podaje adres, obliczany jest skrót i wiadomo o jaki rekord chodzi. Niejasne dla mnie jest generowanie linku, na jaki ma się kliknąć aby zresetować hasło - w jaki sposób może to być bezpieczne?

Skrót e-maila to sztuka dla sztuki: albo baza emaili albo atak słownikowy.

Generalnie skrzynka pocztowa to najsłabszy punkt. Przejęcie skrzynki daje niewyobrażalne możliwości.

[KiLeRrosS]

Dokładnie, całe potwierdzenie wiarygodności usera na podstawie adresu e-mail. Trochę słabo.
Dobrą opcja (dodatkową) byłoby spięcie konta z IP, dla tych co mają stały adres. Tylko, że gdzie tu anonimowość w takim przypadku.

[severson]

Możemy również potwierdzać wszystkie transakcje wiarygodnym testem DNA lub potwierdzeniem ze strony kilku realnych znajomych.

W zasadzie jestem przeciwny znacznemu zwiększaniu bezpieczeństwa kosztem znacznego obniżenia funkcjonalności.

Krysia, która korzysta z Bitomatu tylko do tego, do czego on teoretycznie służy (wpłata, konwersja, wypłata) mogłaby mieć nawet hasło "Krysia" i nie oznaczałoby to obniżenia bezpieczeństwa do nieakceptowalnego poziomu.

[maky]

Możemy również potwierdzać wszystkie transakcje wiarygodnym testem DNA lub potwierdzeniem ze strony kilku realnych znajomych.

W zasadzie jestem przeciwny znacznemu zwiększaniu bezpieczeństwa kosztem znacznego obniżenia funkcjonalności.

Krysia, która korzysta z Bitomatu tylko do tego, do czego on teoretycznie służy (wpłata, konwersja, wypłata) mogłaby mieć nawet hasło "Krysia" i nie oznaczałoby to obniżenia bezpieczeństwa do nieakceptowalnego poziomu.

Dokładnie. Jeśli ktoś traktuje bitomat.pl jako konto oszczędnościowo rozliczeniowe to:
1. radzę poczytać regulamin
2. kim jest twórca?
3. wróć do pkt 2

[qertoip]

Wygenerowane hasło było by wysyłane na konto mailowe

Proponujesz dziurę, a nie zabezpieczenie.

A po co trzymać adres mailowy? Można mieć również jego skrót.

Nie można. E-mail jest niezbędny do działania każdego serwisu.

Niejasne dla mnie jest generowanie linku, na jaki ma się kliknąć aby zresetować hasło - w jaki sposób może to być bezpieczne?

Taki link powinien wygasać natychmiast po użyciu lub upływie krótkiego czasu nawet jeśli nie był wykorzystany. Za każdym razem generowany jest inny link. Link nie może działać na stałe. To jest procedura awaryjna - chwilowe (na godziny) obniżenie bezpieczeństwa żeby odzyskać konto.[/quote]

[Frodo]

Wygenerowane hasło było by wysyłane na konto mailowe

Proponujesz dziurę, a nie zabezpieczenie.

Na czym polega ta dziura?

A po co trzymać adres mailowy? Można mieć również jego skrót.

Nie można. E-mail jest niezbędny do działania każdego serwisu.

Niezbędny jest do odzyskiwania hasła. W tym przypadku użytkownik sam podaje e-mail

Niejasne dla mnie jest generowanie linku, na jaki ma się kliknąć aby zresetować hasło - w jaki sposób może to być bezpieczne?

Taki link powinien wygasać natychmiast po użyciu lub upływie krótkiego czasu nawet jeśli nie był wykorzystany. Za każdym razem generowany jest inny link. Link nie może działać na stałe. To jest procedura awaryjna - chwilowe (na godziny) obniżenie bezpieczeństwa żeby odzyskać konto.

Zgoda. Ale w jaki sposób generować? Aby nie było przypadku, że ktoś poda czyjeś konto a sam tymczasem wygeneruje sobie link nie patrząc co przyszło na tamto konto?

[qertoip]

Wygenerowane hasło było by wysyłane na konto mailowe

Proponujesz dziurę, a nie zabezpieczenie.

Na czym polega ta dziura?

Wszystko wysłane e-mailem powinno być uważane za upublicznione. Duża część SMTP i PO3 wciąż idzie otwartym tekstem. Dodatkowo, historyczna zawartość skrzynki jest stosunkowo łatwo dostępna (np. użytkownik robi sobie backupy poczty na inne dyski czy automatycznie online). Hasło nie może być wysyłane otwartym tekstem ani zalegać w archiwach poczty.

A po co trzymać adres mailowy? Można mieć również jego skrót.

Nie można. E-mail jest niezbędny do działania każdego serwisu.

Niezbędny jest do odzyskiwania hasła. W tym przypadku użytkownik sam podaje e-mail

Niezbędny jest do mailingów, zarówno komercyjnych, jak i choćby związanych z bezpieczeństwem. Bez e-maili to tylko 4chan

Niejasne dla mnie jest generowanie linku, na jaki ma się kliknąć aby zresetować hasło - w jaki sposób może to być bezpieczne?

Taki link powinien wygasać natychmiast po użyciu lub upływie krótkiego czasu nawet jeśli nie był wykorzystany. Za każdym razem generowany jest inny link. Link nie może działać na stałe. To jest procedura awaryjna - chwilowe (na godziny) obniżenie bezpieczeństwa żeby odzyskać konto.

Zgoda. Ale w jaki sposób generować? Aby nie było przypadku, że ktoś poda czyjeś konto a sam tymczasem wygeneruje sobie link nie patrząc co przyszło na tamto konto?

Nie rozumiem problemu. Owszem, można wygenerować link innej osobie, znając jej login i e-mail. Ale on przyjdzie do tej innej osoby, więc najwyżej zaśmieci jej skrzynkę i nic więcej.

[M4v3R]

A jak jest z tymi rundami? Bezpieczeństwo polega na tym że dla każdego badanego hasła trzeba powtórzyć je kilka tysięcy razy?

Rundy czynią proces hashowania wolniejszym, bo trzeba ten sam algorytm powtórzyć wiele razy. Dzięki temu np. słabe hasło zamiast 5 godzin hasło łamałoby się 5 tysięcy godzin. Co czyni łamianie go nieopłacalnym.

[qertoip]

A jak jest z tymi rundami? Bezpieczeństwo polega na tym że dla każdego badanego hasła trzeba powtórzyć je kilka tysięcy razy?

Rundy czynią proces hashowania wolniejszym, bo trzeba ten sam algorytm powtórzyć wiele razy. Dzięki temu np. słabe hasło zamiast 5 godzin hasło łamałoby się 5 tysięcy godzin. Co czyni łamianie go nieopłacalnym.

Zgadza się.

Z drugiej strony pamiętajmy, że przy logowaniu serwer musi to wszystko obliczyć dla podanego hasła, żeby porównać go z hashem. Jeśli nałoży się drakońskie wymagania na pracochłonność generowania skrótu, to próba logowania staje się zasobożerną, publicznie dostępną akcją aplikacji. To czyni aplikację bardziej podatną na (D)DOS-y.

[Frodo]

Jak oblicza raz to nie powinno być problemu dla tysiąca rund, może dla miliona. Ale bardziej zabezpiecza wydłużenie hasła; podwojenie może utrudnić odgadnięcie kilkaset tysięcy razy.

[koko]

wystarczy dodac do kazdego hasla salt z losowo wygenerowanych np 20 znakow, po czym dokonac podwojnej funckji skrotu (nawet starego md5) i wowczas lamanie brute force czy przy uzyciu rainbow tables staje sie praktycznie niemozliwe nawet dla hasel o dlugosci 1 znaku.

[Frodo]

wystarczy dodac do kazdego hasla salt z losowo wygenerowanych np 20 znakow, po czym dokonac podwojnej funckji skrotu (nawet starego md5) i wowczas lamanie brute force czy przy uzyciu rainbow tables staje sie praktycznie niemozliwe nawet dla hasel o dlugosci 1 znaku.

Musimy mieć generator losowości wielkości 160 bitów. Dla każdego hasła inne salt, ale nie może być czysto losowe, każde hasło musi mieć własną inicjacyjną wartość dla zadanego hasła. Jest ono zależne od hasła, więc dla krótkich haseł odtwarzamy proces generowania soli i krótkie hasła da się złamać. Chyba że działa inaczej, czegoś nie rozumiem. Gdyby salt była losowymi znakami jak guid to drugi raz dla tego samego hasła otrzymalibyśmy inną wartość i inny skrót.

[M4v3R]

Zgadza się.

Z drugiej strony pamiętajmy, że przy logowaniu serwer musi to wszystko obliczyć dla podanego hasła, żeby porównać go z hashem. Jeśli nałoży się drakońskie wymagania na pracochłonność generowania skrótu, to próba logowania staje się zasobożerną, publicznie dostępną akcją aplikacji. To czyni aplikację bardziej podatną na (D)DOS-y.

Przed takim DDoSem stosunkowo łatwo się zabezpieczyć. Wystarczy wtedy ograniczyć ilość możliwych prób i blokować dostęp np. na 10 minut po 5 nieudanych.

wystarczy dodac do kazdego hasla salt z losowo wygenerowanych np 20 znakow, po czym dokonac podwojnej funckji skrotu (nawet starego md5) i wowczas lamanie brute force czy przy uzyciu rainbow tables staje sie praktycznie niemozliwe nawet dla hasel o dlugosci 1 znaku.

Nieprawda. Zawsze pozostaje Ci możliwość najzwyklejszego bruteforce'a. Bo skoro zakładamy że baza została złamana to atakujący ma tez dostęp do saltow. Z algorytmem który podałeś słabe hasła (poniżej 7-8 znaków, bez znaków specjalnych) są do złamania w ciagu minut.

Na razie jedyny sposób na bycie w miarę bezpiecznym przy użyciu haseł to:
- wymagać używania silnych haseł (plus sprawdzanie czy hasło nie jest słownikowe)
- obliczać skrót hasła przy użyciu nowych algorytmów (SHA-256/512)
- używać innej, losowej soli dla każdego użytkownika
- używać dodatkowej soli z innego miejsca (np. zdefiniowanej w kodzie aplikacji)
- używać przynajmniej kilkuset rund algorytmu hashowania. Dodatkowe punkty za losową ilość rund w zależności od użytkownika.

Jeszcze jedną rzeczą którą można zrobić aby znacząco zwiększyć bezpieczeństwo jest wprowadzenie dwu-stopniowej autoryzacji (jednorazowe hasła, na papierze, wysyłane przez SMS lub odczytywane z tokena). to jest właśnie coś, co zamierzamy na BitMarkecie niedługo wprowadzić.

[qertoip]

Przed takim DDoSem stosunkowo łatwo się zabezpieczyć. Wystarczy wtedy ograniczyć ilość możliwych prób i blokować dostęp np. na 10 minut po 5 nieudanych.

Ale komu zablokować? Logowanie to publiczna akcja - żądający jest nieuchwytny.

Na IP praktycznie nie można polegać:
- przy Distributed DOS atak odbywa się z różnych IP
- IP często bywa wspólne dla wielu użytkowników (proxy dostawcy Internetu, sieci korporacyjnej czy akademickiej)
- łatwo zmieniać IP żądania (multiproxy, tory itp) nawet przy zwykłym DOS

W ten sposób można się zabezpieczyć tylko przed script kiddies.

W ogólnym przypadku jedyne co można zrobić, to uczynić wszystkie publiczne akcje aplikacji bardzo lekkimi i postawić silne serwery, żeby skuteczny DDOS był trudny do zorganizowania.

Na razie jedyny sposób na bycie w miarę bezpiecznym przy użyciu haseł to:
- wymagać używania silnych haseł (plus sprawdzanie czy hasło nie jest słownikowe)
- obliczać skrót hasła przy użyciu nowych algorytmów (SHA-256/512)
- używać innej, losowej soli dla każdego użytkownika
- używać dodatkowej soli z innego miejsca (np. zdefiniowanej w kodzie aplikacji)
- używać przynajmniej kilkuset rund algorytmu hashowania. Dodatkowe punkty za losową ilość rund w zależności od użytkownika.

100% prawda.

Jeszcze jedną rzeczą którą można zrobić aby znacząco zwiększyć bezpieczeństwo jest wprowadzenie dwu-stopniowej autoryzacji (jednorazowe hasła, na papierze, wysyłane przez SMS lub odczytywane z tokena). to jest właśnie coś, co zamierzamy na BitMarkecie niedługo wprowadzić.

Światna wiadomość!

[Frodo]

Nieprawda. Zawsze pozostaje Ci możliwość najzwyklejszego bruteforce'a. Bo skoro zakładamy że baza została złamana to atakujący ma tez dostęp do saltow. Z algorytmem który podałeś słabe hasła (poniżej 7-8 znaków, bez znaków specjalnych) są do złamania w ciagu minut.

Znaki specjalne nie wiem czy są konieczne. Użycie wielkich liter i cyfr zwiększa dla każdego znaku trudność owszem 2.5 krotnie. Ale łatwiej się pomylić z wielkimi literami. Tymczasem znacznie wzrasta trudność łamania hasła gdy dłuższe choćby o 50%.

Na razie jedyny sposób na bycie w miarę bezpiecznym przy użyciu haseł to:
- wymagać używania silnych haseł (plus sprawdzanie czy hasło nie jest słownikowe)

Potrzebny byłby słownik polski i angielski. A może zadać pytanie Googlowi i nie mógłby zwrócić żadnego wyniku? Jednak lepiej wymagać długie hasło np. 16 znaków i wtedy nie należałoby sprawdzać czy należy do słownika (bo za długie) ale czy jakiś dłuższy fragment nie należy do słownika - to jednak byłoby czasochłonne, dla jednego ciągu byłaby masa podciągów.

- obliczać skrót hasła przy użyciu nowych algorytmów (SHA-256/512)

tak

- używać innej, losowej soli dla każdego użytkownika

Skąd pobrać losową wartość? odczyt zegara daje mało bitów a tu trzeba by odczytać wiele liczb losowych. Tego nie za bardzo rozumiem. Ta wartość soli i tak musiała by być zapisana w bazie. W razie wycieku byłaby znana.

- używać dodatkowej soli z innego miejsca (np. zdefiniowanej w kodzie aplikacji)

Dobre rozwiązanie. Mniejsze prawdopodobieństwo wycieku bazy+programu

Jeszcze jedną rzeczą którą można zrobić aby znacząco zwiększyć bezpieczeństwo jest wprowadzenie dwu-stopniowej autoryzacji (jednorazowe hasła, na papierze, wysyłane przez SMS lub odczytywane z tokena). to jest właśnie coś, co zamierzamy na BitMarkecie niedługo wprowadzić.

Trzeba by jeszcze zabezpieczyć się przed phishingiem. Fałszywa strona może ukraść zarówno hasło logowania jak i hasło jednorazowe. Można by jeszcze zrobić tak jak w Liberty Reserve - użytkownik definiuje własny tekst powitania, który musi się zgadzać.
Captcha jest niekonieczna, tylko dodatkowe utrudnienie dla legalnego użytkownika.

[qertoip]

Znaki specjalne nie wiem czy są konieczne.

Są konieczne. Dziedziną powinny być praktycznie wszystkie drukowalne znaki.

A może zadać pytanie Googlowi i nie mógłby zwrócić żadnego wyniku?

ROTFL. Przecież wtedy upubliczniasz hasło!

Skąd pobrać losową wartość?

Jak zwykle: z generatora liczb pseudolosowych.

Tego nie za bardzo rozumiem. Ta wartość soli i tak musiała by być zapisana w bazie. W razie wycieku byłaby znana.

Bez indywidualnej soli atakujący najpierw (jeden raz) liczy skróty dla wszystkich możliwych haseł (np. do 8 znaków). Następnie porównuje gotowe skróty z wyciękniętymi skrótami haseł. Z indywidualną solą musi dla każdego usera osobno liczyć skróty wszystkich możliwych haseł. Dzięki indywidualnej soli cały proces robi się n razy wolniejszy, gdzie n to liczba userów w bazie.

Frodo, doceniam że naciskasz na bezpieczeństwo i starasz się pomóc w lepszym zabezpieczeniu serwisów z których korzystasz. Ale szczerze mówiąc bardziej mieszasz niż pomagasz. Tu nie ma miejsca na kombinowanie i wymyślanie własnych rozwiązań. W tych tematach od dawna istnieją sprawdzone rozwiązania, które trzeba po prostu zrozumieć i zaimplementować (no offence!).

[Frodo]

Znaki specjalne nie wiem czy są konieczne.

Są konieczne. Dziedziną powinny być praktycznie wszystkie drukowalne znaki.

Zgoda że powinny być _możliwe_ ale niekoniecznie trzeba by wymagać dużych liter, user na odczepnego może wstawić jedną dużą literę. Ważniejszą rzeczą jest długość hasła, dobrą praktyką byłoby użycie kliku słów nawet ze słownika, to gdy będzie ich np. 4 każdy ze 100 tysięcy słów, już mamy duże bezpieczeństwo, a 4 słowa jest łatwiej zapamiętać niż 16 losowych znaków.

A może zadać pytanie Googlowi i nie mógłby zwrócić żadnego wyniku?

ROTFL. Przecież wtedy upubliczniasz hasło!

Rzeczywiście, byłoby to absurdalne...

Skąd pobrać losową wartość?

Jak zwykle: z generatora liczb pseudolosowych.

Ale wtedy mam wartość pseudolosową, a generator trzeba ustawić najpierw prawdziwie losową wartością. Linux ma pojemnik liczb losowych gdzie gromadzi losowość ruchu myszki i wciśnięcia klawiatury. W Windows nie wiem czy jest wystarczająca losowość. Ale tu trzeba dużo bitów, gdy chcemy dać losową sól dla każdego indywidualnie.

Bez indywidualnej soli atakujący najpierw (jeden raz) liczy skróty dla wszystkich możliwych haseł (np. do 8 znaków). Następnie porównuje gotowe skróty z wyciękniętymi skrótami haseł. Z indywidualną solą musi dla każdego usera osobno liczyć skróty wszystkich możliwych haseł. Dzięki indywidualnej soli cały proces robi się n razy wolniejszy, gdzie n to liczba userów w bazie.

Rzeczywiście, obliczenie skrótu jest dłuższa operacją niż jego porównywanie.

W tych tematach od dawna istnieją sprawdzone rozwiązania, które trzeba po prostu zrozumieć i zaimplementować (no offence!).

MtGox nie w pełni korzystał ze wszystkich rozwiązań. Pytając się, dowiaduję się pewnych rzeczy o bezpieczeństwie, chociażby to jak indywidualna sól utrudnia łamanie haseł.