Temat: Zlecę doświadczonemu programiście...
Po pierwsze, to banki internetowe nie umożliwiają autoryzacji za pomocą jakiegokolwiek
hasha z hasła, więc to odpada.
Faktycznie, moja pomyłka (myślałem o autentyfikacji, a napisałem autoryzacja).
Po drugie, kolega powinien wiedzieć, ze md5 jak i sha1 nie są już uznawane
za bezpieczne funkcje hashujące.
Poziom bezpieczeństwa jest wielkością relatywną. Osobiście uważam że jeśli znane i szanowane firmy w dziedzinie bezpieczeństwa (np. VeriSign, Thawte) używają na dzień dzisiejszy algorytmu sha1 (PKCS) to można mu jeszcze ufać.
Są możliwe kolizje, a od kiedy powstały Rainbow Tables, łamanie jest jeszcze łatwiejsze.
Nawet w internecie są dziesiątki serwisów, które oferują odszukanie hasha, czy kolizji.
Jeśli chodzi o Rainbow Tables, to zwiększają one szanse hackera, wtedy gdy system nie wymusza na użytkownikach stosowania bezpiecznych haseł (minimalna długość, użycie małych i wielkich liter oraz cyfr).
Jednak nawet przy luźnej polityce haseł użytkowników można znaczenie zwiększyć bezpieczeństwo dodając entropię do hasła (tzw. salting, wspomniałem o tym w poprzednim poście).
Używanie kilku przejść przez funkcje hashujące też jest dobrym rozwiązaniem.
no i co? Ale będzie mógł zrobić update ze swoim przygotowanym hashem i zalogować się
na konto usera korzystając z innego hasła.
Jeśli włamie się do systemu bazodanowego i będzie posiadał uprawnienia do wykonania UPDATE na tabeli USERS, to kaplica i nic tu nie pomoże.
Gorzej, gdy uzyska dostęp do FTP i zmodyfikuje działanie skryptu tak, by logować
do pliku loginy i hasła użytkowników.
Uruchamianie demona FTP na serwerze produkcyjnym banku jest dosyć ryzykownym posunięciem, a uruchomienie go na publicznym interfejsie sieciowym, to już głupota.
Na systemach produkcyjnych procedura wygląda mniej więcej tak:
svn checkout
https://svn.example.com/...
chown -r httpd:httpd *
chmod -r 0400 *