Pytanie Demistifying Web Authentication


Obecnie badam protokoły uwierzytelniania użytkowników dla witryny, którą rozwijam. Chciałbym utworzyć plik cookie uwierzytelniania, aby użytkownicy mogli pozostać zalogowanym między stronami.

Oto moje pierwsze bash:

cookie = user_id|expiry_date|HMAC(user_id|expiry_date, k)

Gdzie k jest HMAC(user_id|expiry_date, sk) i sk jest kluczem 256-bitowym znanym tylko serwerowi. HMAC jest hash SHA-256. Zwróć uwagę, że "|" jest separatorem, a nie tylko konkatenacją.

Wygląda to tak w PHP:

$key = hash_hmac('sha256', $user_id . '|' . $expiry_time, SECRET_KEY);
$digest = hash_hmac('sha256', $user_id . '|' . $expiry_time, $key);
$cookie = $user_id . '|' . $expiry_time . '|' . $digest;

Widzę, że jest podatny na ataki Replay, jak stwierdzono w Bezpieczny protokół ciasteczek, ale powinien być odporny na Ataki Głośności i Splatanie Cryptograficzne.

PYTANIE:  Czy jestem tutaj na właściwej linii, czy też istnieje ogromna luka w zabezpieczeniach, którą przeoczyłem? Czy istnieje sposób obrony przed atakami Replay, które działają z dynamicznie przydzielonymi adresami IP i nie używają sesji?

UWAGI

Najnowszy materiał, który przeczytałem:
Dawkowanie i zakaz uwierzytelniania klienta w sieci aka Fu et al.
(https://pdos.csail.mit.edu/papers/webauth:sec10.pdf)

Bezpieczny protokół ciasteczek aka Liu i in.
(http://www.cse.msu.edu/~alexliu/publications/Cookie/cookie.pdf)
który rozszerza się na poprzednią metodę

Ulepszone pliki cookie bezstanowej sesji
(http://www.lightbluetouchpaper.org/2008/05/16/hardened-stateless-session-cookies/)
który również rozszerza się na poprzednią metodę.

Ponieważ temat jest niezwykle skomplikowany, szukam tylko odpowiedzi od ekspertów od bezpieczeństwa z doświadczeniem w tworzeniu i łamaniu schematów uwierzytelniania.


12
2017-10-22 19:16


pochodzenie


To jest świetne pytanie i zastanawiam się, czy rozważyć rozpoczęcie bounty, aby wskrzesić pytanie i zwrócić na niego więcej uwagi. Może nawet e-mail link do tego pytania do różnych ekspertów bezpieczeństwa. - John Zabroski
Możesz uzyskać więcej odpowiedzi na stronie security.stackexchange.com - Edu
Dobry pomysł. security.stackexchange.com/questions/30707/... - Joony


Odpowiedzi:


Ogólnie jest w porządku, zrobiłem coś podobnego w wielu aplikacjach. Nie jest bardziej podatny na powtórne ataki, niż były już identyfikatory sesji. Możesz chronić tokeny przed wyciekiem w celu odtworzenia za pomocą protokołu SSL, tak jak w przypadku identyfikatorów sesji.

Drobne sugestie:

  • Umieść pole w swoich danych użytkownika, które zostanie zaktualizowane na hasło zmiany hasła (być może licznik generowania hasła lub nawet losowa sól) i uwzględnij to pole w tokenie i części podpisanej. Wtedy, gdy użytkownik zmienia swoje hasła, unieważnia również inne skradzione tokeny. Bez tego ograniczymy się do czasu, w którym rozsądnie pozwoli się żetonowi żyć przed wygaśnięciem.

  • Umieść identyfikator schematu w tokenie i części podpisanej, aby (a) można było mieć różne typy tokenów do różnych celów (np. Jeden dla auth i jeden dla ochrony XSRF) oraz (b) można aktualizować mechanizm za pomocą nowa wersja bez konieczności unieważniania wszystkich starych tokenów.

  • Zapewnić user_id nigdy nie jest ponownie używany, aby zapobiec użyciu tokenu w celu uzyskania dostępu do innego zasobu o tym samym identyfikatorze.

  • Zakłada się odgałęzienie rury | nigdy nie może pojawić się w żadnej z wartości pól. Prawdopodobnie działa to dla wartości numerycznych, z którymi (prawdopodobnie) masz do czynienia, ale możesz w pewnym momencie potrzebować bardziej zaangażowanego formatu, np. Par nazw / wartości zakodowanych przez URL.

  • Podwójne HMAC nie wydaje się naprawdę za bardzo cię pochłaniać. Zarówno brutalna siła jak i kryptoanaliza przeciwko HMAC-SHA256 są już nieprawdopodobnie trudne dzięki obecnemu zrozumieniu.


7
2018-02-11 19:17





  1. O ile twoje transakcje / sekunda nie będą opodatkowały twojego sprzętu, przekazałbym tylko skrót w pliku cookie (tj. Pominąłem user_id i expiry_date - bez sensu dawałem złym ludziom więcej informacji, niż to absolutnie konieczne).

  2. Można założyć, że następny dynamiczny adres IP powinien być, biorąc pod uwagę poprzedni dynamiczny adres IP (nie mam szczegółów pod ręką, niestety). Hashowanie tylko niezmiennej części dynamicznego adresu IP pomogłoby zweryfikować użytkownika nawet po zmianie jego adresu IP. To może, ale nie musi działać, biorąc pod uwagę różne schematy alokacji adresów IP.

  3. Możesz uzyskać informacje o systemie i haszyszu, które również - w Linuksie możesz uname -a (ale są też podobne możliwości dla innych systemów operacyjnych). Wystarczająca ilość informacji systemowych i możesz być w stanie całkowicie pominąć (częściowy) adres IP. Ta technika wymaga pewnych eksperymentów. Używanie jedynie informacji systemowych dostarczanych przez zwykłą przeglądarkę ułatwiłoby to.

  4. Musisz zastanowić się, jak długo pliki cookie powinny pozostać świeże. Jeśli możesz żyć z osobami, które muszą uwierzytelniać się raz dziennie, łatwiej byłoby ci kodować uwierzytelnianie systemu niż zezwalać ludziom na uwierzytelnianie tylko raz w miesiącu (i tak dalej).


0
2018-02-15 19:48



Cały punkt tego systemu polega na tym, aby nie przechowywać stanu na serwerze. Gdyby było to możliwe, losowy identyfikator sesji byłby zawsze lepszy od tego systemu. - ayke


Uznałbym ten protokół za bardzo słaby!

  1. plik cookie sesji nie jest losowym źródłem o wysokiej entropii.
  2. Serwer musi wykonać asymetryczne szyfrowanie na każdej stronie, aby zweryfikować użytkownika.
  3. Bezpieczeństwo JAKIEGOKOLWIEK użytkownika polega tylko na zabezpieczeniu skutera kluczowego.

Klucz SK serwera jest najbardziej wrażliwą częścią. Jeśli ktokolwiek może go odgadnąć lub ukraść, może zalogować się jako konkretny użytkownik.

Więc jeśli sk jest generowany dla każdej sesji i użytkownika, to dlaczego hmac? Myślę, że i tak skorzystasz z protokołu TLS, jeśli nie, zastanów się, czy twój protokół nie został złamany z powodu ataków powtórki i podsłuchiwania w ogóle!

Jeśli sk jest generowany dla każdego użytkownika, ale nie dla każdej sesji, jest podobny do hasła 256-bitowego.

Jeśli sk jest identyczny dla wszystkich użytkowników, ktoś musi po prostu złamać 256 bitów i może zalogować się jako dowolny użytkownik, którego chce. Musi jedynie odgadnąć id i datę wygaśnięcia.

Spójrz na digest-authentication. Jest to uwierzytelnianie na żądanie, określone przez rfc2617. Jest bezpieczny dla ataków typu "odpłata" przy użyciu nonces, wysyłanych na każde żądanie. Jest bezpieczny do podsłuchu za pomocą skrótu. Jest zintegrowany z HTTP.


-1
2018-02-18 12:00



1) jest całkowicie nieistotny. 2) Nie ma asymetrycznej kryptografii, tylko dwa lub cztery skróty. 3) To jest cały punkt kryptografii, dzięki czemu system zależy od bezpieczeństwa klucza, a nie od protokołu. "ktoś musi po prostu złamać 256 bitów" jest śmieszny. To około 2 ^ 256 prób. Powodzenia z tym. - ayke