Kredensial Sesi yang Terikat Perangkat (DBSC)

Kredensial Sesi Terikat Perangkat (DBSC) memperkuat autentikasi dengan menambahkan keamanan sesi yang didukung hardware.

Daniel Rubery
Daniel Rubery
José Luis Zapata

Pengantar

Banyak situs mengandalkan cookie yang berlaku lama untuk autentikasi pengguna, tetapi cookie ini rentan terhadap pembajakan sesi. Kredensial Sesi Terikat Perangkat (DBSC) menambahkan lapisan keamanan yang didukung hardware untuk mengurangi risiko ini, sehingga memastikan sesi terikat ke perangkat tertentu.

Panduan ini ditujukan bagi developer yang mengelola alur autentikasi di aplikasi web. Dokumen ini menjelaskan cara kerja DBSC dan cara mengintegrasikannya ke situs Anda.

Cara kerja DBSC

Secara umum, DBSC memperkenalkan pasangan kunci kriptografi yang terkait dengan perangkat pengguna. Chrome membuat pasangan kunci ini selama login dan menyimpan kunci pribadi di hardware yang aman, seperti Trusted Platform Module (TPM), jika tersedia. Sesi menggunakan cookie berdurasi singkat. Saat salah satu cookie ini berakhir masa berlakunya, Chrome akan membuktikan kepemilikan kunci pribadi sebelum memuat ulang cookie tersebut. Proses ini menautkan kelanjutan sesi ke perangkat asli.

Jika perangkat pengguna tidak mendukung penyimpanan kunci yang aman, DBSC akan melakukan penggantian ke perilaku standar tanpa mengganggu alur autentikasi.

Ringkasan penerapan

Untuk mengintegrasikan DBSC ke dalam aplikasi, Anda perlu melakukan perubahan berikut:

  • Ubah alur login Anda untuk menyertakan header Secure-Session-Registration.
  • Menambahkan endpoint pendaftaran sesi yang:
    • Mengaitkan kunci publik dengan sesi pengguna.
    • Menayangkan konfigurasi sesi.
    • Transisi ke cookie dengan masa berlaku singkat.
  • Tambahkan endpoint refresh untuk menangani perpanjangan cookie dan validasi kepemilikan kunci.

Sebagian besar endpoint yang ada tidak memerlukan perubahan apa pun. DBSC dirancang agar bersifat aditif dan tidak mengganggu.

Jika cookie sementara yang diperlukan tidak ada atau masa berlakunya habis, Chrome akan menjeda permintaan dan mencoba memuat ulang cookie. Dengan begitu, aplikasi Anda dapat terus menggunakan pemeriksaan cookie sesi yang biasa untuk mengonfirmasi bahwa pengguna login. Karena cocok dengan alur autentikasi umum, DBSC berfungsi dengan perubahan minimal pada logika login Anda.

Langkah-langkah implementasi

Bagian ini menjelaskan perubahan yang diperlukan pada sistem autentikasi Anda, termasuk cara mengubah alur login, menangani pendaftaran sesi, dan mengelola penggantian cookie yang masa berlakunya singkat. Setiap langkah dirancang untuk berintegrasi dengan lancar dengan infrastruktur yang ada.

Langkah-langkah penerapan mengikuti alur umum yang akan dialami pengguna yang login saat DBSC aktif: pendaftaran saat login, diikuti dengan penggantian cookie reguler yang berumur pendek. Anda dapat menguji dan menerapkan setiap langkah secara terpisah, bergantung pada tingkat sensitivitas sesi aplikasi Anda.

Diagram yang menunjukkan alur DBSC

1. Mengubah alur login

Setelah pengguna login, respons dengan cookie yang berlaku lama dan header Secure-Session-Registration. Contoh:

Header respons HTTP berikut ditampilkan setelah pendaftaran sesi berhasil:

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

Jika perangkat mendukung penyimpanan kunci yang aman, Chrome menghubungi endpoint /StartSession dengan kunci publik dalam Token Web JSON (JWT).

auth_cookie dalam contoh ini mewakili token sesi Anda. Anda dapat memberi nama cookie ini sesuka Anda, asalkan cocok dengan kolom name dalam konfigurasi sesi dan digunakan secara konsisten di seluruh aplikasi Anda.

2. Menerapkan endpoint pendaftaran sesi

Di /StartSession, server Anda harus:

  • Mengaitkan kunci publik yang diterima dengan sesi pengguna.
  • Merespons dengan konfigurasi sesi.
  • Ganti cookie yang berumur panjang dengan cookie yang berumur pendek.

Dalam contoh berikut, cookie berumur pendek dikonfigurasi agar berakhir setelah 10 menit:

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. Menerapkan endpoint refresh

Saat cookie yang berumur pendek berakhir, Chrome memulai alur penggantian untuk membuktikan kepemilikan kunci pribadi. Proses ini melibatkan tindakan terkoordinasi oleh Chrome dan server Anda:

  1. Chrome menunda permintaan pengguna ke aplikasi Anda dan mengirimkan permintaan refresh ke /RefreshEndpoint:

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

  2. Server Anda merespons dengan tantangan:

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

  3. Chrome menandatangani tantangan menggunakan kunci pribadi yang disimpan dan mencoba lagi permintaan:

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

  4. Server Anda memvalidasi bukti yang ditandatangani dan menerbitkan cookie singkat yang diperbarui:

    HTTP/1.1 200 OK

Set-Cookie: auth_cookie=short_lived_grant; Max-Age=600; Domain=example.com; Secure; SameSite=Lax

  5. Chrome menerima cookie yang diperbarui dan melanjutkan permintaan yang ditangguhkan semula.

Pola integrasi alternatif

Untuk meningkatkan ketahanan, situs dapat menambahkan cookie kedua non-DBSC bersama dengan cookie yang berumur pendek. Cookie yang aktif dalam jangka waktu lama ini hanya digunakan untuk menerbitkan token baru yang aktif dalam jangka waktu singkat dan membantu membedakan antara permintaan yang benar-benar tidak diautentikasi dan kegagalan DBSC sementara.

  • Cookie yang aktif dalam jangka waktu lama tetap ada meskipun DBSC gagal.
  • Cookie berumur pendek diperbarui menggunakan DBSC dan diperlukan untuk operasi sensitif.

Pola ini memberi situs kontrol lebih besar atas cara menangani kasus ekstrem.

Peringatan dan perilaku penggantian

Chrome dapat melewati operasi DBSC dan mengirim permintaan tanpa cookie singkat yang dikelola DBSC dalam skenario berikut:

  • Endpoint refresh tidak dapat dijangkau karena error jaringan atau masalah server.
  • TPM sedang sibuk atau mengalami error penandatanganan. Karena TPM digunakan bersama di seluruh proses sistem, refresh yang berlebihan dapat melampaui batas kecepatan.
  • Cookie singkat yang dikelola DBSC adalah cookie pihak ketiga, dan pengguna telah memblokir cookie pihak ketiga di setelan browsernya.

Dalam situasi ini, Chrome akan kembali menggunakan cookie yang aktif dalam jangka waktu lama jika cookie tersebut masih ada. Penggantian ini hanya berfungsi jika penerapan Anda menyertakan cookie yang memiliki masa aktif panjang dan cookie yang memiliki masa aktif singkat. Jika tidak, Chrome akan mengirim permintaan tanpa cookie.

Ringkasan

Kredensial Sesi Terikat Perangkat meningkatkan keamanan sesi dengan perubahan minimal pada aplikasi Anda. Fitur ini memberikan perlindungan yang lebih kuat terhadap pembajakan sesi dengan mengikat sesi ke perangkat tertentu. Sebagian besar pengguna akan mendapatkan manfaat tanpa mengalami gangguan apa pun, dan DBSC akan melakukan penggantian yang lancar pada hardware yang tidak didukung.

Untuk mengetahui informasi selengkapnya, lihat spesifikasi DBSC.