Dane uwierzytelniające sesji powiązanych z urządzeniem (DBSC)

Dane uwierzytelniające sesji powiązane z urządzeniem (DBSC) zwiększają bezpieczeństwo uwierzytelniania, dodając zabezpieczenia sesji oparte na sprzęcie.

Daniel Rubery

José Luis Zapata

Wprowadzenie

Wiele witryn korzysta z plików cookie o długim okresie ważności do uwierzytelniania użytkowników, ale są one podatne na przejęcie sesji. Dane uwierzytelniające sesji powiązane z urządzeniem (DBSC) dodają warstwę zabezpieczeń opartych na sprzęcie, aby zmniejszyć to ryzyko, zapewniając, że sesje są powiązane z określonymi urządzeniami.

Ten przewodnik jest przeznaczony dla deweloperów, którzy utrzymują procesy uwierzytelniania w aplikacjach internetowych. Wyjaśniamy w nim, jak działa DBSC i jak zintegrować ją z witryną.

Jak działa DBSC

Na najwyższym poziomie DBSC wprowadza parę kluczy kryptograficznych powiązanych z urządzeniem użytkownika. Chrome generuje tę parę kluczy podczas logowania i przechowuje klucz prywatny w bezpiecznym sprzęcie, takim jak moduł TPM (Trusted Platform Module), jeśli jest dostępny. Sesje korzystają z krótkotrwałych plików cookie. Gdy jeden z tych plików cookie wygaśnie, Chrome potwierdza posiadanie klucza prywatnego przed jego odświeżeniem. Ten proces łączy ciągłość sesji z oryginalnym urządzeniem.

Jeśli urządzenie użytkownika nie obsługuje bezpiecznego przechowywania kluczy, DBSC płynnie przechodzi na standardowe działanie bez przerywania procesu uwierzytelniania.

Omówienie wdrożenia

Aby zintegrować DBSC z aplikacją, musisz wprowadzić te zmiany:

• Zmodyfikuj proces logowania, aby uwzględnić nagłówek Secure-Session-Registration.
• Dodaj punkt końcowy rejestracji sesji, który:
  • Przypisuje klucz publiczny do sesji użytkownika.
  • Udostępnia konfigurację sesji.
  • Przejście na krótkotrwałe pliki cookie.
• Dodaj punkt końcowy odświeżania, aby obsługiwać odnawianie plików cookie i weryfikację posiadania klucza.

Większość dotychczasowych punktów końcowych nie wymaga żadnych zmian. DBSC ma charakter dodatkowy i niezakłócający.

Gdy wymagany krótkotrwały plik cookie nie jest dostępny lub wygasł, Chrome wstrzymuje żądanie i próbuje odświeżyć plik cookie. Dzięki temu aplikacja może nadal używać zwykłych sprawdzeń plików cookie sesji, aby potwierdzić, że użytkownik jest zalogowany. Ponieważ pasuje to do typowych przepływów uwierzytelniania, DBSC działa przy minimalnych zmianach w logice logowania.

Etapy wdrażania

W tej sekcji znajdziesz informacje o niezbędnych zmianach w systemie uwierzytelniania, w tym o tym, jak zmodyfikować proces logowania, obsługiwać rejestrację sesji i zarządzać odświeżaniem krótkotrwałych plików cookie. Każdy krok został zaprojektowany tak, aby można go było łatwo zintegrować z dotychczasową infrastrukturą.

Kroki implementacji są zgodne z typowym procesem, który użytkownik zalogowany na konto przechodzi, gdy jest aktywna funkcja DBSC: rejestracja podczas logowania, a następnie regularne odświeżanie krótkotrwałych plików cookie. Możesz przetestować i wdrożyć każdy krok niezależnie od pozostałych, w zależności od poziomu wrażliwości sesji w Twojej aplikacji.

1. Modyfikowanie procesu logowania

Po zalogowaniu się użytkownika wyślij długotrwały plik cookie i nagłówek Secure-Session-Registration. Na przykład:

Po zarejestrowaniu sesji zwracany jest ten nagłówek odpowiedzi HTTP:

HTTP/1.1 200 OK
Secure-Session-Registration: (ES256 RS256); path="/StartSession"
Set-Cookie: auth_cookie=session_id; max-age=2592000; Domain=example.com; Secure; SameSite=Lax

Jeśli urządzenie obsługuje bezpieczne przechowywanie kluczy, Chrome kontaktuje się z punktem końcowym /StartSession za pomocą klucza publicznego w tokenie sieciowym JSON (JWT).

Znak auth_cookie w tym przykładzie oznacza token sesji. Możesz nadać temu plikowi cookie dowolną nazwę, o ile pasuje ona do pola name w konfiguracji sesji i jest używana spójnie w całej aplikacji.

2. Wdrażanie punktu końcowego rejestracji sesji

W /StartSession serwer powinien:

• powiązać otrzymany klucz publiczny z sesją użytkownika;
• Odpowiada konfiguracją sesji.
• Zastąp długotrwały plik cookie krótkotrwałym.

W tym przykładzie krótkotrwały plik cookie jest skonfigurowany tak, aby wygasał po 10 minutach:

HTTP/1.1 200 OK
Set-Cookie: auth_cookie=short_lived_grant; Max-Age=600; # Expires after 10 minutesSet-Cookie: Domain=example.com; Secure; SameSite=Lax

{
  "session_identifier": "session_id",
  "refresh_url": "/RefreshEndpoint",
  "scope": {
    "origin": "https://example.com",
    "include_site": true,
    "scope_specification": [
      { "type": "exclude", "domain": "*.example.com", "path": "/static" }
    ]
  },
  "credentials": [{
    "type": "cookie",
    "name": "auth_cookie",
    "attributes": "Domain=example.com; Secure; SameSite=Lax"
  }]
}

3. Wdrażanie punktu końcowego odświeżania

Gdy krótkotrwały plik cookie wygaśnie, Chrome inicjuje proces odświeżania, aby potwierdzić posiadanie klucza prywatnego. Ten proces obejmuje skoordynowane działania Chrome i Twojego serwera:

1. Chrome przekazuje żądanie użytkownika do aplikacji i wysyła żądanie odświeżenia do /RefreshEndpoint:

   POST /RefreshEndpoint HTTP/1.1
   Sec-Secure-Session-Id: session_id
   

2. Serwer odpowiada wyzwaniem:

   HTTP/1.1 403 Forbidden
   Secure-Session-Challenge: "challenge_value"
   

3. Chrome podpisuje wyzwanie za pomocą zapisanego klucza prywatnego i ponawia żądanie:

   POST /RefreshEndpoint HTTP/1.1
   Sec-Secure-Session-Id: session_id
   Secure-Session-Response: <JWT proof>
   

4. Serwer weryfikuje podpisany dowód i wydaje odświeżony, krótkotrwały plik cookie:

   HTTP/1.1 200 OK
   
   Set-Cookie: auth_cookie=short_lived_grant; Max-Age=600; Domain=example.com; Secure; SameSite=Lax
   

5. Chrome otrzymuje odświeżony plik cookie i wznawia pierwotne odroczone żądanie.

Alternatywny wzorzec integracji

Aby zwiększyć odporność, witryny mogą dodać drugi plik cookie, który nie jest plikiem cookie DBSC, obok krótkotrwałego pliku cookie. Ten długotrwały plik cookie służy tylko do wydawania nowych krótkotrwałych tokenów i pomaga odróżnić prawdziwie nieuwierzytelnione żądania od tymczasowych błędów DBSC.

• Długotrwały plik cookie jest zachowywany nawet w przypadku niepowodzenia DBSC.
• Krótkotrwały plik cookie jest odświeżany za pomocą DBSC i jest wymagany w przypadku operacji wymagających zachowania poufności.

Ten wzorzec daje witrynom większą kontrolę nad obsługą przypadków brzegowych.

Zastrzeżenia i działanie w przypadku braku zgodności

W tych sytuacjach Chrome może pominąć operacje DBSC i wysyłać żądania bez krótkotrwałego pliku cookie zarządzanego przez DBSC:

• Punkt końcowy odświeżania jest niedostępny z powodu błędów sieci lub problemów z serwerem.
• Moduł TPM jest zajęty lub napotyka błędy podpisywania. Ponieważ moduł TPM jest współdzielony przez procesy systemowe, nadmierne odświeżanie może przekroczyć jego limity szybkości.
• Krótkotrwały plik cookie zarządzany przez DBSC jest plikiem cookie innej firmy, a użytkownik zablokował pliki cookie innych firm w ustawieniach przeglądarki.

W takich sytuacjach Chrome wraca do używania długotrwałego pliku cookie, jeśli jest on nadal obecny. Ta rezerwa działa tylko wtedy, gdy w Twojej implementacji znajdują się zarówno długotrwałe, jak i krótkotrwałe pliki cookie. W przeciwnym razie Chrome wysyła żądanie bez pliku cookie.

Podsumowanie

Dane uwierzytelniające sesji powiązane z urządzeniem zwiększają bezpieczeństwo sesji przy minimalnych zmianach w aplikacji. Zapewniają one lepszą ochronę przed przejęciem sesji, ponieważ wiążą sesje z określonymi urządzeniami. Większość użytkowników nie odczuje żadnych zakłóceń, a DBSC w przypadku nieobsługiwanego sprzętu będzie działać w sposób niezakłócony.

Więcej informacji znajdziesz w specyfikacji DBSC.