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


78

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?


124
Poszedłbym o krok dalej. Nie wystarczy go zaszyfrować. Chciałbyś to mieszać. W ten sposób nawet ty nie powinieneś wiedzieć, jakie są hasła w postaci zwykłego tekstu.
Święty

67
@Santa Hashowanie hasła nie wystarczy. Musisz dodać trochę soli, aby przepis był wystarczająco dobry ...
Bakuriu

16
Proszę spojrzeć na ten odpowiedni post Security.StackExchange: Jak bezpiecznie hash hasła?
Adi

10
Niezadowolony DBA mówi ... wybierz * od użytkownika, a następnie sprzedaje tę listę za pensję. Nic nigdy nie jest bezpieczne.
Jon Raynor

Odpowiedzi:


194

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.


89
Lub lepiej, haszuj to!
Blorgbeard

29
To. „Mam inne problemy, jeśli ktoś dostanie się do mojej bazy danych”. To twoja baza danych, możesz spodziewać się problemów, jeśli zostanie zhakowany. Ale przechowując hasła w postaci zwykłego tekstu, dajesz wszystkim użytkownikom problemy z potencjalnie wszystkimi innymi kontami. Jak myślisz, ile osób naprawdę używa innego hasła na każdej stronie?
Carson63000,

13
Postępuj zgodnie z radą Blorgbearda, może przeczytaj to . Szyfrowanie haseł nie zapewnia ochrony w przypadku naruszenia bezpieczeństwa serwera WWW. Klucz do odszyfrowania haseł musi być przechowywany gdzieś na serwerze. Hashowanie haseł oznacza, że ​​nawet w przypadku, gdy ktoś ma pełny dostęp do komputera, nie może łatwo odzyskać haseł.
Slicedpan

7
Dlaczego miałbyś kiedykolwiek szyfrować hasła, jeśli nie ma to żadnej wartości dla twojego systemu? W którym momencie będziesz musiał odszyfrować hasła, inne niż do porównania? @pdr, nie powinieneś mówić OP, aby szyfrował, powinieneś powiedzieć mu, żeby zrobił sól i hash.
NobleUplift

4
Chcesz również przesłać odpowiedzi na pytania dotyczące odzyskiwania hasła. W przeciwnym razie można ich również użyć do uzyskania dostępu do innych stron, podobnie jak hasła.
Zan Lynx,

64

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.



13
+1 za wzmiankę o niezadowolonych pracownikach. Łatwo jest przeoczyć, gdy jesteś jednoosobowym sklepem lub małą firmą, ale w końcu będziesz mieć ludzi pracujących z danymi, których osobiście nie sprawdziłeś.

2
Napisanie foreach w celu przejrzenia listy użytkowników, a następnie skrótu ich haseł to praca kilku minut, a szczerze mówiąc 4000 to prawie nic. php.net/manual/en/function.hash.php
Elin

3
Ciągle przełączasz się między terminami „szyfruj” za pomocą „hash and salt” @ david25272. Nie pomylcie tych dwóch, które są całkowicie różne. Teraz OP szuka algorytmu szyfrowania, a nie algorytmu mieszającego. Ponadto jest to „sól i skrót”, a nie „skrót i sól”. Nie możesz solić po haszu.
NobleUplift

1
Również @phpmysqlguy, przeczytaj moją odpowiedź na sugestie dotyczące algorytmów solenia i mieszania .
NobleUplift

36

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.


9
Robisz to, co uważam za najważniejsze: TY i twoi pracownicy nie powinniście mieć dostępu do hasła użytkownika. Hakerowi zależy na ludziach, którzy przechowują dane dotyczące użytkowników.
Adam Davis

1
+1 za to, że jako programista / administrator nie powinieneś mieć dostępu do haseł użytkowników. To samo w sobie jest wystarczającym powodem.
Matt

21

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.


18

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.


+1 za skrót i sól. Pękanie haszy bez soli jest takie proste.
Code Maverick

3
Wiesz, co jest po drugiej stronie tęczowego stołu @CodeMaverick? Garnek złota.
NobleUplift

W kontekście mieszania haseł MD5 nie ma znanych luk w zabezpieczeniach poza tym, że jest szybki, i dotyczy to również SHA-2. Korzystanie z powolnej, iterowanej konstrukcji jest znacznie ważniejsze niż wybranie SHA-2 zamiast MD5.
CodesInChaos

4
„Przeczytaj całą tę stronę zanim hash haseł” - to strona mówi, że należy nie używać rund mieszaja, ale metoda mieszania, który został specjalnie zaprojektowany, aby być tak wolno, jak to konieczne, takie jak PBKDF2.
jhominal

2
Użyj SCrypt lub PBKDF2, z których oba są bardzo drogie w działaniu pod względem pamięci lub procesora. Użyj losowo wygenerowanej soli przechowywanej w rekordzie użytkownika. Nie wykonuj wielu rund mieszania, co tylko prowadzi do problemów z kolizją.
tom.dietrich

14

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.

6
Zasadniczo zaleca się stosowanie losowej soli zamiast nazwy użytkownika.
CodesInChaos

Wow, świetny chwyt @CodesInChaos. Nie zauważyłem tego po pierwszym przeczytaniu pytania. Tak, twoja sól powinna być generowana losowo. Nie musi to być jakiś zwariowany obiekt blob przechowywany w MySQL (i byłoby źle, ponieważ wtedy nie byłby przenośny). W przeciwnym razie +1 za powiedzenie, że tylko użytkownik powinien znać hasło użytkownika.
NobleUplift

Dobra, zaktualizowana odpowiedź sugerująca, że ​​aplikacja ma własną losową wartość soli.
Michael Shaw

4
Nie, aplikacja nie ma również wartości soli. Dla każdego przechowywanego skrótu powinna być inna, silnie losowa wartość soli. (Przechowujesz sól obok tego skrótu.) To właśnie chroni przed atakami statystycznymi. Jeśli użyłeś tego samego skrótu dla całej aplikacji, to ten sam tekst jawny haszy do tej samej wartości. To o wiele gorsze niż używanie nazwy użytkownika jako skrótu.
Ben Voigt

To nie jest usługa internetowa, ale uwierzytelnianie kluczy SSH korzysta z „czystego” rozwiązania, w którym serwer przechowuje klucz publiczny, a użytkownik uwierzytelnia się za pomocą klucza prywatnego.
cpast

10

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ę).


+1 za poznanie różnicy między szyfrowaniem a haszowaniem.
NobleUplift

8

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.


2
Niestety używam PHP 5.3.3, więc twoje sugestie nie będą miały zastosowania
phpmysqlguy

4
czy aktualizacja jest 5.3.3 do 5.3.8?
gbjbaanb

Czy jest jakaś szansa, że ​​jesteś na Red Hat? Ponieważ dokonali backportowania poprawki do bcrypt. Jeśli nie, użyj SHA256 zamiast brcypt.
Elin

1
Szyfrowanie i mieszanie to różne rzeczy. Hasła hasłowe, nie szyfruj ich. Nigdy nie musisz ich znać. Wystarczy, że użytkownik będzie mógł użyć hasła, aby udowodnić, kim jest. Hashowanie (z solą) pozwala na to. Szyfrowanie, szczególnie szyfrowanie symetryczne jest nieprawidłowe, ponieważ umożliwia odzyskanie haseł.
Paul de Vrieze

Dodam tylko, że dobrą cechą funkcji password_hash () w php 5.5+ jest to, że domyślnie obsługuje ona solenie i tak dalej. Wcześniej musisz zacząć korzystać z biblioteki ircmaxell, która ją obsługuje (napisał implementację 5.5). Nie zakładaj, że możesz samodzielnie wygenerować losową sól. Jest to bardzo trudne i najlepiej pozostawić je ekspertom; bardzo łatwo jest uzyskać losowe, ale niejednolite wyniki, które można wykorzystać.
Elin

7

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.


+1 za wspomnienie zarówno o soleniu, jak i haszowaniu, a także o nie wspominaniu o szyfrowaniu, które nawet nie należy do tego pytania.
NobleUplift

2

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.


2

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.


1
nie dodaje to niczego godnego do tego, co zostało już opublikowane w poprzednich odpowiedziach
komentuje

3
+1. Powiedział „haszowanie” zamiast szyfrowania, jak wiele innych. Ponadto bezpośrednio zaprzeczył OP, który powiedział, że chce, aby zwykły tekst hasła logował się na konta innych użytkowników.
NobleUplift

0

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.


-1

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.


1
W rzeczywistości, gdyby PO posunął się o krok dalej i został zaszyfrowany w JavaScript, hash zostałby wysłany przewodem i nigdy nie byłby widoczny w żądaniu.
NobleUplift

1
W takim przypadku atakujący musiałby tylko przesłać skrót przez drut. Hash działałby po prostu jako wymyślne, ale niezaszyfrowane hasło, prawda? (Edytuj: nie, jeśli trzeba go za każdym razem solić inną solą, a sól pochodzi z serwera. Myślę, że)
RemcoGerlich

1
@RemcoGerlich Kluczowa koncepcja znana jest jako nonce, która służy do unikania ataku powtórkowego .

-1

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.


2
Kto przechowuje hasła przy użyciu szyfrowania asymetrycznego? To jest kryptografia z kluczem publicznym, co oznacza, że ​​nawet po tym, jak zaszyfruję moje hasło, można je odszyfrować i odczytać, jeśli ktoś kiedykolwiek uzyska mój klucz prywatny. Dzięki hashowaniu znam tylko i wyłącznie moje hasło (chyba, że ​​je zapiszę lub nie wprowadzę do menedżera haseł, gdzie faktycznie jest to szyfrowanie asymetryczne).
NobleUplift

Proszę sprawdzić stronę wikipedii pod kątem kryptografii klucza publicznego: en.wikipedia.org/wiki/Public-key_cryptography „Kryptografia klucza publicznego, znana również jako kryptografia asymetryczna”
Alpha1983,

2
... tak, powiedziałem to using asymmetric encryption? That's public-key cryptography. O co ci chodzi?
NobleUplift

-1

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.


1
wydaje się, że nie oferuje to nic istotnego w porównaniu z 14 wcześniejszymi odpowiedziami
komara

Nie zgadzam się, inaczej nie opublikowałbym tego. Nie jestem jednak pewien, czy widzę, jak kręcenie negatywnych komentarzy przyczynia się do rozmowy, oprócz zniechęcania ludzi do uczestnictwa.
lobati

cóż, nie wiem, czy przeczytałeś inne odpowiedzi przed opublikowaniem swojej, ale podczas mojego czytania wszystkie punkty tutaj zostały już przedstawione (i dla mojego czytania lepiej przedstawione) gdzie indziej. Na przykład, w tej i tej odpowiedzi ponad dwa miesiące temu poruszono kwestię błędu . Punkt o hashowaniu haseł powstał przynajmniej w 7 innych odpowiedziach. Już dawno wspomniano o tworzeniu kopii zapasowych i rozliczaniu możliwych problemów w innych częściach systemu. Itd. Etc
komara

Połączony punkt błędny był inny niż mój. Podkreślali różnicę znaczenia między skrótem a szyfrowaniem, podczas gdy mówiłem, że błędem jest myśleć, że bazę danych można uznać za „bezpieczną”. Nadal nie widzę żadnych innych odpowiedzi na temat innych programów i ich interakcji, które są niepewne, i nie wspomniałem o kopiach zapasowych.
lobati

„zakładaj, że zostaniesz zhakowany” - tak napisano w odpowiedzi opublikowanej ponad 2 miesiące temu
komara
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.