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?

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.

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

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.

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.

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.

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.

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.

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.

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.