Autor Wątek: Bespieczeństwo baz danych  (Przeczytany 4021 razy)

Offline Krzysiek K.

  • Redaktor
    • DevKK.net

# Marzec 03, 2010, 16:37:05
Dlatego używa się hasha, którego samo obliczenie zajmuje 0.1 s.
Nie przesadzasz? SHA-1 powinno być wystarczające do takich zastosowań.

Offline Mr. Spam

  • Miłośnik przetworów mięsnych

Offline msieradzki

  • Użytkownik

# Marzec 03, 2010, 16:58:20
http://www.postgresql.org/docs/8.3/static/pgcrypto.html

W Postgresie masz już to wszystko zakodzone. Czas haszowania można dostroić wg potrzeb.

Porównanie szybkości haszowania:

Algorithm   Hashes/sec   For [a-z]   For [A-Za-z0-9]
crypt-bf/8   28      246 years   251322 years
crypt-bf/7   57      121 years   123457 years
crypt-bf/6   112      62 years   62831 years
crypt-bf/5   211      33 years   33351 years
crypt-md5   2681      2.6 years   2625 years
sha1      590223   4 days   12 years

Offline siso

  • Użytkownik

# Marzec 04, 2010, 01:49:46
Jak nie idki, to co?
Hashe obiektów, czy podobne coś. Wspomniany już frejmłork powinien takie coś dostarczyć.
Powinny to być jakieś abstrakcyjne na pierwszy rzut oka wartości, trudne do skojarzenia z istniejącymi w bazie obiektami. Najważniejsze - nie będące sekwencją. I niech jeszcze zmieniają się z sesji na sesję, a co.

ID-ki i formularze do tego właśnie przecież służą, nie głośmy herezji. User wypełnia forma / klika w link i wysyła w ten sposób żądanie, skrypt je analizuje, sprawdza pod kątem poprawności (np. uprawnienia, spójność, zgodność z logiką systemu) i - jeśli potrzeba - uaktualnia model danych, czyli bazę. Tak to działa i działać powinno.
Nie głosimy herezji, próbujemy tu tylko walczyć z antypatternami ;)
Formy służą do tego, o czym napisałeś i tak to działać powinno ale - na litość - nie ma powodów do pchania w nie surowych danych z bazy, lecz tylko tych, które zostały świadomie wystawione. Jeśli zamiast ID-ków użyjesz hash-y, pierwszy z brzegu spryciarz nie będzie w stanie zniszczyć Ci zawartości celując w jakieś okoliczne wartości z sekwencji, żeby daleko przykładu nie szukać.


Dlatego używa się hasha, którego samo obliczenie zajmuje 0.1 s.

http://chargen.matasano.com/chargen/2007/9/7/enough-with-the-rainbow-tables-what-you-need-to-know-about-s.html
Przeczytałem tylko początek, dalej mi się nie chciało, bo już późno :)
Przedstawiony tu sposób jest tyleż naiwny, co niepraktyczny. Co najwyżej 15-to znakowe bazy do hashowania czegokiolwiek (nie tylko haseł) nie są już modne w tym sezonie ;) Wystarczy użyć dwa, trzy, niech nawet i cztery razy dłuższych i odporność na reverse eng. znacząco rośnie. Dodajmy do tego możliwość zastosowania nie jednego a kilku różnych algorytmów hashujących, możliwość preprocessingu wejścia i postprocessingu wyjścia (jeśli komuś mało) - i co, wychodzą niezłe hashcze? ;)

Offline owyn

  • Użytkownik

# Marzec 04, 2010, 11:08:31
Dlatego używa się hasha, którego samo obliczenie zajmuje 0.1 s.

http://chargen.matasano.com/chargen/2007/9/7/enough-with-the-rainbow-tables-what-you-need-to-know-about-s.html

Czyli spowalniamy nasz serwer aby lekko zwiększyć bezpieczeństwo na wypadek, gdyby ktoś odczytał dane z bazy? Z tego co zrozumiałem, autorowi wątku chodziło o jakąś grę online, a nie o obsługę konta bankowego. Poziom zabezpieczeń należy dostosować do potrzeb. Jeśli z tym przesadzisz, to w efekcie zmarnujesz zbyt dużo czasu na implementację, a serwer będzie działał zbyt wolno.

Offline msieradzki

  • Użytkownik

# Marzec 04, 2010, 12:32:15
Uprościłem to wtedy trochę pisząc 0.1s, liczbę iteracji Blowfisha możesz dostosować (p. ten link do dokumentacji PostgreSQLa). Sprawdzanie hasła jest używane przez 1 użytkownika raz na godzinę lub rzadziej. W tym samym czasie twoja strona odpowiada na np. 100 żądań od niego. Na pewno lepsze to od SHA1, które można w tym samym czasie wykonać 10k razy częściej. Założenie jest takie, że użytkownicy mają te same hasło do innych, ważniejszych stron i niektórzy z nich mają bardzo głupie hasła (pomimo wymagań w rodzaju 20 znaków).

Jeśli nie musisz robić własnego uwierzytelniania użyj OpenID.

Offline Dab

  • Redaktor
    • blog

# Marzec 04, 2010, 12:40:58
Jeżeli ktoś ma te same hasło do wszystkich stron, łącznie z firmowym mailem i kontem w banku to już mu nic nie pomoże.

Offline msieradzki

  • Użytkownik

# Marzec 04, 2010, 13:10:22
Ja mam takie same hasło do całej serii nieistotnych stronek :P. Do banku raczej nikt nie używa tego samego hasła.

Offline Krzysiek K.

  • Redaktor
    • DevKK.net

# Marzec 04, 2010, 13:21:53
Cytuj
Założenie jest takie, że użytkownicy mają te same hasło do innych, ważniejszych stron i niektórzy z nich mają bardzo głupie hasła
No i co z tego wynika dla Twojego serwisu? Myślę, że niewiele, ponieważ:
- jeżeli hasło jest głupie, można je złamać metodą słownikową i nic na to nie poradzisz (poza wymaganiem złożoności hasła, ale to inna historia),
- jeżeli ktoś się włamał na inną stronę i użył tego samego hasła na Twojej, tym bardziej nic nie poradzisz,
- jeżeli ktoś się włamie na Twoją stronę i użyje uzyskanego hasła gdzieś indziej, to już jest wina użytkownika, że ma jedno hasło na wszystko


W przypadku gier online po prostu nie ma potrzeby ochrony hasła tak mocnej, żeby zamulać przez to serwer. :)


Inna kwestia, że użytkownik nie dość, że nie powinien przesyłać do serwera hasła plaintextem, nie powinien też przesyłać do serwera nawet hasha tego hasła, bo hash też można podsłuchać i potem próbować zalogować się do serwera tym samym hashem nawet bez znajomości hasła. W praktycznych protokołach serwer wysyła do klienta identyfikator sesji (coś niepowtarzalnego, np. losową liczbę, czy aktualną datę i godzinę), który klient łączy z hasłem i wysyła hash dopiero całości. Jeżeli do tego identyfikator sesji ustali się w sposób tajny, to system wyjdzie elegancki - są metody kryptograficzne na to, żeby klient i serwer ustalił wspólny identyfikator, a podsłuchujący nie miał szans go wywnioskować z przebiegu komunikacji.

Offline bies

  • Użytkownik

# Marzec 04, 2010, 13:29:05
(...) W praktycznych protokołach serwer wysyła do klienta identyfikator sesji (coś niepowtarzalnego, np. losową liczbę, czy aktualną datę i godzinę), który klient łączy z hasłem i wysyła hash dopiero całości. Jeżeli do tego identyfikator sesji ustali się w sposób tajny, to system wyjdzie elegancki - są metody kryptograficzne na to, żeby klient i serwer ustalił wspólny identyfikator, a podsłuchujący nie miał szans go wywnioskować z przebiegu komunikacji.
W praktycznych protokołach nie duplikuje się warstwy SSL/TLS.

Offline Krzysiek K.

  • Redaktor
    • DevKK.net

# Marzec 04, 2010, 13:39:23
W praktycznych protokołach nie duplikuje się warstwy SSL/TLS.
Jak widać w takim razie POP3 nie jest praktycznym protokołem. ;)

Offline bies

  • Użytkownik

# Marzec 04, 2010, 14:31:09
W praktycznych protokołach nie duplikuje się warstwy SSL/TLS.
Jak widać w takim razie POP3 nie jest praktycznym protokołem. ;)
Nie jest. Używasz jeszcze gdzieś czystego POP3? Chyba wszędzie używa się POP3 owiniętego w SSL/TLS (STARTTLS albo opakowania komunikacji w SSL).

Offline Krzysiek K.

  • Redaktor
    • DevKK.net

# Marzec 04, 2010, 16:54:45
No dobra, ale jeżeli o gamedev i gry online chodzi, to sama dyskusja ma sens, bo łatwiej znaleźć implementację SHA-1 w Action Scripcie, niż implementację całego SSL.

Offline Krolik

  • Użytkownik

# Marzec 04, 2010, 17:05:48
Gdzie można poczytać o tym co piszecie ...  tak czytam te SSL'e SHA-1 ... i nic nie kminie :P. Czy znacie jakies przystepne źródło po polsku gdzie można o tym wszystkim poczytac?

Offline siso

  • Użytkownik

# Marzec 04, 2010, 18:10:34
Internet

Offline bies

  • Użytkownik

# Marzec 04, 2010, 23:40:52
No dobra, ale jeżeli o gamedev i gry online chodzi, to sama dyskusja ma sens, bo łatwiej znaleźć implementację SHA-1 w Action Scripcie, niż implementację całego SSL.
Tia... HTTPS!

Królik: w skrócie strona logowania musi być serwowana tylko przez https://.
« Ostatnia zmiana: Marzec 04, 2010, 23:59:09 wysłana przez bies »