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

Pracuję nad projektem, który musi mieć uwierzytelnianie (nazwa użytkownika i hasło)

Łączy się również z bazą danych, więc pomyślałem, że przechowam tam nazwę użytkownika i hasło. Wydaje się jednak, że posiadanie haseł nie jest dobrym pomysłem, jak pole tekstowe w tabeli siedzącej w bazie danych.

Używam C # i łączę się z serwerem ekspresowym 2008. Czy ktoś może zasugerować (z jak największą liczbą przykładów), jaki byłby najlepszy sposób przechowywania tego typu danych?

PS Jestem otwarty na pomysł, aby te informacje nie były przechowywane w bazie danych, jeśli można podać dobry powód

Masz rację, że przechowywanie hasła w polu tekstowym to okropny pomysł. Jednak, jeśli chodzi o lokalizację , w większości przypadków, które napotkasz (i szczerze mówiąc, nie mogę wymyślić żadnych kontrprzykładów), przechowywanie reprezentacji hasła w bazie danych jest właściwe. Przez reprezentację to znaczy, że chcesz hash hasła przy użyciu soli (która powinna być inna dla każdego użytkownika) i bezpieczny algorytm 1-way i sklep , który , wyrzucać oryginalnego hasła. Następnie, gdy chcesz zweryfikować hasło, haszujesz wartość (używając tego samego algorytmu haszującego i soli) i porównujesz ją z wartością haszowaną w bazie danych.

Chociaż dobrze jest o tym myśleć i jest to dobre pytanie, w rzeczywistości jest to duplikat tych pytań (przynajmniej):

• Jak najlepiej przechowywać informacje o użytkowniku oraz login i hasło użytkownika
• Najlepsze praktyki dotyczące przechowywania haseł do baz danych
• Solenie hasła: najlepsze praktyki?
• Czy kiedykolwiek można przechowywać hasło w postaci zwykłego tekstu w zmiennej php lub stałej php?

Aby wyjaśnić nieco więcej na temat bitu solenia, istnieje niebezpieczeństwo, że po prostu wyszyfrujesz hasło i zapiszesz to, że jeśli intruz przejmie twoją bazę danych, może nadal używać tak zwanych tęczowych tabel, aby móc „odszyfrować” hasło (przynajmniej te, które pojawiają się w tabeli tęczy). Aby obejść ten problem, programiści dodają sól do haseł, która, jeśli jest właściwie wykonana, sprawia, że ​​ataki tęczy są po prostu niewykonalne. Zauważ, że powszechnym nieporozumieniem jest po prostu dodanie tego samego unikalnego i długiego ciągu do wszystkich haseł; chociaż nie jest to okropne , najlepiej jest dodawać unikalne sole do każdego hasła. Przeczytaj to, aby uzyskać więcej.

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

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

Zobacz online twórcę skrótów SHA1, aby dowiedzieć się, co wytwarza funkcja skrótu (ale nie używaj SHA1 jako funkcji skrótu, użyj czegoś silniejszego, takiego jak SHA256).

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

Jak z tego korzystać: Ale, jak mówisz, jak korzystać z tego zmasowanego hasła przechowywanego w bazie danych?

Gdy użytkownik się zaloguje, poda Ci nazwę użytkownika i hasło (w oryginalnym tekście). Wystarczy użyć tego samego kodu skrótu, aby zakodować to wpisane hasło, aby uzyskać zapisaną wersję.

Porównaj więc dwa hashowane hasła (hash bazy danych dla nazwy użytkownika oraz wpisanego i hashowanego hasła). Możesz sprawdzić, czy „to, co wpisali”, „pasuje” do tego, co wprowadził pierwotny użytkownik dla swojego hasła ”, porównując ich skróty.

Dodatkowy kredyt:

Pytanie: Gdybym miał twoją bazę danych, czy nie mógłbym po prostu wziąć crackera takiego jak John the Ripper i zacząć tworzyć skróty, dopóki nie znajdę pasujących do zapisanych, zakodowanych haseł? (ponieważ użytkownicy wybierają krótkie, słownikowe słowa i tak ... powinno być łatwo)

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

Powinieneś więc „zasolić” swoje hasła. Zobacz artykuł Wikipedii na temat soli

Zobacz przykład „Jak mieszać dane za pomocą soli” w C #

Jako zahartowany solą skrót, wykorzystujący bezpieczny algorytm, taki jak sha-512.

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

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

Całkowicie polecam przeczytanie artykułów „ Wystarczy Tęczowe tablice: Co musisz wiedzieć o bezpiecznych schematach haseł [martwy link, kopia w archiwum internetowym ] i jak bezpiecznie przechowywać hasło .

Wielu programistów, łącznie ze mną, myśli, że rozumie bezpieczeństwo i mieszanie. Niestety większość z nas po prostu tego nie robi.

Mogę być nieco nie na temat, ponieważ wspomniałeś o potrzebie nazwy użytkownika i hasła, a moje zrozumienie problemu nie jest wprawdzie najlepsze, ale czy OpenID jest czymś, co warto rozważyć?

Jeśli użyjesz OpenID, w ogóle nie przechowujesz żadnych poświadczeń, jeśli dobrze rozumiem technologię, a użytkownicy mogą korzystać z poświadczeń, które już posiadają, unikając potrzeby tworzenia nowej tożsamości, która będzie specyficzna dla Twojej aplikacji.

Może jednak nie być odpowiedni, jeśli dana aplikacja jest przeznaczona wyłącznie do użytku wewnętrznego

RPX zapewnia łatwy i łatwy sposób zintegrowania obsługi OpenID z aplikacją.

W twoim scenariuszu możesz spojrzeć na członkostwo asp.net, dobrą praktyką jest przechowywanie hasła użytkownika jako łańcucha mieszanego w bazie danych. możesz uwierzytelnić użytkownika, porównując zakodowane hasło przychodzące z hasłem przechowywanym w bazie danych.

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

Chciałbym MD5 / SHA1 hasło, jeśli nie musisz mieć możliwości cofnięcia skrótu. Kiedy użytkownicy logują się, możesz po prostu zaszyfrować podane hasło i porównać je z hashem. W tym przypadku kolizje mieszania są prawie niemożliwe, chyba że ktoś uzyska dostęp do bazy danych i zobaczy skrót, dla którego już ma kolizję.