W jakim scenariuszu haker otrzyma tabelę, ale nie kod PHP?

Question

Ok, więc rozumiem wartość soli w moich mieszanych hasłach ... rodzaj.

Konfiguruję podstawowy schemat uwierzytelniania, w którym ustawiam hasła, a użytkownicy nie mają możliwości ustawienia haseł jako czegoś, co mogą wykorzystać w innej witrynie.

Jaka jest rzeczywista użyteczność soli?

W jakich okolicznościach ktoś może narazić na szwank moją tabelę użytkowników, ale nie uzyska również dostępu do pozostałych tabel ze wszystkimi danymi lub mojego kodu PHP, który pokazuje magię?

Próbuję ustalić, czy użycie soli jest tak ważne w moim przypadku.

Dzięki

Answer 1

Należy zauważyć, że SQL Injection może być używany do odczytu plików przy użyciu load data infile. Posiadanie wartości soli nieznanej atakującemu, zmusi napastnika do zrobienia znacznie większej liczby zgadywanek w celu uzyskania zwykłego tekstu. Chociaż solenie prawie nigdy nie bierze tego pod uwagę. Główną ideą jest wykonanie dwóch rzeczy:

1) Dwóch użytkowników z tym samym hasłem będzie mieć różne skróty hasła. Dlatego niektóre systemy solenia używają bardzo małych soli, takich jak tylko kilka bajtów.

2) Zmuszenie atakującego do wygenerowania większego rainbow tables. W tym przypadku potrzebujesz co najmniej 8 bajtów. Często zdarza się, że sole mają taką samą liczbę bitów, co funkcja trawienia wiadomości, co powoduje, że obliczenia wstępne są całkowicie niewykonalne.

Po uzyskaniu soli można użyć narzędzia John The Ripper do brutalnej wymuszenia hasła. GPU są również powszechnie używane do łamania mocno zasolonych haseł. Należy zauważyć, że bcrypt() jest dobry w obronie przed FPGA i GPU ze względu na wysokie wymagania dotyczące pamięci. Using memory hard functions for password storage może przynieść bardzo silny system przechowywania haseł.

Answer 2

Jak rozumiem, sól spowalnia odwrotne obliczenie haseł użytkowników w przypadku tej tabeli wykradzenie. Sole są przypisywane do hasła, a następnie mieszane jednokierunkowo w celu uniknięcia możliwości określenia haseł z Tęczowymi tabelami lub list wstępnie mieszanych haseł.

Answer 3

Jeśli użyjesz soli, powiedzmy losowo jeden ASCII, atakujący musi mieć tabelę, której rozmiar jest 256 razy bardziej relatywny do stołu tęczowego bez soli.

Dla 2 soli charytatywnych ASCII ma już 65536 razy większy rozmiar.

Co naprawdę należy wspomnieć, dlaczego warto używać soli w ogóle, to fakt, że większość użytkowników używa słów bezpośrednio znalezionych w słowniku. Nie mam danych na temat ilości, ale myślę, że to dużo. Więc nawet jeśli nie ma używanych tablic kolorów, atakujący może tylko "bruteforce" wprowadzić mały zestaw haseł w tym samym czasie. Jeśli nie masz soli, zrób słownikowy atak z pewnymi modyfikacjami (numery dodatków, ...), a otrzymasz 30% wszystkich haseł z jednym atakiem słownikowym. Z solą to nie może się zdarzyć w jednym biegu, oznacza to, że zajmuje dużo więcej czasu, co oznacza, że ​​jest bezcelowe dla atakującego.

Na inne pytanie:

nic nie utrudnia atakującemu na zdobycie innych danych tabeli. Ale to nic nie może uśpić haseł z solą lub bez niej.

Answer 4

Dużym problemem z soleniem haseł (i ich hashowania) jest to, że wiele osób ... w rzeczywistości prawie wszyscy ludzie ... ponownie używają swoich haseł. Ponadto większość tabel użytkowników przechowuje również wiadomości e-mail i/lub nazwy użytkownika. Więc jeśli ktoś zdąży uzyskać hasło wszystkich użytkowników, szkoda nie została po prostu zrobiona na twojej stronie, ale także gdziekolwiek indziej, że ci użytkownicy są zarejestrowani, gdzie mogą być łatwo sprawdzeni. Ze wszystkimi danymi, które normalnie są przechowywane na tablicach użytkownika, trudno jest wyolbrzymić obrażenia.

W skrócie; Pęknięte hasła nie tylko zapewniają użytkownikom dostęp do hostingu, ale także wpływają na bezpieczeństwo klientów w niemal każdej witrynie, do której się logują.

Ale aby odpowiedzieć na pytanie tytułowe; jest bardzo prawdopodobne, że jeśli twoja baza danych zostanie naruszona, twój kod PHP też jest. Mogą jednak uzyskać tylko dostęp do odczytu kodu PHP, podczas gdy większość poziomów dostępu do baz danych wymaga dostępu INSERT/UPDATE, aby aplikacja mogła w ogóle funkcjonować. Niektórzy dzielą dostęp SQL do odczytu i zapisu, ale w większości przypadków jest to nierealne, ponieważ zawsze jesteś w INSPEKCJACH i AKTUALIZACJI, nawet na stronach, na których użytkownicy nawet nie zalogowali się (liczniki, takie jak przyciski itp. .).