2009-05-18 20 views
39

Jaka jest zalecana praktyka przechowywania haseł użytkowników w SQL Server 2008?przechowywanie haseł w SQL Server

Przechowuję dane użytkownika dla intranetu i chciałbym uzyskać porady na temat najlepszego sposobu przechowywania danych użytkownika, takich jak nazwa, hasło i uprawnienia dostępu użytkownika itp. Myślę o utworzeniu kolumny nvarchar, a następnie zaszyfrowaniu tego tekst przed wstawieniem do tabeli.

+2

Jeśli jest to domena AD, czy nie możesz pozwolić AD na uwierzytelnianie? – Rytmis

+0

Dziękuję wszystkim za sugestie. Richard – Richard

Odpowiedz

2

to na ogół sposób na zrobienie tego.

Twoja aplikacja będzie obsługiwać szyfrowanie (i opcjonalnie odszyfrowywanie), baza danych po prostu zapisze hasło.

Polecam używanie czegoś mocniejszego niż datowanego defacto - MD5

Większość .net deweloperzy wydają się jak za pomocą TDES

+0

Zgodziłbym się, że chcesz iść z czymś silniejszym niż MD5, kiedy możesz –

+3

MD5 nie jest algorytmem szyfrowania, jest to algorytm mieszający. http://en.wikipedia.org/wiki/MD5 –

+0

Uzgodnione. Domyślam się, że nie byłam wyraźna, więc dostałeś górę :) –

2

T-SQL zawiera funkcje szyfrowania - 4Guys miał good article on it for SQL Server 2005 aa czas temu ale myślę, że wszystko nadal obowiązuje do 2008 roku.

+0

Ten artykuł dotyczy szyfrowania kluczem symetrycznym. Hasła powinny być mieszane. – Swoogan

+0

Zgadzam się - artykuł, z którym się łączyłem jest znacznie przestarzały. To dlatego ja osobiście przegłosowałem odpowiedź elazar-leibovicha powyżej. –

7

Szyfrowanie w przypadku wrażliwych danych jest dobre. Jednak przy użyciu haseł nigdy nie powinieneś znać oryginalnej wartości, a ponieważ wszystko, co jest zaszyfrowane, może zostać odszyfrowane, narażasz te informacje na niebezpieczeństwo odkrycia.

Zamiast tego należy zachować skrót hasła. Ten proces ma wartość i generuje bardzo skomplikowaną sumę kontrolną. Biorąc pod uwagę liczbę, nie ma możliwości powrotu do pierwotnego hasła, co zwiększa bezpieczeństwo takich informacji. Jeśli chcesz się dowiedzieć, czy ktoś podał Ci poprawne hasło, otrzymasz wartość, którą ci dali i porównali skróty.

Bezpieczeństwo to skomplikowany temat. Nawet z hashe, możesz skończyć na systemie, który ma poważne wady bezpieczeństwa. Uzyskanie pomocy konsultanta ds. Bezpieczeństwa nie jest złym pomysłem, jeśli nikt inny w twoim zespole nie ma już tego rodzaju wiedzy.

+1

Bardzo prawdziwe w większości przypadków. Biorąc pod uwagę, że OP korzysta z intranetu, mogą zaistnieć okoliczności (integracja z innymi aplikacjami w intranecie, które wymagają logowania), gdzie przydatna jest możliwość odzyskania hasła. –

53

Zwykłym sposobem na przechowywanie hasła jest użycie funkcji hash na haśle, ale wcześniej do salt. Ważne jest, aby "solić" hasło, aby bronić się przed atakami rainbow table.

Więc twój stół powinien wyglądać podobnie do tego

._______._________________.______________. 
|user_id|hash    |salt   | 
|-------|-----------------|--------------| 
|12  |[email protected]|13%!#tQ!#3t...| 
|  |...    |...   | 

Podczas sprawdzania, czy dana hasło odpowiada użytkownikowi, należy złączyć sól do podanego hasła, i obliczyć funkcji skrótu łańcucha wynikowego. Jeśli wynik funkcji mieszania jest zgodny z kolumną hash - jest to poprawne hasło.

Ważne jest, aby zrozumieć, że idea "salt-hash" ma konkretny powód - uniemożliwienie każdemu, kto ma dostęp do bazy danych, znajomości hasła (uznanie za problematyczny problem z odwróceniem funkcji skrótu). Na przykład DBA banku nie będzie mógł zalogować się na twoje konto bankowe, nawet jeśli ma dostęp do wszystkich kolumn.

Należy również rozważyć użycie go, jeśli uważasz, że użytkownicy będą używać poufnego hasła (na przykład hasła do konta Gmail) jako hasła do Twojej witryny.

IMHO nie zawsze jest potrzebna do zabezpieczenia. Więc powinieneś pomyśleć, czy tego chcesz, czy nie.

Zobacz dobre podsumowanie tego mechanizmu pod numerem this article.

Aktualizacja: Warto wspomnieć, że na dodatkowe zabezpieczenie przed ukierunkowanego ataku na odwrócenie indywidualne hasło użytkownika skrótu, należy use bcrypt, które mogą być dowolnie trudne do wyliczenia. (Ale jeśli naprawdę nie boisz się tajemniczego mężczyzny w czerni celującego w twoją konkretną bazę danych, myślę, że sha1 jest wystarczająco dobry.Nie wprowadziłbym innej zależności dla mojego projektu dla tego dodatkowego zabezpieczenia.Także, nie ma powodu, aby nie używać sha1 100 razy, co dałoby podobny efekt).

+4

powyższy link nie działa, ale [to] (http://msdn.microsoft.com/en-us/library/ff649202.aspx) jeden robi. – JumpingJezza

+1

@JumpingJezza, dziękuję, kiedyś działało, aktualizuję link –