Czy „if password == XXXXXXX” wystarcza dla minimalnego bezpieczeństwa?

20

Jeśli utworzę login dla aplikacji o średnim lub niskim ryzyku bezpieczeństwa (innymi słowy, nie jest to aplikacja bankowa ani nic takiego), czy mogę zweryfikować hasło wprowadzone przez użytkownika, mówiąc tylko:

if(enteredPassword == verifiedPassword)
     SendToRestrictedArea();
else
     DisplayPasswordUnknownMessage();

Wydaje się, że łatwo jest być skutecznym, ale z pewnością nie miałbym nic przeciwko, gdyby to było wszystko, czego potrzeba. Czy wystarczy proste sprawdzenie nazwy użytkownika / hasła?

Aktualizacja: konkretnym projektem jest usługa sieciowa, weryfikacja odbywa się całkowicie po stronie serwera i nie jest open source. Czy domena zmienia sposób, w jaki sobie z tym poradzisz?

Morgan Herlocker
źródło
3
zależy, skąd pochodzi poprawne hasło? jeśli jest zakodowany na stałe, nie będzie można skonfigurować / zmienić hasła bez zmiany kodu. Jeśli pochodzi z pliku konfiguracyjnego, będzie widoczny dla każdego, kto ma do niego dostęp.
Alb
1
„czy wystarczy sprawdzić kombinację nazwy użytkownika / hasła”?
Chris
3
@opinion: wydaje się mało prawdopodobne, aby było to gorsze niż brak logowania. Podaj uzasadnienie tak silnego roszczenia.
Morgan Herlocker
1
Twoja terminologia jest niepoprawna, gdy porównujesz hasło, weryfikujesz je, nie upewniając się, że jest poprawne. Poświęć trochę czasu na zrozumienie różnicy.
billy.bob
1
Oznacza to przechowywanie haseł w postaci zwykłego tekstu, co jest nieodpowiedzialne. Oznacza to również powiadomienie użytkownika, że ​​hasło jest niepoprawne, co zapewnia potencjalnemu napastnikowi zbyt dużo informacji. Zawsze powinieneś być niejednoznaczny, tzn. „Niepoprawny login lub hasło”.
Rein Henrichs

Odpowiedzi:

26

Nie bez SSL

Nie jest to bezpieczne, jeśli hasło jest wysyłane przez sieć zwykłym tekstem. Hashowanie hasła po stronie serwera również nie jest bezpieczne, jeśli hasło jest wysyłane przez sieć zwykłym tekstem.

Ponieważ <input type="password"/>znacznik HTML wysyła zawartość w postaci zwykłego tekstu, będzie to problem bez względu na sposób przechowywania hasła na serwerze, chyba że witryna internetowa używa protokołu SSL do przesłania hasła.

(Uwierzytelnianie HTTP, które pojawia się w oknie dialogowym z prośbą o podanie hasła, może, ale nie musi być zwykłym tekstem, w zależności od wspólnych mechanizmów uwierzytelniania serwera i przeglądarki. Może to być sposób na uniknięcie tego bez użycia SSL.)

Nie, jeśli administratorzy witryny są podejrzani

Zakładając, że używasz HTTPS do tworzenia stron internetowych, może to być bezpieczne, jeśli zaufasz administratorom witryny (którzy potrafią czytać hasła w postaci zwykłego tekstu) i innym osobom, które mają dostęp do komputera, aby zachowywać się poprawnie. Teraz może być oczywiste, że mogą zrobić wszystko, co chcą z twoją witryną (ponieważ administrują nią), ale jeśli potrafią odczytać hasło, mogą również być w stanie użyć skradzionej pary login / hasło na stronach innych osób.

Sposobem, który utrzymuje bezpieczny od haseł administratora

Jeden bezpieczny sposób przechowywania haseł i sprawdzić to w następujący sposób:

def change_password user, new_password
  salt = random(65536).to_s(16) #will be 4 characters long
  password_hash = salt + hash(salt + new_password)
  store(user,password_hash)
end

def does_password_match? user, entered_password
  correct_password_hash = retrieve(user)
  salt = correct_password_hash[0...4]
  entered_password_hash = salt + hash(salt + entered_password)
  return correct_password_hash == entered_password_hash
end

Dla funkcji skrótu, spróbuj użyć czegoś silny, a coś, co nie ma dobrych tęczowe tablice w naturze jeszcze. Można zmienić długość soli razie potrzeby stoły robocze wokół tęczy.

W zależności od środowiska, w którym się znajdujesz, zmienności opóźnień w sieci oraz tego, czy nazwy użytkowników mają być znane publicznie, możesz chcieć obliczyć inną ścieżkę kodu, hash('0000'+entered_password)jeśli użytkownik nie istnieje, aby uniemożliwić atakującym określania nazwy użytkowników, które są ważne w oparciu o czas potrzebny określić, że hasło jest nieprawidłowe.

Ken Bloom
źródło
1
Dobre rady :) Jeśli chodzi o SSL, musieliśmy zaprojektować coś, co działałoby na wolności , i po prostu użyliśmy asymetrycznej kryptografii do zakodowania hasła (wymaga Javascript), a następnie odkodowania go na serwerze. Sól + skrót występuje wtedy normalnie. Ponadto, ponieważ klucz publiczny jest wysyłany ze stroną internetową, może on często zmieniać się dowolnie.
Matthieu M.
1
@Matthieu M .: Kiedy ktoś może sfałszować twoją stronę, może również zmienić klucz publiczny na taki, na którym sam zna odpowiedni klucz prywatny. Twój pomysł pomaga więc tylko przeciwko pasywnym atakom odczytu, a nie przeciwko środkowemu człowiekowi.
Paŭlo Ebermann
@Paulo: tak, zgadzam się, że SSL dotyczy nie tylko szyfrowania, ale także certyfikatu, niestety nie dzwonię tutaj, a kiedy ludzie mówią, że chcą korzystać ze strony przy regularnym http://połączeniu ... to frustrujące: /
Matthieu M.,
@ Matthieu: Czy to oznacza, że ​​wysyłasz public_key jako część publicznej strony internetowej, obliczasz encrypt(entered_password, public_key)na kliencie i wysyłasz ten wynik na serwer, który wykonuje does_password_match?(user, decrypt(encrypted_password, private_key))?
Ken Bloom
@Ken: mniej więcej masz prawidłowe szyfrowanie. Do dopasowania hasła jest więcej does_password_match(user, salt, decrypt(encrypted, key)), z solą zależną od użytkownika. Jak powiedziałem, oczywistym problemem jest brak ochrony człowieka w środku.
Matthieu M.,
52

Sugerowałoby to, że trzymasz hasła w otwartym tekście, co jest nie do przyjęcia, nawet w scenariuszach o niskim poziomie bezpieczeństwa.

Powinieneś raczej mieć:

if(hash(enteredPassword) == storedHash)

Możesz użyć prostego skrótu, jak na przykład MD5

vartec
źródło
22
+1 do mieszania hasło. Ale bym przynajmniej dodać trochę soli, jak również. W przeciwnym razie, ponieważ użytkownicy zamierzają ponownie używać nazw użytkowników i haseł między systemami, naruszenie aplikacji o niskim poziomie bezpieczeństwa może umożliwić osobie atakującej złamanie aplikacji o znacznie wyższej ochronie. Niedawny włamanie do HBGary, na przykład, udało się skompromitować system CMS działający na ich stronie internetowej i częściowo zmienić go w dostęp do roota do swoich serwerów, ponieważ system CMS o niskim poziomie bezpieczeństwa nie dodawał soli do skrótów arstechnica.com/tech-policy/ news / 2011/02 / ...
Justin Cave
1
Zgadzam się ... rozważ następujące ... "ciągi JavaFile.class | grep -i hasło"
Bill
Na czym polega problem z posiadaniem hasła w postaci zwykłego tekstu, jeśli są one używane tylko jeden raz?
10
@Tim ponieważ użytkownicy nie będą wykorzystywać hasło tylko raz. Badania pokazują, że hasła użytkowników konsekwentnie ponownie użyć wielokrotnie (np theregister.co.uk/2011/02/10/password_re_use_study ) bez względu na to, ile razy oni powiedzieli nie.
Scott
3
@Tim: Poza tym, po prostu otworzyć exe, dll, etc, w edytorze tekstu, a będziesz prawdopodobnie zobaczyć hasła właśnie tam.
Gus Cavalcanti
14

Zgadzam się z tymi, którzy sugerują hashowania, ale istnieje również koło jesteś wymyślania tutaj. W zależności od platformy prawdopodobnie można znaleźć narzędzia do zarządzania rola / użytkownika, który obejmuje wszystkie rzeczy zarządzania użytkownikami i bezpiecznie, bez konieczności zbyt dużo interwencji ze strony użytkownika.

glenatron
źródło
I dopiero odkryto Providers ASP.Net członkostwa, ale szukałem w nich myśli „ile razy mam zmarnowany mój czas realizacji coś takiego?”
glenatron
8

Bezpieczeństwo jest bardzo drażliwy temat, szczególnie dlatego, że musi być równowaga pomiędzy inconveniencing użytkowników i upewniając ich informacje są bezpieczne. Zazwyczaj formuła ile trzeba bezpieczeństwo jest funkcją znaczenia danych. W skrócie:

isSecuritySufficient = effortToBreak > rewardForBreaking

Częstym nieporozumieniem o ludziach, którzy robią złe rzeczy jest to, czego po. Większość z nich chce zniszczyć zaufanie . Powinieneś zawsze robić wszystko, co możliwe, aby chronić zaufanie użytkowników. Część, która robi swoje należytej staranności, aby upewnić się, że ich tożsamość jest bezpieczne. Mogą obchodzi o dane, które przechowują, ale dbają o ich tożsamości - nawet na najniższym progu bezpieczeństwa.

Dostępnych jest wiele tanich opcji (do wdrożenia i wpływu na użytkownika). Jednym z nich jest zakodowanie hasła na minimalnym poziomie. Każda usługa przechowująca coś tak wrażliwego jak hasło w postaci zwykłego tekstu zasługuje na zawstydzenie związane z włamaniem.

Ogólne zasady ochrony haseł

  • Nigdy przechowuj haseł w postaci zwykłego tekstu
  • Hash pomocą bezpiecznego funkcji skrótu SHA-1 podobny lub nawet SHA-512 (nawet MD5 jest zbyt łatwe do znalezienia pasującego hash)
  • Użyj wartości soli aplikacji. Sól jest losowe bajty albo dodawane do hasła, aby uczynić go bardziej trudne do odgadnięcia. Sól powinna być generowane w czasie wykonywania i wykorzystywania informacji o urządzeniu, jako wartością początkową zamiast przechowywane i odwołuje się w żaden sposób.
  • Użyj wartości soli specyficznej dla użytkownika. Użyj tego w połączeniu z solą do aplikacji.
  • Zaszyfruj wszystkie żądania uwierzytelnienia przesyłane przez sieć. Oznacza to używanie protokołu SSL w aplikacjach internetowych.

Ponieważ do uwierzytelniania korzystasz z protokołu SSL, musisz przynajmniej zaszyfrować wszystkie strony, które dotyczą konta użytkownika. Pozwala to na jak największą ochronę tożsamości użytkownika.

Uwaga na temat zarządzania hasłem : użytkownicy od czasu do czasu zapomną swoje hasło. Absolutnie najgorsze , co możesz zrobić, to wysłać im hasło w wiadomości e-mail. Jeśli wdrożenie zasad opisanych powyżej, nie będzie w stanie to zrobić tak. Jest o wiele lepiej, aby zapewnić sposób, aby zresetować swoje hasło za pomocą linku wysłanego do swojego zarejestrowanego adresu e-mail. Linkujące resetu będzie miał kod jednorazowego użytku, aby zapewnić osoba dostęp do strony jest im.

Berin Loritsch
źródło
1
Na początku byłem naprawdę uderzony przez ideę soli sól + aplikacja użytkownika, ale im więcej o tym myślę, tym bardziej przekonany jestem. Jeśli użyjesz, powiedzmy, 4 znaków soli aplikacji i 4 soli użytkownika, różnica między tym a 8 znakami soli użytkownika jest taka, że ​​połowa soli będzie identyczna dla każdego użytkownika. Wydaje się, że byłoby to bardziej bezpieczne, aby po prostu zwiększyć rozmiar soli użytkownika, zamiast mieć sól aplikacji. Ponadto, jeśli sól aplikacja jest oparta na sprzęcie to nie można uaktualnić lub zmienić sprzęt bez unieważniania wszystkich haseł.
David Conrad
Problem polega na tym, że sól użytkownika znajduje się w wierszu bazy danych wraz z hasłem użytkownika. Jeśli zły człowiek wie, co jest dla soli (i robią) i widzą go w bazie danych, a następnie umie całkowicie go złamać. Włączając udział w aplikacji, która jest obliczana (w ten sam sposób za każdym razem, gdy umysł) zamiast przechowywać, to sprawia, że o wiele trudniejsze do złamania tabele użytkowników. Oczywiście można pójść o krok dalej i zrobić 1 część czystego losowe sól i 1 część soli obliczoną z zarówno dla konkretnych mecz.
Berin Loritsch
Ach, rozumiem, trzymaj część soli poza bazą danych. Że ma sensu. Dziękuję Ci.
David Conrad
Nie widzę problemu przechowywania soli na rzędzie, tak długo, jak jego unikalny w rzędzie. Oto skrót: "fd84235a55bbfeb1585a3dd069d48127989c9753058b51b6ba2056fd6c5a0a91" (SHA256), oto sól: "671254bdf7944f8fa88e6c9913b948ee". Myślisz, że możesz dostać hasło? Nie ma tęczowe tablice dla tej soli (nawet jeśli dany sól), utkniesz brute-zmuszając go.
Bryan Boettcher,
3

W porządku, chyba że hasło jest używane do czegokolwiek innego. Jest jeszcze ryzyko, że użytkownik zdecyduje, że można ponownie użyć hasła, więc byłoby jeszcze lepiej:

if(hash(enteredPassword) == hashOfValidPassword)

Jeśli jest to dla siebie lub kogoś, kto jest świadomy, że hasło jest przechowywane w postaci zwykłego tekstu, to w porządku.


źródło
1
Jak w komentarzu Justina Cave'a do odpowiedzi vartca, użyj soli, więc if (hash (enteredPassword + salt) == hashOfValidSaltedPassword)- i zauważ, że +to prawdopodobnie konkatenacja, a nie dodanie. To bardzo utrudnia stosowanie tęczowe tablice, które są tabele mieszań dotyczące prawdopodobnych haseł.
David Thornley
jeśli wszystko, czego szukasz, to skrót, czy nie mogliby po prostu przejść przez pętlę możliwych ciągów, dopóki nie wygeneruje tego samego skrótu, co przechowywany skrót? Istnieje wiele strun, które mogą odpowiadać tej samej hash, mimo wszystko.
Morgan Herlocker
@Prof Plum: To jest bardzo trudne do znalezienia kolizji jeśli algorytm mieszania jest dobra. To jest podstawa współczesnej kryptografii: są zasadniczo jednokierunkowe funkcje.
3

Czy kod źródłowy? Nawet jeśli nie, to jestem pewien, hasło można znaleźć w instrukcji maszynowych w przypadku binarny jest dostępny. Polecam robi sum kontrolnych i porównywania że zamiast.

Nigdy nie wychodzą bezpieczeństwa, nawet jeśli nie jest to bardzo ważne w swojej opinii.

Anto
źródło
2
Tak, zły pomysł, jeśli jest to projekt open source :)
-1 - Jeśli uważasz, mający źródło robi różnicę, o których nic nie wiemy bezpieczeństwa.
mattnz
1

Absolutnie nie. Mają lektury tego , opisuje w jaki sposób hakerzy zhakowane strony internetowej zabezpieczeń. Planujecie miałby Cię jako najsłabsze ogniwo w łańcuchu.

Dave
źródło
0

Stwierdzono w kilka odpowiedzi, które nie należy przechowywać samego hasła, ale hash - i należy użyć SSL.

Można powiedzieć, co to jest wielka sprawa? Jeżeli moja aplikacja zostanie posiekany, że nie ma większego niepokoju. Dobrze jest to dość powszechne wzór dla użytkowników, aby używać tego samego hasła na wszystkich stronach. Czy haker hack swojej stronie i mieć dostęp do haseł użytkownika, haker będzie mógł podszyć dużo tych użytkowników na innych stronach o większym znaczeniu dla tych użytkowników. Tak hacking witryny może być pierwszym krokiem do wzmocnienia hakera dostępu do informacji bankowość dla użytkowników.

I właśnie mieszania hasło nie wystarczy. Trzeba mieszania go z solą. Hakerzy mają odwrotne hash tabel przeglądowych, więc dla danego hash, mogą znaleźć hasło dopasowanie.

Jeśli nie zdecydujesz się na realizacji tych funkcji, należy poinformować użytkowników z tego braku bezpieczeństwa, zachęcając ich, aby nie używać tego samego hasła, że ​​używają oni gdzie indziej.

Pete
źródło
-2

Tak długo, jak to jest po stronie serwera .. Wtedy tak.

Jeśli chcesz trochę więcej przejdź zabezpieczeń i szyfrowania https \ hash hasła w DB.

Kretynowie
źródło
3
Po co zakładać, że jest to aplikacja internetowa?
Chris
Słuszna uwaga! Właśnie zrobiłem.
Morons
4
-1, nawet jeśli jest to po stronie serwera, nadal nie jest w porządku
GSto,