Najlepszy sposób na przechowywanie hasła w bazie danych [zamknięty]

Background Nigdy ... naprawdę ... musisz znać hasło użytkownika. Chcesz tylko zweryfikować, że przychodzący użytkownik zna hasło do konta.

Hash It: Przechowuj hashowane hasła użytkowników (szyfrowanie jednokierunkowe) za pomocą silnej funkcji skrótu. Wyszukiwanie "C# encrypt passwords" daje mnóstwo przykładów.

Zobacz online SHA1 hash creator aby dowiedzieć się, co generuje funkcja haszująca (ale nie używaj SHA1 jako funkcji haszującej, użyj czegoś mocniejszego takich jak SHA256).

Teraz hashowane hasło oznacza, że ty (i złodzieje baz danych) nie powinieneś być w stanie odwrócić tego hasha z powrotem do oryginalnego hasła.

Jak go używać: Ale jak mam użyć tego zmasowanego hasła przechowywanego w bazie danych?

Kiedy użytkownik się zaloguje, poda ci nazwę użytkownika i hasło (w oryginalnym tekście) Wystarczy użyć tego samego kodu hashowego, aby hashować wpisane hasło, aby uzyskać zapisaną wersję.

Więc porównaj te dwa hashed passwords(hash bazy danych dla nazwy użytkownika i wpisanego & hashed password). Możesz sprawdzić, czy "co wpisali" pasowało "co oryginalny użytkownik wprowadził dla swojego hasła", porównując ich skróty.

Extra kredyt:

pytanie: gdybym miał twoją bazę danych, to czy nie mógłbym po prostu wziąć krakera jak John Rozpruwacz i zacząć robić hasze, dopóki nie znajdę dopasowania do Twoich przechowywanych, zahaszowanych haseł? (ponieważ użytkownicy wybierają krótkie, słownikowe słowa i tak ... powinno be easy)

Odpowiedź: Tak ... tak, mogą.

Więc powinieneś "posolić" swoje hasła. Zobacz artykuł na Wikipedii o soli

Zobacz " jak hashować dane za pomocą salt " C# przykład

Jako hash utwardzony kluczem, przy użyciu bezpiecznego algorytmu, takiego jak sha-512.

Najlepszą praktyką bezpieczeństwa jest nie przechowywanie hasła w ogóle( nawet nie zaszyfrowane), ale przechowywanie solonego hasha (z unikalną solą na hasło) zaszyfrowanego hasła.

W ten sposób odzyskanie hasła ze zwykłego tekstu jest (praktycznie) niemożliwe.

Polecam przeczytać artykuły dość z tęczowymi tabelami: co musisz wiedzieć o bezpiecznych schematach haseł [martwy link, Skopiuj z Internet Archive] i Jak bezpiecznie przechowywać hasło.

Wielu programistów, w tym ja, myśli, że rozumie Bezpieczeństwo i haszowanie. Niestety większość z nas po prostu nie.

Może jestem nieco off-topic, jak wspomniałeś o potrzebie nazwy użytkownika i hasła, a moje zrozumienie problemu nie jest co prawda najlepsze, ale czy OpenID jest czymś wartym rozważenia?

Jeśli używasz OpenID, to nie przechowujesz żadnych poświadczeń, jeśli dobrze rozumiem technologię i użytkownicy mogą używać poświadczeń, które już mają, unikając potrzeby tworzenia nowej tożsamości, która jest specyficzna dla Twojej aplikacji.

To może nie być odpowiednie, jeśli aplikacja, o której mowa, jest wyłącznie do użytku wewnętrznego

RPX zapewnia łatwy sposób na zintegrowanie obsługi OpenID z aplikacją.

W Twoim scenariuszu możesz rzucić okiem na asp.net członkostwo, dobrą praktyką jest przechowywanie hasła użytkownika jako zaszyfrowanego ciągu w bazie danych. możesz uwierzytelnić użytkownika, porównując zahaszowane hasło przychodzące z hasłem przechowywanym w bazie danych.

Wszystko zostało zbudowane do tego celu, sprawdź asp.net członkostwo

Chciałbym MD5 / SHA1 hasło, jeśli nie trzeba być w stanie odwrócić hash. Kiedy użytkownicy logują się, możesz po prostu zaszyfrować podane hasło i porównać je z Hashem. Kolizje Hash są prawie niemożliwe w tym przypadku, chyba że ktoś uzyska dostęp do bazy danych i zobaczy hash, dla którego już miał kolizję.