Jak najlepiej przechowywać informacje o użytkowniku oraz login i hasło użytkownika

Hasła powinny być przechowywane jako hash kryptograficzny, który jest nieodwracalną operacją uniemożliwiającą odczytanie zwykłego tekstu. Podczas uwierzytelniania użytkowników wprowadzanie hasła jest poddawane temu samemu procesowi hashowania i porównywane.

Unikaj używania szybkiego i taniego hasha, takiego jak MD5 lub SHA1; celem jest uczynienie atakującego kosztownym obliczanie tabel tęczowych (na podstawie kolizji hash); szybki hash przeciwdziała temu. Użycie drogiego hasha nie jest problem w przypadku scenariuszy uwierzytelniania, ponieważ nie będzie to miało wpływu na pojedynczy przebieg skrótu.

Oprócz hashowania, sól hash z losowo wygenerowaną wartością; nonce, który jest następnie przechowywany w bazie danych i konkatenowany z danymi przed hashowaniem. Zwiększa to liczbę możliwych kombinacji, które muszą być generowane podczas obliczeń kolizji, a tym samym zwiększa ogólną złożoność czasową generowania tabel tęczowych.

Kolumna hash hasła może być stała długość; Twój hash kryptograficzny powinien wyprowadzać wartości, które mogą być zakodowane na stałą długość, która będzie taka sama dla wszystkich hashów.

W miarę możliwości unikaj włączania własnego mechanizmu uwierzytelniania hasłem; używaj istniejącego rozwiązania, takiego jak bcrypt.

Doskonałe wyjaśnienie, jak postępować z hasłami i czym należy się martwić, można znaleźć na stronie http://www.matasano.com/log/958/enough-with-the-rainbow-tables-what-you-need-to-know-about-secure-password-schemes.

Na koniec pamiętaj, że jeśli atakujący uzyska dostęp do twojej bazy danych, twoim bezpośrednim zmartwieniem powinny być wszelkie poufne lub identyfikujące go informacje, do których może mieć dostęp, oraz wszelkie szkody, jakie mógł wyrządzić.

Nie ma nic złego w umieszczaniu ich w tym samym stole. W rzeczywistości byłoby znacznie szybciej, więc gorąco polecam. Nie wiem, dlaczego chcesz to rozdzielić.

Spróbuję odpowiedzieć na twoje pierwotne pytanie. Posiadanie tego wszystkiego w jednej tabeli jest w porządku, chyba że masz po prostu dużo danych osobowych do zebrania. W takim przypadku może mieć sens rozdzielenie go. Decyzję tę należy podjąć w oparciu o ilość danych osobowych, z którymi masz do czynienia i jak często trzeba uzyskać do nich dostęp.

Powiedziałbym, że przez większość czasu robiłbym coś takiego w jednej tabeli:

UserID, FirstName, LastName, Email, Password, TempPassword

EDIT -- wiesz co, właśnie coś wymyśliłem. Jeśli utworzysz indeks w polu Nazwa użytkownika lub e-mail (w zależności od tego, co wolisz), prawie całkowicie wyeliminujesz wadę wydajności polegającą na tworzeniu tak wielu kolumn w tabeli użytkownika. Mówię tak, ponieważ za każdym razem, gdy się zalogujesz, klauzula WHERE będzie bardzo szybka, aby znaleźć nazwę użytkownika, jeśli ma indeks i nie ma znaczenia, czy masz 100 kolumn w tej tabeli. więc zmieniłem swoje opinia. Umieściłbym wszystko w jednym stole. ;)

W obu przypadkach, ponieważ bezpieczeństwo wydaje się być popularnym tematem, hasło powinno być wartością hash. Sugerowałbym SHA1 (lub SHA256, jeśli naprawdę się tym martwisz). TempPassword powinien również używać hasha i jest tam tylko dla funkcji Zapomniałem hasła. Oczywiście z hash nie można odszyfrować i wysłać użytkownikowi swoje oryginalne hasło. Zamiast tego generujesz tymczasowe hasło, którym mogą się zalogować, a następnie zmuszasz ich do zmiany ich hasło ponownie po zalogowaniu.

Po pierwsze, aby stwierdzić (miejmy nadzieję) oczywiste, jeśli można w jakikolwiek sposób uniknąć przechowywania nazw użytkowników i haseł zrobić to; jest to duża odpowiedzialność i jeśli twój sklep poświadczeń jest naruszony może zapewnić dostęp do wielu innych miejsc dla tych samych użytkowników (ze względu na udostępnianie hasła).

Jeśli musisz przechowywać dane uwierzytelniające:

• nie przechowuj odwracalnej formy; przechowuj hash za pomocą uznanego algorytmu, takiego jak SHA-256. Używać oprogramowania kryptograficznego z renomowanego, godnego zaufania źródła - nie SPRÓBUJ TOCZYĆ WŁASNE, PRAWDOPODOBNIE SIĘ POMYLISZ.
• dla każdego zestawu poświadczeń przechowuj sól wraz z hashowanymi danymi; jest to używane do "prime" hash tak, że dwa identyczne hasła nie wytwarzają tego samego hash - ponieważ daje to, że hasła są takie same.
• Użyj bezpiecznego generatora losowego. Słaba losowość jest główną przyczyną błędów bezpieczeństwa związanych z szyfrowaniem, a nie algorytmów szyfrujących.

Jeśli musisz przechowywać odwracalne referencje:

• Wybierz dobry algorytm szyfrowania-AES-256, 3DES (datowany) lub szyfr klucza publicznego. Używaj oprogramowania kryptograficznego z renomowanego, godnego zaufania źródła - nie próbuj zwijać własnego, prawdopodobnie pomylisz się.
• dla każdego zestawu poświadczeń przechowuj sól (niezaszyfrowaną) wraz z zaszyfrowanymi danymi; jest to używane do "prime" szyfru szyfrującego, tak aby dwa identyczne hasła nie wytwarzały tego samego tekstu zaszyfrowanego - ponieważ daje to, że hasła są to samo.
• Użyj bezpiecznego generatora losowego. Słaba losowość jest główną przyczyną błędów bezpieczeństwa związanych z szyfrowaniem, a nie algorytmów szyfrujących.
• przechowuj klucze szyfrowania / deszyfrowania oddzielnie od bazy danych, w zabezpieczonym pliku O / s, dostępnym tylko dla profilu runtime aplikacji. W ten sposób, jeśli twój DB zostanie naruszony (np. przez SQL injection), Twój klucz nie będzie automatycznie podatny na ataki, ponieważ wymagałoby to dostępu do dysku twardego w ogóle. Jeśli twój O / S obsługuje szyfrowanie plików powiązane z profilem, użyj go - może tylko pomóc i jest ogólnie przejrzyste (np. szyfrowanie NTFS).
• jeśli jest to praktyczne, przechowuj klucze same zaszyfrowane hasłem głównym. Zazwyczaj oznacza to Twoją aplikację. potrzebne będzie to hasło z kluczem przy starcie-nie ma sensu podawać go w parametrze ze skryptu, ponieważ jeśli dysk twardy zostanie naruszony, musisz założyć, że zarówno plik klucza, jak i skrypt mogą być wyświetlane.
• Jeśli nazwa użytkownika nie jest konieczna do zlokalizowania konta rekord Szyfruj zarówno nazwę Użytkownika, jak i hasło.

Z mojego doświadczenia wynika, że przechowywanie danych osobowych i danych logowania w poszczególnych bazach danych jest najlepszą praktyką w tym przypadku. Powodem jest to, że jeśli ma miejsce wstrzyknięcie SQL, jest ono ograniczone (chyba że infiltrator zna wewnętrzny układ bazy danych) do tabeli, do której odnoszą się dane, w przeciwieństwie do zapewnienia dostępu do całego konglomeratu danych.

Należy jednak pamiętać, że może to nastąpić kosztem konieczności wykonania większej liczby zapytań, stąd wydajność hit.

Czy wszystkie te dane zawsze będą miały relację 1: 1 z użytkownikiem? Jeśli możesz forsee zezwalając użytkownikom na wiele adresów, numerów telefonów, itp, to możesz chcieć wyłożyć dane osobowe do osobnej tabeli.

Należy przechowywać je w tej samej tabeli i używać szyfrowania jednokierunkowego. MD5 będzie działać, ale jest słaby, więc można rozważyć coś w rodzaju SHA1 lub innej metody. Nie ma korzyści z przechowywania 2 pozycji w oddzielnych tabelach.