Kredensial Sesi yang Terikat Perangkat (DBSC)

bookmark_border Tetap teratur dengan koleksi Simpan dan kategorikan konten berdasarkan preferensi Anda.

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

Daniel Rubery

José Luis Zapata

Pengantar

Banyak situs mengandalkan cookie jangka panjang 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, memastikan sesi terikat ke perangkat tertentu.

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

Cara kerja DBSC

Pada tingkat tinggi, DBSC memperkenalkan pasangan kunci kriptografis 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 berumur pendek. Saat salah satu cookie ini berakhir masa berlakunya, Chrome akan membuktikan kepemilikan kunci pribadi sebelum memuat ulangnya. Proses ini menautkan kontinuitas sesi ke perangkat asli.

Jika perangkat pengguna tidak mendukung penyimpanan kunci yang aman, DBSC akan kembali 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 Sec-Session-Registration.
• Tambahkan endpoint pendaftaran sesi yang:
  • Mengaitkan kunci publik dengan sesi pengguna.
  • Menayangkan konfigurasi sesi.
  • Beralih 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 menjadi tambahan dan tidak mengganggu.

Jika cookie berumur pendek yang diperlukan tidak ada atau sudah tidak berlaku, Chrome akan menjeda permintaan dan mencoba memuat ulang cookie. Dengan demikian, aplikasi Anda dapat terus menggunakan pemeriksaan cookie sesi biasanya untuk mengonfirmasi bahwa pengguna telah login. Karena cocok dengan alur autentikasi standar, DBSC berfungsi dengan perubahan minimal pada logika login Anda.

Langkah-langkah implementasi

Bagian ini membahas perubahan yang diperlukan pada sistem autentikasi Anda, termasuk cara mengubah alur login, menangani pendaftaran sesi, dan mengelola pembaruan cookie berumur pendek. Setiap langkah dirancang untuk berintegrasi dengan lancar dengan infrastruktur yang ada.

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

1. Mengubah alur login

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

Header respons HTTP berikut ditampilkan setelah pendaftaran sesi berhasil:

HTTP/1.1 200 OK
Sec-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 akan 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 apa pun yang Anda inginkan, asalkan cocok dengan kolom name dalam konfigurasi sesi dan digunakan secara konsisten di seluruh aplikasi.

2. Mengimplementasikan endpoint pendaftaran sesi

Di /StartSession, server Anda harus:

• Mengaitkan kunci publik yang diterima dengan sesi pengguna.
• Respons dengan konfigurasi sesi.
• Ganti cookie dengan masa berlaku lama dengan cookie dengan masa berlaku singkat.

Dalam contoh berikut, cookie berumur pendek dikonfigurasi agar berakhir masa berlakunya 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 berumur pendek berakhir masa berlakunya, Chrome akan memulai alur refresh untuk membuktikan kepemilikan kunci pribadi. Proses ini melibatkan tindakan terkoordinasi oleh Chrome dan server Anda:

1. Chrome menunda permintaan pengguna ke aplikasi Anda dan mengirim permintaan muat ulang ke /RefreshEndpoint:

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

2. Server Anda merespons dengan tantangan:

   HTTP/1.1 401 Unauthorized
   Sec-Session-Challenge: "challenge_value"
   

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

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

4. Server Anda memvalidasi bukti yang ditandatangani dan menerbitkan cookie berumur pendek 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 dimuat ulang dan melanjutkan permintaan yang ditangguhkan sebelumnya.

Pola integrasi alternatif

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

• Cookie jangka panjang tetap ada meskipun DBSC gagal.
• Cookie berumur pendek dimuat ulang menggunakan DBSC dan diperlukan untuk operasi sensitif.

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

Perilaku pengganti dan peringatan

Chrome dapat melewati operasi DBSC dan mengirim permintaan tanpa cookie berumur 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 melebihi batas kapasitasnya.
• Cookie berumur pendek yang dikelola DBSC adalah cookie pihak ketiga, dan pengguna telah memblokir cookie pihak ketiga di setelan browser mereka.

Dalam situasi ini, Chrome akan kembali menggunakan cookie dengan masa berlaku lama jika masih ada. Penggantian ini hanya berfungsi jika penerapan Anda menyertakan cookie dengan masa berlaku lama dan singkat. Jika tidak, Chrome akan mengirimkan permintaan tanpa cookie.

Ringkasan

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

Untuk informasi selengkapnya, lihat spesifikasi DBSC.