Dlaczego hasła powinny być szyfrowane, jeśli są przechowywane w bezpiecznej bazie danych?

Mam serwis internetowy. W tej chwili mam hasła zapisane w postaci zwykłego tekstu w tabeli MySQL na moim serwerze. Wiem, że to nie jest najlepsza praktyka i dlatego nad nią pracuję.

Dlaczego hasła powinny być szyfrowane, jeśli są przechowywane w bezpiecznej bazie danych? Zdaję sobie sprawę, że jeśli ktoś włamie się do mojej bazy danych, dostanie hasło każdego. Ale mam inne problemy, jeśli ktoś dostanie się do mojej bazy danych, na przykład usuwając dane.

Mogę wymyślić scenariusz polegający na zhakowaniu. Przywracasz bazę danych sprzed kilku godzin i wszystko jest w porządku. Jeśli jednak hasła są jawne ... Złodziej ma wszystkie hasła i musisz je zresetować. Kłopoty z użytkownikami.

Jeśli hasła zostały zaszyfrowane, możesz po prostu przywrócić poprzednią bazę danych. Czy to prawidłowe myślenie?

Po pierwsze, powinieneś być bardziej wolny z prawem dostępu tylko do odczytu niż do odczytu i zapisu. Możliwe, że haker ma dostęp do twoich danych, ale nie jest w stanie ich edytować.

Ale, co ważniejsze, nie chodzi o ciebie. Fakt, że ktoś może mieć kłopoty, jeśli ktoś ma pełny dostęp do bazy danych, nie ma znaczenia. Znacznie ważniejsze są dane użytkownika.

Jeśli odzyskasz bazę danych, haker nadal ma dostęp do konta użytkownika.

A kto wie co jeszcze? Co jeśli użyją tego samego hasła w Google? Czy PayPal? Co się stanie, jeśli da to hakerowi dostęp do panieńskiego nazwiska matki lub ostatnich 4 cyfr karty kredytowej?

Co się stanie, jeśli przeniesie je to na inne konta? Nie wkładaj hakera, aby przejść przez system wsparcia użytkownika i uzyskać więcej informacji .

Po prostu ... po prostu nie. To są prywatne informacje o użytkowniku i nie musisz ich widzieć. To także twoja reputacja. Zaszyfruj to.

EDYCJA: Jeden dodatkowy komentarz, aby zapisać przyszłego czytelnika przed przeczytaniem każdej odpowiedzi i komentarza ...

Jeśli zamierzasz szyfrować (w ścisłym tego słowa znaczeniu), musisz użyć pary kluczy publiczny / prywatny , co jest w porządku, ale utrudnia życie zarówno tobie, jak i użytkownikowi.

Prostszym i równie skutecznym rozwiązaniem jest losowe posolenie i zaszyfrowanie hasła. Sam haszowanie nie wystarczy; jeśli użytkownik używa wspólnego hasła, pojawi się ono w tabelach mieszania wstecznego, które są łatwo dostępne za pomocą prostego wyszukiwania w Internecie.

Jeśli zostaniesz zhakowany, możesz przywrócić witrynę z kopii zapasowych i naprawić ją. Ale haker wciąż ma hasła do wszystkich kont! Istnieją udokumentowane przykłady tego, co się dzieje w świecie rzeczywistym (Sony, Linked-in), w którym gdyby tabele haseł zostały odpowiednio zaszyfrowane i solone, szybkie zabezpieczenie i przywrócenie usługi byłoby znacznie łatwiejsze.

Prawdopodobnie dobrym pomysłem jest założenie, że zostaniesz zhakowany, a także zaprojektuj strategię tworzenia kopii zapasowych i zaszyfruj poufne dane, mając to na uwadze. I to nie tylko hakerzy, przed którymi musisz chronić. Niezadowoleni, nieuczciwi lub po prostu nieświadomi pracownicy mogą rozdawać hasła w postaci zwykłego tekstu.

Bez mieszania będziesz musiał wyłączyć dostęp dla wszystkich, dopóki nie zmienią swojego hasła (co, nawet jeśli to możliwe, będzie ogromnym bólem głowy dla wszystkich). Gdyby hasła zostały zaszyfrowane i solone, można przywrócić serwis internetowy, a atakującemu byłoby znacznie trudniej uzyskać dostęp do kont użytkowników.

Właściwie zakodowane i słone hasło jest w zasadzie jednokierunkowe. Nie można łatwo odgadnąć hasła na podstawie zaszyfrowanego hasła. Nawet ty, ponieważ usługodawca nie będzie w stanie zgadnąć, możesz tylko zresetować.

Ponadto, jak powiedział Elin, nie próbuj rzucać własnym hashem (lub szyfrowaniem). Użyj standardowej biblioteki.

Mam jednak inne problemy, jeśli ktoś dostanie się do mojej bazy danych, np. Usunięcie danych.

Nie chodzi o problemy, które masz, chodzi o problemy, które mogą powodować dla wszystkich innych użytkowników. Chodzi o usunięcie pokusy (lub, co gorsza, potencjalnej odpowiedzialności) osób pracujących w witrynie, aby nadużywać przechowywanych tam danych.

Widzisz, chociaż ludzie powinni używać różnych haseł w różnych systemach, w rzeczywistości tak nie jest .

... a ponieważ hashowanie haseł jest tak łatwe, nie masz usprawiedliwienia dla nieprzestrzegania najlepszych praktyk branżowych.

Zauważalne ataki, takie jak usuwanie danych, są zwykle sprawą amatorów i są najmniejszymi zmartwieniami. Jedną z pierwszych rzeczy, które zrobi doświadczony atakujący, jest próba uzyskania legalnego dostępu, więc nawet jeśli załatasz pierwotną lukę, której użył, nadal będzie mógł się dostać. Robi wszystko, co możliwe, aby uniknąć zwracania na siebie uwagi, dopóki spełnia to, czego pragnie. Pozostawienie haseł bez skrępowania sprawiło, że jego praca stała się znacznie łatwiejsza. Utrudniasz także wykrywanie i izolowanie jego przyszłych złośliwych zachowań.

Ponadto nie wszystkie kompromisy zapewniają pełny dostęp do powłoki. Co jeśli podatność wykorzystana przez atakującego jest tylko zastrzykiem SQL tylko do odczytu na usersstole? Pozostawienie haseł bez skrępowania dało mu prawie pełny dostęp.

To oprócz powodów podanych w innych odpowiedziach dotyczących twojej odpowiedzialności za ochronę danych użytkowników. Chodzi mi o to, że nie tylko użytkownicy mają coś do stracenia.

Muszę tu opublikować odpowiedź na błąd w samym pytaniu. Pytasz, czy hasła powinny być szyfrowane. Nikt nie szyfruje haseł; nikt, z wyjątkiem usług i programów takich jak Firefox Sync i Roboform, których jedynym celem jest szyfrowanie haseł.

Rzućmy okiem na definicje:

W kryptografii szyfrowanie to proces kodowania wiadomości (lub informacji) w taki sposób, że tylko uprawnione strony mogą je odczytać.

I mieszanie:

Funkcja skrótu to dowolny algorytm odwzorowujący dane o dowolnej długości na dane o stałej długości.

Innymi słowy, szyfrowanie jest konwersją dwukierunkową, a hashowanie jest konwersją jednokierunkową , więc jeśli nie odszyfrujesz ich później, nie jest to szyfrowanie.

Nie tylko hash, sól ! Przeczytaj całą stronę, zanim zaszyfrujesz swoje hasła.

Jeśli chodzi o algorytmy haszujące, nad którymi obecnie analizuje OP, sugerowałbym dowolny z wysokiej klasy wariantów SHA-2, taki jak SHA-384 lub SHA-512.

I upewnij się, że używasz rund mieszania . Nie mieszaj raz, mieszaj wiele razy.

Rozważ przeczytanie tej strony, aby bardziej zabezpieczyć proces logowania.

Po drugie, twoja baza danych nigdy nie będzie wystarczająco bezpieczna. Zawsze będą dziury w zabezpieczeniach i stale ewoluujące zagrożenia. Powinieneś przestrzegać prawa Murphy'ego i zawsze przygotowywać się na najgorszą ewentualność.

Do innych punktów PDR marki są dokładnie co jeszcze chciałbym powiedzieć: ludzie, którzy używają tego samego hasła dla każdej strony internetowej, hakerami wykorzystujące socjotechnikę, aby uzyskać więcej informacji, itd. Itd.

Stawką jest tutaj ważna zasada. Jest tylko jedna osoba, która ma firmę znającą hasło użytkownika. To jest użytkownik. Ani ich żona / mąż, ich lekarz, a nawet ksiądz.

Na pewno nie obejmuje programisty, administratora bazy danych ani technika systemowego odpowiedzialnego za używaną usługę. To stwarza wyzwanie, ponieważ programista ma obowiązek odebrania dowodu, że użytkownik faktycznie zna hasło, co nie jest trywialnym problemem do rozwiązania w czysty sposób.

Czystym rozwiązaniem jest posiadanie mechanizmu, w którym użytkownik jest proszony o nowe i nieprzewidywalne dane, a następnie musi zwracać odpowiedź opartą na tych danych i haśle. Jedną z implementacji tego byłoby poproszenie użytkownika o cyfrowe podpisanie niektórych nowo wygenerowanych danych swoim podpisem cyfrowym, a my moglibyśmy matematycznie udowodnić, że użyli tej samej pary kluczy kryptograficznych, której użyli pierwotnie do utworzenia konta.

W praktyce czyste rozwiązania wymagają znacznej infrastruktury i przetwarzania po stronie klienta, a dla wielu stron internetowych często nie jest to właściwe dla ochrony danych.

Bardziej powszechnym rozwiązaniem byłoby:

W momencie pierwszego otrzymania hasła w aplikacji, hasło jest przekazywane do funkcji skrótu wraz z losową wartością „soli” aplikacji w funkcji skrótu.

Oryginalny ciąg jest następnie nadpisywany w pamięci i od tego momentu solony skrót jest przechowywany w bazie danych lub porównywany z rekordem bazy danych.

Kluczowymi aspektami zapewniającymi bezpieczeństwo są tutaj:

1. Znajomość skrótu nie zapewnia bezpośredniego uwierzytelnienia.
2. Odwrotne obliczanie hasła z skrótu jest niepraktyczne.
3. Korzystanie z tęczowych tabel (długich list haseł i ich obliczonych skrótów) jest trudniejsze, ponieważ wynikowy skrót zależy zarówno od nazwy użytkownika, jak i hasła.

Musisz „zaszyfrować” (a właściwie „hash”, aby uzyskać właściwe pojęcie mieszania) hasła jako drugą warstwę obrony : ma to na celu zapobiec eskalacji bazy danych przez osobę atakującą, która dostrzegła bazę danych tylko do odczytu że dostęp do odczytu i zapisu, a dokładnie, zaczynają zmieniać dane. Częściowe naruszenia tylko do odczytu mają miejsce w prawdziwym świecie, np. Poprzez atak typu SQL injection z konta z dostępem tylko do odczytu lub poprzez odzyskanie odrzuconego dysku twardego lub starej taśmy kopii zapasowej ze śmietnika. Tam obszernie pisałem na ten temat .

Jeśli chodzi o właściwe sposoby mieszania haseł, zobacz tę odpowiedź . Dotyczy to soli, iteracji, a przede wszystkim nie wymyślania własnych algorytmów (domowa kryptografia to pewna recepta na katastrofę).

Nie powtórzę tego, co powiedzieli inni ludzie, ale zakładając, że masz PHP 5.3.8 lub nowszy, powinieneś używać natywnego PHP bcryptdo przechowywania swoich haseł. Jest to wbudowane w PHP. Jeśli masz PHP 5.5, możesz użyć najlepszej dostępnej stałej hasła. Możesz także użyć biblioteki, aby 5.3.8 lub lepiej zachowywać się jak 5.5.

Pytanie o przepełnienie stosu Jak używasz bcrypt do mieszania haseł w PHP? wyjaśnia to, a pozostałe odpowiedzi wyjaśniają więcej. Nie próbuj robić tego samemu.

Zgadzam się z odpowiedzią pdr z powodów podanych w tej odpowiedzi.

Dodałbym, co następuje: powinieneś to zrobić, ponieważ jest to łatwe i ogólnie przyjęte jako najlepsza praktyka dla każdego zastosowania. Mówiąc dokładniej, hasła powinny zawsze być solone i mieszane przed zapisaniem w dowolnym trwałym magazynie. Oto dobre odniesienie do znaczenia solenia i wyboru dobrego skrótu kryptograficznego (który zapewnia również bezpłatny kod źródłowy w kilku popularnych językach): https://crackstation.net/hashing-security.htm

Niewielka ilość dodatkowego czasu na programowanie jest warta ochrony, jaką zapewnia użytkownikom, oraz reputacji programisty.

Mogę wymyślić scenariusz polegający na zhakowaniu.

Kolejny scenariusz, o którym musisz pomyśleć: ktoś poślizgnął się na Twoim DBA (lub ktokolwiek inny może uruchomić wybrane zapytania na Twoim DB) 100 USD, aby dać im hasła użytkowników. Lub inżynierowie społeczni, aby to zrobić.

Następnie używają tych haseł, aby zalogować się do Gmaila użytkownika ... lub witryny handlowej ... (ponieważ ludzie są ... mniej inteligentni, powiedzmy - i używają tego samego hasła we wszystkich witrynach).

Zirytowany użytkownik pozywa Twoją firmę za ujawnienie hasła.

NIKT (w tym osoby w Twojej firmie) nie powinien być w stanie odczytać hasła w postaci zwykłego tekstu. Zawsze. Nie ma uzasadnionej potrzeby biznesowej ani technicznej.

Po pierwsze, nawet administratorzy baz danych nie powinni widzieć haseł użytkowników. Hashowanie ich zapobiegnie temu, jeśli administrator zdecyduje się spojrzeć na hasło i zalogować się na konto użytkownika.

Zaskakujące, nikt jeszcze o tym nie wspominał, ale co z bezpieczeństwem FIZYCZNYM twojej bazy danych?

Być może masz skonfigurowane najlepsze zabezpieczenia IT na świecie, ale to nie powstrzyma nikogo, kto może uzyskać fizyczny dostęp do twoich nośników pamięci. Co się stanie, gdy Twój zespół wygra po południu Superbowl, a w centrum miasta, w którym znajduje się twoje biuro / dostawca usług hostingowych, wybuchnie mała zamieszka? (Biorąc pod uwagę, że jest to Seattle vs. Denver, dwa duże obszary informatyczne w USA, nie sądzę, aby było to nieuzasadnione). Tłum wpada do twojego budynku i podczas gdy władze są przytłoczone, ktoś chwyta twój sprzęt z bazą danych zawierającą hasła w postaci jawnego tekstu?

Co się stanie, gdy Federalni pojawią się i zajmą twój sprzęt, ponieważ jakiś szef wysokiego szczebla wykorzystywał swoją pozycję w firmie do przeprowadzania nielegalnych transakcji giełdowych? Następnie Federalni używają tych haseł do badania twoich klientów, chociaż nie zrobili nic złego. Potem zdają sobie sprawę, że to TY naraziłeś ich na niebezpieczeństwo.

Co się stanie, gdy dział IT zapomni o wyczyszczeniu starych dysków RAID, w których przechowywano DB, podczas planowanych wymian, zanim „przekaże” stare dyski stażystom, a następnie ich współlokatorzy w akademiku znajdą to, co zostało, i wymyślą, że mogą ” sprzedać ”i nigdy nie miał do nich dostępu?

Co się stanie, gdy serwer DB wysadzi płytę główną, dział IT przywróci obraz na nowym serwerze, a „tusza” starego serwera zostanie wrzucona na stos recyklingu? Te dyski są nadal dobre, a dane wciąż tam są.

Każdy porządny architekt wie, że bezpieczeństwo nie jest czymś, co później „naciągasz” na zapory ogniowe i zasady operacyjne. Bezpieczeństwo musi być podstawową częścią projektu od samego początku, a to oznacza, że ​​hasła są jednokierunkowe, NIGDY nie są przesyłane bez szyfrowania (nawet w obrębie własnych centrów danych) i nigdy nie można ich odzyskać. Wszystko, co można odzyskać, może zostać zagrożone.

Odkładając na bok przypadek włamania do bazy danych: Jako klient nie chciałbym, abyś znał moje hasło. Wiem, że możesz łatwo złapać hasło, gdy pojawia się na żądanie, ale mam lepsze wrażenie, gdy nie masz go do dyspozycji, aby zapytać w dowolnym momencie.

Jeśli hasła są przechowywane w postaci zwykłego tekstu, oznaczałoby to, że są one znane użytkownikowi i każdemu, kto ma dostęp do tej tabeli. Cały pomysł dotyczący implementowania użytkowników i haseł polega na tym, aby pewna sesja w twoim systemie należała do tej osoby, zarówno ze względu na prywatność, jak i bezpieczeństwo.

Jeśli grupa użytkowników zna nazwę użytkownika / hasło, jednoznaczna identyfikacja osoby staje się bezużyteczna , co stwarza wiele możliwych scenariuszy kradzieży tożsamości, oszustwa ...

Dlatego hasła są przechowywane przy użyciu protokołów szyfrowania asymetrycznego, aby upewnić się, że można je zweryfikować bez możliwości ich odczytania.

Myślę, że pytanie ma fundamentalną wadę. Faktem jest, że nie ma czegoś takiego jak „bezpieczna baza danych”. Należy wziąć pod uwagę, że w twoim systemie występują wady, które mogłyby umożliwić złośliwym użytkownikom dostęp do dowolnych danych na twoich serwerach. Heartbleed jest tego doskonałym przykładem, ponieważ jest exploitem, który był na wolności przez ponad dwa lata, zanim został zauważony przez naukowców. Możliwe, że zrobiłeś wszystko, co wiesz, jak chronić dane, ale nie możesz uwzględnić wszystkich innych programów, których używasz na swoich serwerach i skomplikowanych sposobów ich interakcji.

Jeśli ktoś się tobą zainteresuje, zostaniesz zhakowany. Ważne jest, aby dołożyć wszelkich starań, aby przede wszystkim nie dać się zhakować, ale także aby złagodzić obrażenia zadawane w takim przypadku poprzez umieszczenie jak największej liczby przeszkód. Hashuj swoje hasła. Konfiguracja nie jest trudna, a wyrządzasz swoim użytkownikom krzywdę, nie traktując ich prywatności poważnie. Pychą jest myśleć, że jesteś lepiej chroniony przed złośliwymi atakami niż firmy takie jak Yahoo , Sony czy Target , które zostały zhakowane.