Archiwum działu Ogólne (posty do 12.2007) - Ulepszenie kodowania hasel w bazie danych
flash-chat - 10-05-2006, 12:31
Trzeba się zastanowić nad tym czy zmieniając sposób logowania na 10000*MD5 nie zostawiasz nowej luki bezpieczeństwa - DoS - w sytuacji gdy ktoś specjalnie loguje się nieprawidłowo w kółko.
Co do "kompatybilności" wstecz to sądzę że jak zawsze - jeśli nie da się tego jednoznacznie ustalić to trzeba administratorom (użytkownikom) dać możliwość zainstalowania jakiegoś PasswordSecurity MOD (który jest domyślnie wyłączony) z wyraźnym ostrzeżeniem że jego instalacja jest NIEODWRACALNA.
Jeśli chodzi o poprawienie bezpieczeństwa to ja osobiście proponuje się przerzucić z MD5 na SHA256 (niestety tracąc kompatybilność). Implementacje w PHP na pewno w necie są.
Myślę że jeśli mamy chronić użytkowników przed "adminem" albo kimś podobnym to sytuacja jest niestety dość beznadziejna. Jak już ktoś wcześniej wspominał zawsze dla innej metody (niezależnie od tego jak długiej i zawikłanej) można wygenerować słownik. A porównanie ze słownikiem to już nie problem.
Chociaż z drugiej strony poprzeczka wtedy na pewno NIECO wzrasta (tylko czy na pewno na tyle żeby chronić przed głupim i nieodpowiedzialnym adminem? trzeba sobie odpowiedzieć na pytanie: czy człowiek który bardzo dobrze zna PHP, MD5, BASE64, SQL'a, JS i dodatkowo zagadnienia z bezpieczeństwem - tzn. mając taką wiedzę żeby potrafił to złamać będzie nad tym w ogóle siedział? Człowiek z taką wiedzą ma IMO wiele ciekawszych rzeczy do roboty za które mu zresztą dobrze płacą jak jest specjalistą od tych dziedzin) - odpadają wtedy wszystkie 'powszechnie' dostępne słowniki dla głupich adminów.
Jeśli chodzi o inne bardziej "wyrafinowane" metody ale bez zbytniej kompilacji to akurat ten temat tutaj nie jest dobrym miejscem żeby wypisywać 'DOBRE' pomysły
Niektórzy użytkownicy zawsze pozostaną głupi i naprawdę ciężko na to cokolwiek poradzić. Jeśli macie swoje fora to sprawdźcie sobie ile % użytkowników ma hasła w postaci pass == md5(login).
A w ogóle to przydałoby się żeby co jakiś czas w tych ciekawszych tematach robić podsumowania (jakiś admin czy moderator czy coś) - bo żeby się wypowiedzieć sensownie trzeba wszystko dokładnie przeczytać. Mógłby ktoś co N stron pisać podsumowanie w stylu:
"X proponuje rozwiązanie oparte na blabla. Y argumentuje że ważna jest kompatybilność wstecz bo...." itp. Ewentualnie jeszcze z odnośnikami do konkretnych postów.
Sorry za 'Kotleta'.
Crack - 10-05-2006, 14:35
Cytat: | Co do "kompatybilności" wstecz to sądzę że jak zawsze - jeśli nie da się tego jednoznacznie ustalić to trzeba administratorom (użytkownikom) dać możliwość zainstalowania jakiegoś PasswordSecurity MOD (który jest domyślnie wyłączony) z wyraźnym ostrzeżeniem że jego instalacja jest NIEODWRACALNA. |
Myślisz że ktoś przeczyta ten komunikat? Zajmij się pomocą techniczną a zrozumiesz co mam na myśli.
flash-chat napisał/a: | Jak już ktoś wcześniej wspominał zawsze dla innej metody (niezależnie od tego jak długiej i zawikłanej) można wygenerować słownik. |
Pociesz się tym że generowanie wymaga posiadania całej sieci i przetwarzania rozproszonego. Inaczej życzę miłej zabawy dla haseł powyżej 7 znaków.
flash-chat napisał/a: | Niektórzy użytkownicy zawsze pozostaną głupi i naprawdę ciężko na to cokolwiek poradzić. Jeśli macie swoje fora to sprawdźcie sobie ile % użytkowników ma hasła w postaci pass == md5(login). |
Na takich nic nie poradzisz, sami będą sobie winni. Ich tok myślenia wygląda mniej więcej tak: "skąd ktoś ma wiedzieć że mój pies ma na imię burek".
Co do podsumowania, moje przemyslenia:
Sposób na tablice:
1. Hasła zakodowane w jakikolwiek inny sposób niż czyste sha1 lub md5, może być to nawet dolepienie czegokolwiek do hasła (byle był to znak spoza alfanumerycznych), może to być podwójne kodowanie (tablice są ale niepełne i tylko komercyjne)
2. Wymuszenie bardziej złożonych haseł - conajmniej 7 znaków, w tym jedna cyfra. Najlepiej 8 znaków i więcej
3. Tracisz kompatybilność wstecz, chyba że napiszesz konwerter wyłapujący stare hasła i zamieniający na nowe. Konwersję można wykonać w sposób niezauważalny dla użytkownika, zmieniając hash w bazie danych po pierwszym udanym logowaniu (a)
Sposób na "admina" znającego się trochę na PHP, który spróbuje przechwycić hasło:
1. Szyfrowanie haseł jeszcze po stronie użytkownika za pomocą JS - odpowiednia biblioteka była już wspominana - zapobiega to przejęciu snifferem albo odczytaniu z PHP jeszcze przed zakodowaniem.
Sposób na podsłuchiwanie transferu (życzliwy "admin" z sieci lokalnej ze znifferem):
1. Zamiast 1 można zastosować HTTPS - niestety to kosztuje, chyba że ktoś chce mieć ciągle informację o niezaufanym certyfikacie.
Najskuteczniejsze wydaje mi się szyfrowanie haseł biblioteką JS po stronie użytkownika w jakiś niestandardowy sposób, np. 2 razy md5 (dla drugiego md5 najlepiej sprowadzić pierwszy wynik z zapisu hex na zwykłe znaki). Jeśli dobrze pamiętam właśnie tak robi vBulletin.
|
|
|