Najlepsze praktyki dotyczące uwierzytelniania / bezpieczeństwa aplikacji internetowych (dowolna platforma)


12

Dzisiaj otrzymałem pytanie od mojego kierownika, które zadaje mi moje przemyślenia na temat tego, co uważa się za akceptowalny projekt do uwierzytelniania aplikacji formularza internetowego, szczególnie w odniesieniu do charakteru wielu popularnych przeglądarek, aby „Zapamiętaj hasło” w polach typowego hasła użytkownika .

Mam problem ze znalezieniem odpowiedzi, która moim zdaniem jest do zaakceptowania. W świetle kłopotliwych wad bezpieczeństwa Sony naprawdę chcę zachować ostrożność, mimo że dane przechowywane na ludziach są mniej czułe. Nie przechowujemy numerów ubezpieczenia społecznego, a nawet adresów, przechowujemy jednak numery telefonów, adresy e-mail i zdjęcia odwiedzającego.

Obawia się, że użytkownik może po prostu zapamiętać hasło na terminalu publicznym, a następnie ktoś może po prostu wskoczyć na ten terminal i rozpocząć przeglądanie lub modyfikowanie danych w nieautoryzowany sposób. Jestem jednak całkiem pewien, że przynajmniej na stacjach roboczych Windows, że przeglądarka nie zapamięta hasła na kontach użytkowników Windows.

Poza tym wdrażam jednokierunkowe szyfrowanie hasła po stronie serwera (przechowuj zakodowane hasło w bazie danych, szyfruj hasło dostarczone przez użytkownika na serwerze, porównaj z zaszyfrowanym łańcuchem z bazy danych). Nie ma bezpośrednich planów włączenia szyfrowania SSL, jednak jest to nadal opcja.

Czy przy takim podejściu występują jakieś poważne wady bezpieczeństwa? Czy masz jakieś lepsze sugestie?


Podczas przechowywania hasła zaszyfrowanego w jedną stronę (tj. Zaszyfrowanego), upewnij się, że używasz silnego skrótu (tj. Nie MD5) lub nie podszywasz hasła (patrz stackoverflow.com/questions/420843/... ) lub obu.
Jordan Reiter,

Sprawdź stronę internetową OWASP ( owasp.org ). Mają wiele bardzo przydatnych informacji dotyczących bezpieczeństwa, w tym „ściągawki” dla różnych protokołów.
Ralph

Istnieją wytyczne dotyczące uwierzytelniania stron internetowych na podstawie formularzy stackoverflow.com/a/477578/463478
Tylko Ty

Odpowiedzi:


13

Kilka wskazówek na wysokim poziomie:

  1. Przechowuj tylko potrzebne dane
  2. Zawsze przechowuj poufne dane (SSN, hasło, numer karty kredytowej itp.) Podczas ich przechowywania
  3. Zawsze szyfruj ruch przy użyciu protokołu SSL podczas przesyłania / odbierania wrażliwych danych
  4. W razie wątpliwości dotyczących wrażliwości informacji zaszyfruj je
  5. Nie ufaj wkładowi użytkownika (ktoś spróbuje wprowadzić coś złego)
  6. Nie ufaj swoim danym (ktoś może to zmienić w bazie danych - na przykład wstrzykuje złośliwy skrypt)
  7. Nie stosuj własnego szyfrowania
  8. Zabezpiecz serwery obsługujące aplikacje / bazy danych
  9. Zwiększ obciążenie użytkowników końcowych ze względu na bezpieczeństwo (ograniczenia haseł, nigdy nie ujawniaj haseł, nie wysyłaj adresów URL w wiadomościach e-mail, skracaj czas sesji itp.)

Moją propozycją byłoby zdobycie książki na temat zabezpieczania aplikacji internetowych. Jest tylko zbyt wiele informacji do przekazania w jednej odpowiedzi / blogu / artykule. Temat samego szyfrowania jest istotny.


Jaki jest powód korzystania z SSL zamiast zwijania własnego szyfrowania? Czy zastanowiłbyś się nad użyciem czegoś takiego jak WS-Security, aby wprowadzić własne szyfrowanie? Konfiguracja SSL może być uciążliwa.
Pan Jefferson

To dobra lista kontrolna. Dziwi mnie, że nie było więcej głosów na ten temat.
Kristofer Hoch,

2
@ Mr.Jefferson powiedziałbym, że 99,999999% czasu, NIGDY nie chcesz „zrolować własnego szyfrowania”.
Zach Leighton


1

Powiedziałbym, że wszystko w porządku.

Większość użytkowników będzie wystarczająco jasna, aby nie zapisywać hasła na terminalu publicznym, a hasła będą przechowywane dla poszczególnych profili. Pamiętaj, że równie łatwo mogą napisać go na karteczce lub użyć słabego hasła.

Jeśli strona logowania nie jest zaszyfrowana za pomocą protokołu SSL, atakujący nie będzie trudny do wąchania tego hasła podczas przesyłania przez sieć. Dobra robota hashuje hasło w bazie danych, co uniemożliwi potencjalnemu napastnikowi zobaczenie haseł wszystkich (których mogliby użyć z adresem e-mail do próby zalogowania się na innych stronach, na których może znajdować się użytkownik).

Jeśli nadal chcesz, są sposoby, aby wyłączyć zachowanie przeglądarki, jak zauważył Chad. Widziałem to tylko na stronie mojego banku i systemie Microsoft Live.


Świetny post, zapomniałem dodać, że nazwa użytkownika nie będzie adresem e-mail, jednak użytkownik będzie miał adres e-mail zapisany w systemie. Zabawne, że o tym wspominasz, ponieważ nawet popularne witryny, takie jak Facebook, są podatne na wąchanie pakietów w celu uzyskania wiadomości e-mail i haseł.
wałek klonowy

Chcę również dodać, że nie wskazuję wad bezpieczeństwa na Facebooku jako „wymówki” koniecznie dla złego modelu bezpieczeństwa w mojej aplikacji. Tylko dlatego, że mama Joey'a pozwala mu oglądać filmy z oceną R, nie robi to dobrze :)
maple_shaft

1

W pewnym momencie nie możesz (i nie jest to prawnie wymagane) chronić użytkownika przed sobą. Funkcja „Zapamiętaj hasło” może być ryzykowna, ale ryzyko to przejmuje użytkownik. Podobnie, jeśli użytkownik zdecyduje się ponownie użyć hasła do wielu usług, przyjmuje na siebie to ryzyko. Nie musisz również ostrzegać ich przed nie zapisywaniem hasła na karteczce i przyklejaniem go do monitora, nawet jeśli użytkownicy często to robią.

To znaczy, dopóki ktoś z powodzeniem nie będzie się spierał i nie zmieni zasad. Zobacz także: „Ostrzeżenie: zawartość może być gorąca”.


0

Nie sądzę, abyś mógł niezawodnie kontrolować, czy przeglądarka pamięta hasło. To po prostu z twoich rąk, czy przeglądarka to robi, czy nie. Niekoniecznie stanowi to dla ciebie ogromne zagrożenie bezpieczeństwa . Zawsze należy zakładać, że ataki można przeprowadzać przy użyciu prawidłowych danych logowania. Nie zakładaj, ponieważ ktoś ma poprawnego loginu / przepustkę, że nie będzie to dobre. W końcu istnieje wiele sposobów, w jakie hasła mogą wpaść w niepowołane ręce.

Wydaje mi się, że możesz za każdym razem losować nazwy pól w formularzu logowania. Zamiast tego <input name="username"użyj czegoś takiego <input name="user658667587". Dzięki temu buforowane nazwy użytkowników byłyby bezużyteczne. Ale nie wiem, czy koszty ogólne byłyby tego warte. Nie wspominając o niewygodnych użytkownikach, którzy nie korzystają z publicznych maszyn.

Jeśli znajdujesz się w sytuacji szczególnie wrażliwej na bezpieczeństwo (bankowość, inwestycje), możesz po prostu zapytać ludzi podczas logowania, czy jest to maszyna publiczna. Możesz również buforować znane adresy IP, gdy ludzie logują się, a jeśli logują się z innej lokalizacji, oprócz zwykłego użytkownika / hasła wymagają podania niepodpisanego numeru PIN (np. Kliknij zdjęcia). Mój bank robi coś podobnego.

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.