---
url: 'https://www.corbado.com/id/blog/penjelasan-kredensial-sesi-terikat-perangkat-dbsc'
title: 'Penjelasan Kredensial Sesi Terikat Perangkat (DBSC)'
description: 'Pelajari cara Kredensial Sesi Terikat Perangkat (DBSC) mencegah pembajakan sesi & pencurian cookie. Pelajari status dukungan browser dan keamanan perusahaan.'
lang: 'id'
author: 'Vincent Delitz'
date: '2026-06-15T13:57:57.635Z'
lastModified: '2026-06-17T06:05:41.480Z'
keywords: 'Kredensial Sesi Terikat Perangkat, DBSC, Pencegahan pembajakan sesi, Perlindungan pencurian cookie, Pengikatan sesi TPM'
category: 'Authentication'
---
# Penjelasan Kredensial Sesi Terikat Perangkat (DBSC)
**Status Dukungan Browser**
> **Terbaru (April 2026):** Chrome 146 merilis
> [DBSC dalam ketersediaan umum di Windows](https://blog.google/security/protecting-cookies-with-device-bound-session-credentials/),
> mengeluarkan fitur ini dari Origin Trial. Dukungan macOS (menggunakan
> [Secure Enclave](https://www.corbado.com/glossary/secure-enclave)) akan hadir pada rilis Chrome mendatang.
> Google juga mengumumkan peta jalan publik untuk identitas terfederasi (pengikatan
> [SSO](https://www.corbado.com/blog/passkeys-single-sign-on-sso) lintas asal), registrasi lanjutan (mTLS / kunci
> perangkat keras), dan kunci berbasis perangkat lunak untuk perangkat tanpa perangkat
> keras yang aman.
| Browser | Windows | macOS | Linux | Android | iOS | Status |
| ----------- | ----------------------- | -------------------------- | ----------- | ----------- | --------------- | ------------------------------------------------------------------------------------------------------------------------------------------------ |
| **Chrome** | ✅ GA (Chrome 146, TPM) | 🚧 Segera (Secure Enclave) | ❌ | ❌ | ❌ | [GA di Windows](https://blog.google/security/protecting-cookies-with-device-bound-session-credentials/) (April 2026), macOS pada rilis mendatang |
| **Edge** | ⏸️ Uji coba berakhir | ❌ | ❌ | ❌ | ❌ | Origin Trial berakhir Okt 2025, belum ada pengumuman GA |
| **Safari** | N/A | 🔄 Mengevaluasi | N/A | N/A | 🔄 Mengevaluasi | WebKit sedang berdiskusi, belum ada pengumuman implementasi |
| **Firefox** | 🔄 Memantau | 🔄 Memantau | 🔄 Memantau | 🔄 Memantau | 🔄 Memantau | Mengevaluasi, belum ada komitmen untuk mengimplementasikan |
**Keterangan:** ✅ Tersedia secara umum | 🚧 Diumumkan / dalam pengembangan | ⏸️ Uji coba
berakhir | 🔄 Mengevaluasi/memantau | ❌ Belum tersedia
**Catatan:** [DBSC](https://www.corbado.com/blog/device-bound-session-credentials-dbsc) berstatus GA di Windows
dengan TPM pada Chrome 146 (April 2026). Dukungan macOS melalui
[Secure Enclave](https://www.corbado.com/glossary/secure-enclave) akan diluncurkan berikutnya. Peta jalan yang
dinyatakan Google juga mencakup kunci berbasis perangkat lunak untuk memperluas
perlindungan ke perangkat tanpa perangkat keras aman yang berdedikasi.
**Keunggulan Utama: DBSC vs Model Saat Ini**
| **Fitur** | **Model cookie saat ini** | **Model DBSC** |
| ------------------------- | ----------------------------- | -------------------------------------------------------- |
| **Tipe token** | Pembawa (kepemilikan = akses) | Terikat (kepemilikan + kunci = akses) |
| **Konsekuensi pencurian** | Pengambilalihan akun total | Token tidak berguna (tidak dapat disegarkan) |
| **Durasi sesi** | Pendek (untuk keamanan) | Panjang / tak terbatas (aman secara desain) |
| **Hambatan pengguna** | Tinggi (sering login) | Rendah (keamanan tak terlihat) |
| **Bypass MFA** | Rentan (pass-the-cookie) | Tahan (perangkat diperlukan) |
| **Pencabutan** | Lambat (menunggu kedaluwarsa) | Mendekati waktu nyata (gagal pada penyegaran berikutnya) |
## Key Facts
- **DBSC** mengikat sesi web ke kunci kriptografi yang ada di perangkat, membuat cookie
yang dicuri menjadi tidak berguna karena tidak dapat disegarkan dari perangkat lain.
- Browser menyimpan kunci privat yang tidak dapat diekspor di **TPM**, menandatangani
tantangan server setiap 5 menit untuk membuktikan kepemilikan perangkat tanpa interaksi
pengguna.
- Tidak seperti **Token Binding**, yang gagal karena kompleksitas infrastruktur lapisan
TLS, DBSC beroperasi pada lapisan aplikasi HTTP dan bekerja secara transparan dengan
penyeimbang beban (load balancer) dan CDN yang ada.
- **Chrome 146 merilis DBSC dalam GA di Windows (April 2026)**, dengan dukungan Secure
Enclave macOS hadir pada rilis mendatang. Peta jalan Google yang dipublikasikan juga
mencakup identitas terfederasi (pengikatan SSO lintas asal), registrasi lanjutan (mTLS /
kunci perangkat keras), dan kunci berbasis perangkat lunak untuk perangkat tanpa
perangkat keras yang aman. Safari dan Firefox masih mengevaluasi; Origin Trial Edge
berakhir pada Oktober 2025 tanpa ada pengumuman GA.
## 1. Pengantar: Kredensial Sesi Terikat Perangkat (DBSC)
Arsitektur World Wide Web didirikan pada prinsip tanpa status (statelessness). Ketika HTTP
pertama kali dirancang, ia tidak menyimpan informasi tentang pengguna antar permintaan.
Untuk mengatasinya, "cookie" diciptakan - sepotong kecil data yang dikirim dari sebuah
situs web dan disimpan di komputer pengguna, untuk dikirim kembali ke situs web tersebut
pada setiap permintaan berikutnya. Selama beberapa dekade, mekanisme ini telah menjadi
fondasi manajemen sesi. Saat pengguna masuk (login), server memvalidasi kredensial mereka
dan menerbitkan sebuah cookie. Cookie ini bertindak sebagai "token pembawa" (bearer
token). Di dunia fisik, instrumen pembawa adalah dokumen yang memberikan hak atau aset
yang diwakilinya kepada pemegangnya; jika Anda memegang obligasinya, Anda memiliki
obligasi tersebut. Demikian pula, di dunia digital HTTP, jika Anda memegang cookie-nya,
Anda adalah penggunanya.
Kemampuan pembawa ini secara bersamaan merupakan utilitas terbesar web sekaligus
kerentanannya yang paling mendalam. Keamanan seluruh sesi - dan dengan ekstensinya,
identitas, data, serta aset finansial pengguna - bergantung sepenuhnya pada kerahasiaan
string cookie tersebut. Jika aktor jahat dapat menyalin string itu, mereka dapat meniru
pengguna dari perangkat mana pun, di mana pun di dunia, melewati pemeriksaan
[autentikasi](https://www.corbado.com/id/blog/cara-menjadi-sepenuhnya-tanpa-password) awal sepenuhnya. Kerentanan
spesifik ini telah memunculkan ekonomi bawah tanah skala industri dari "pencurian cookie"
dan "pembajakan sesi".
Seiring dengan keberhasilan industri memperkuat "pintu depan"
[autentikasi](https://www.corbado.com/id/blog/cara-menjadi-sepenuhnya-tanpa-password) melalui adopsi standar FIDO
(Fast Identity Online) dan [kunci sandi](https://www.corbado.com/id/glossary/cda), penyerang mengalihkan fokus
mereka ke "pintu belakang": sesi aktif. Melakukan phising
[kata sandi](https://www.corbado.com/id/blog/cara-mengaktifkan-passkey-android) menjadi lebih sulit, tetapi
mencuri cookie sesi tetap sangat efektif. Tanggapan industri terhadap ancaman yang
meningkat ini adalah **Kredensial Sesi Terikat Perangkat (DBSC)**.
[DBSC](https://www.corbado.com/blog/device-bound-session-credentials-dbsc) mewakili pergeseran paradigma dalam
cara sesi web dikelola. Ia mengusulkan untuk menjauh dari token pembawa sederhana menuju
model di mana sesi tersebut
[terikat secara kriptografis ke perangkat](https://www.w3.org/TR/dbsc/). Dengan
[Chrome 146 (April 2026) merilis DBSC dalam GA di Windows](https://blog.google/security/protecting-cookies-with-device-bound-session-credentials/),
standar ini telah bergerak dari tahap eksperimental menjadi kemampuan produksi yang dapat
dikerahkan tim web hari ini. Chrome menggunakan TPM di Windows dan selanjutnya meluncurkan
dukungan untuk [Secure Enclave](https://www.corbado.com/glossary/secure-enclave) di macOS; spesifikasi itu
sendiri agnostik terhadap penyimpanan kunci, hanya mensyaratkan agar itu "kuat terhadap
ancaman yang dijelaskan." Hal ini membuat cookie yang dicuri jauh berkurang nilainya.
Cookie tersebut tidak dapat disegarkan dari perangkat lain tanpa kunci yang terikat.
Artikel ini memberikan analisis mendalam tentang
[DBSC](https://www.corbado.com/blog/device-bound-session-credentials-dbsc), yang dirancang untuk arsitek
keamanan, manajer produk, dan pengembang. Artikel ini mengeksplorasi arsitektur teknis,
implikasi bisnis dari "keamanan tanpa hambatan", hubungannya dengan standar yang muncul
seperti Shared Signals (CAEP/RISC), dan bagaimana organisasi dapat mempersiapkan masa
depan ini menggunakan platform seperti Corbado.
**Pertanyaan Kunci yang dijawab Artikel ini**
1. Mengapa manajemen sesi saat ini gagal mencegah pengambilalihan akun?
2. Apa bedanya DBSC dengan cookie "Aman" dan flag HttpOnly yang ada?
3. Bagaimana DBSC dan [kunci sandi](https://www.corbado.com/id/glossary/cda) bekerja sama untuk ketahanan phising
yang lebih kuat?
4. Apa yang terjadi pada Token Binding, dan mengapa DBSC berhasil di tempat Token Binding
gagal?
5. Apa implikasi bisnis dan ROI bagi Manajer Produk?
6. Browser dan sistem operasi mana yang mendukung DBSC hari ini?
7. Bagaimana organisasi dapat mengimplementasikan DBSC tanpa membangun dari awal?
8. Apa hubungan antara DBSC, DPoP, dan [OAuth 2.0](https://www.corbado.com/glossary/oauth2)?
9. Bagaimana DBSC terintegrasi dengan Shared Signals (CAEP/RISC) untuk respons ancaman
waktu nyata?
## 2. Memahami Masalah Inti dan Solusi
Untuk menavigasi kompleksitas standar baru ini, kita harus terlebih dahulu memahami
masalah mendasar dengan manajemen sesi saat ini dan bagaimana DBSC memberikan solusinya.
Masing-masing area ini mewakili kerentanan atau batasan kritis yang diatasi DBSC.
### 2.1 Kegagalan Manajemen Sesi Saat Ini
Kegagalan mendasar dari manajemen sesi saat ini adalah "portabilitas" kepercayaan. Saat
sebuah server menerbitkan cookie sesi, ia pada dasarnya menerbitkan paspor yang berfungsi
untuk siapa saja yang memegangnya. Meskipun browser telah mengimplementasikan pertahanan
seperti
[flag HttpOnly dan Secure](https://www.wisp.blog/blog/understanding-token-storage-local-storage-vs-httponly-cookies)
(mencegah akses [JavaScript](https://www.corbado.com/id/blog/aplikasi-crud-react-express-mysql) dan memastikan
transmisi melalui HTTPS), pertahanan ini hanya melindungi dari vektor ekstraksi tertentu
seperti Cross-Site Scripting (XSS) atau penyadapan jaringan. Pertahanan ini sama sekali
tidak menawarkan perlindungan terhadap [malware](https://www.corbado.com/glossary/malware) yang berjalan pada
perangkat host. "Infostealers" adalah [malware](https://www.corbado.com/glossary/malware) yang dirancang khusus
untuk menemukan file penyimpanan cookie browser di disk, mendekripsinya (sering kali
menggunakan kredensial tingkat OS pengguna itu sendiri), dan mengeksfiltrasi isinya ke
server komando dan kontrol (C2). Setelah penyerang memiliki cookie tersebut, mereka dapat
melakukan serangan
[Pass-the-Cookie](https://blog.chromium.org/2024/04/fighting-cookie-theft-using-device.html),
menyuntikkan token curian ke browser mereka sendiri untuk membajak sesi. Server, melihat
cookie yang valid, berasumsi bahwa permintaan tersebut sah.
### 2.2 Keunggulan Kriptografis DBSC atas Cookie Aman Tradisional
DBSC memperkenalkan faktor [autentikasi](https://www.corbado.com/id/blog/cara-menjadi-sepenuhnya-tanpa-password)
kedua ke dalam putaran pemeliharaan sesi itu sendiri. Tidak seperti cookie aman standar,
yang merupakan rahasia statis, sesi DBSC terdiri dari token pembawa berumur pendek dan
bukti kepemilikan kriptografis. Browser menghasilkan pasangan kunci publik-privat yang
disimpan dengan aman di perangkat. Server mengikat sesi ke kunci publik tersebut. Secara
berkala, browser harus membuktikan bahwa ia masih memegang kunci privat dengan
menandatangani tantangan dari server.
[Spesifikasi mensyaratkan penyimpanan kunci](https://www.w3.org/TR/dbsc/) yang "kuat
terhadap ancaman yang dijelaskan". Chrome menggunakan TPM di Windows jika tersedia. Jika
penyerang mencuri cookie dari perangkat yang berbeda, mereka tidak dapat menyegarkannya
karena mereka tidak dapat menghasilkan tanda tangan kriptografis yang diperlukan. Aspek
"pembawa" diminimalkan ke jendela yang sangat pendek, sementara aspek "pengikatan"
memberikan kontinuitas jangka panjang.
### 2.3 Sinergi antara Kunci Sandi dan DBSC
[Kunci sandi](https://www.corbado.com/id/glossary/cda) dan DBSC adalah teknologi pelengkap yang mengamankan
berbagai fase siklus hidup pengguna. Kunci sandi (FIDO2) memecahkan masalah _autentikasi_
membuktikan identitas untuk memulai sesi tanpa
[kata sandi](https://www.corbado.com/id/blog/cara-mengaktifkan-passkey-android), sehingga menghilangkan phising
kredensial. DBSC mengatasi masalah _pasca-autentikasi_ membuat pembajakan sesi melalui
pencurian cookie jauh lebih sulit.
[FIDO Alliance membingkai DBSC](https://fidoalliance.org/white-paper-dbsc-dpop-as-complementary-technologies-to-fido-authentication/)
sebagai teknologi pelengkap yang "meningkatkan standar" terhadap pembajakan sesi. Secara
bersamaan, mereka mengurangi permukaan serangan di seluruh siklus login dan sesi meskipun
DBSC tidak melindungi dari [malware](https://www.corbado.com/glossary/malware) dengan akses perangkat
berkelanjutan atau serangan browser-in-the-middle waktu nyata pada perangkat yang sama.
| Teknologi | Phising Jarak Jauh | Penjejalan Kredensial | Pencurian Token |
| ----------------------------- | ------------------ | --------------------- | --------------- |
| **Kunci Sandi** | ✅ | ✅ | ❌ |
| **DBSC / DPoP** | ❌ | ❌ | ✅ |
| **Kunci Sandi + DBSC / DPoP** | ✅ | ✅ | ✅ |
**Bagaimana Kunci Sandi dan DBSC bekerja sama**
| **Aspek** | **Kunci Sandi** | **DBSC** | **Manfaat gabungan** |
| ----------------------- | --------------------------------------------------- | -------------------------------------------- | ------------------------------------------------------------------------- |
| **Cakupan** | Autentikasi (login) | Manajemen sesi | Perlindungan ujung ke ujung |
| **Ancaman dimitigasi** | Phising kata sandi, penjejalan kredensial | Pembajakan sesi jarak jauh, pencurian cookie | Standar yang ditingkatkan secara signifikan terhadap pengambilalihan akun |
| **Pengalaman pengguna** | Login tanpa kata sandi | Perlindungan sesi transparan | Pengalaman mulus dan aman |
| **Penyimpanan kunci** | Kredensial yang terikat perangkat atau disinkronkan | Terikat perangkat (HSM jika tersedia) | Autentikasi fleksibel, pengikatan sesi kaku |
| **Penerapan** | Menggantikan kata sandi | Meningkatkan sesi yang ada | Peningkatan keamanan bertahap |
### 2.4 Belajar dari Kegagalan Token Binding
DBSC bukan upaya pertama untuk mengatasi masalah ini. "Token Binding" adalah standar
sebelumnya yang berupaya mengikat cookie ke koneksi TLS (Transport Layer Security) yang
mendasarinya. Meskipun secara kriptografis kuat, Token Binding gagal diadopsi karena
ketergantungannya yang besar pada lapisan TLS. Di web modern, koneksi TLS sering kali
dihentikan di penyeimbang beban, CDN, atau proksi terbalik, sementara logika aplikasi
berada di server di belakangnya. Menyebarkan informasi Token Binding melalui lapisan
jaringan kompleks ini terbukti terlalu sulit. DBSC belajar dari kegagalan ini dengan
[beroperasi sepenuhnya pada Lapisan Aplikasi (HTTP)](https://fidoalliance.org/white-paper-dbsc-dpop-as-complementary-technologies-to-fido-authentication/).
DBSC tidak bergantung pada koneksi jaringan yang mendasarinya, membuatnya kompatibel
dengan penyeimbang beban, proksi, dan infrastruktur cloud yang ada.
### 2.5 Implikasi Bisnis dan Peluang ROI
Bagi para pemimpin produk, DBSC menawarkan peluang untuk meningkatkan keamanan sekaligus
meningkatkan pengalaman pengguna (UX). Secara tradisional, keamanan tinggi berarti waktu
tunggu sesi yang singkat, memaksa pengguna untuk sering masuk (hambatan). Dengan mengikat
sesi ke perangkat, risiko pencurian cookie _jarak jauh_ berkurang secara signifikan.
Bisnis dapat mempertimbangkan durasi sesi yang lebih panjang, mengetahui bahwa cookie yang
dicuri tidak dapat disegarkan dari perangkat lain. Namun, DBSC tidak melindungi dari
pencurian perangkat, malware persisten pada perangkat, atau penyalahgunaan oleh pengguna
yang berniat jahat, jadi kebijakan masa pakai sesi harus tetap mencerminkan risiko residu
ini.
## 3. Lanskap Ancaman: Industrialisasi Pencurian Cookie
Untuk memahami urgensi di balik DBSC, seseorang harus menghargai kecanggihan lanskap
ancaman modern. Pencurian cookie sesi telah berkembang dari trik peretas ceruk menjadi
industri skala besar dan otomatis.
### 3.1 Bangkitnya Infostealers
```mermaid
graph TD
A[Pengguna Mengunduh
Perangkat Lunak Berbahaya] -->|Eksekusi| B[Infostealer Aktif
di Perangkat]
B --> C[Menemukan Data Browser]
C --> D[Penyimpanan Cookie
Chrome/Edge/Firefox]
C --> E[Basis Data Kata Sandi]
C --> F[Dompet Kripto]
D --> G[Mendekripsi Menggunakan
Kredensial OS]
E --> G
F --> G
G --> H[Membuat File Log
dengan Data Curian]
H --> I[Eksfiltrasi ke Server C2]
I --> J[Pasar Web Gelap]
J --> K[Penyerang Membeli Log]
K --> L[Mengimpor Cookie ke
Browser Sendiri]
L --> M[Bypass MFA]
M --> N[Pengambilalihan Akun
Selesai]
style A fill:#ff6b6b,color:#fff
style B fill:#ff6b6b,color:#fff
style N fill:#ff6b6b,color:#fff
style J fill:#495057,color:#fff
style M fill:#ffd43b,color:#000
```
Malware-as-a-Service (MaaS) telah menurunkan hambatan masuk bagi penjahat dunia maya.
"Infostealers" seperti RedLine, Raccoon, Vidar, dan Taurus adalah varian malware yang
tersedia secara komersial yang dirancang dengan satu tujuan utama: eksfiltrasi data dari
browser web. Pencuri ini didistribusikan melalui email phising, perangkat lunak retakan
(cracked), atau iklan berbahaya. Setelah diinstal, mereka menargetkan jalur file spesifik
tempat browser seperti Chrome, Edge, dan Firefox menyimpan data mereka.
- **Target:** Basis data Cookies (biasanya file
[SQLite](https://www.corbado.com/blog/passkey-webauthn-database-guide)) dan basis data Login Data (kata sandi
yang disimpan).
- **Mekanisme:** Browser mengenkripsi basis data ini menggunakan Data Protection API
(DPAPI di Windows) yang ditautkan ke login OS pengguna. Karena malware berjalan _sebagai
pengguna_, ia dapat dengan mudah meminta dekripsi file-file ini.
- **Output:** Malware menghasilkan "log"—file zip yang berisi cookie yang didekripsi,
[kata sandi](https://www.corbado.com/id/blog/cara-mengaktifkan-passkey-android), informasi sistem, dan
terkadang kunci [dompet](https://www.corbado.com/id/blog/jaminan-dompet-digital) kripto.
### 3.2 Pasar untuk "Log"
Log-log ini dikumpulkan dan dijual di [pasar](https://www.corbado.com/passkeys-for-e-commerce) web gelap seperti
Genesis Market (sebelum diblokir) dan Russian Market. Pembeli dapat mencari log yang
berisi cookie aktif untuk target bernilai tinggi tertentu: "Salesforce," "Gmail," "Bank of
America," atau "Konsol [AWS](https://www.corbado.com/blog/passkeys-amazon-cognito)."
**Bypass:** Nilai dari sebuah log cookie terletak pada kemampuannya untuk melewati
Autentikasi Multi-Faktor (MFA). Sebagian besar tantangan MFA (SMS, TOTP, Push) hanya
terjadi selama proses _login_. Setelah sesi dibuat dan cookie diterbitkan, server
berasumsi bahwa pengguna dipercaya. Seorang penyerang yang mengimpor cookie sesi yang
valid
[melewati gerbang MFA begitu saja](https://workspace.google.com/blog/identity-and-security/defending-against-account-takeovers-top-threats-passkeys-and-dbsc),
tampak bagi server seolah-olah pengguna kembali ke tab yang aktif.
### 3.3 Ancaman Google Workspace & Microsoft Entra
Paket produktivitas cloud merupakan target utama. Cookie sesi yang dicuri untuk akun
Google Workspace atau Microsoft Entra ID (sebelumnya Azure AD) dapat memberi penyerang
akses ke email perusahaan, dokumen, dan sistem internal.
[Intelijen ancaman Google sendiri](https://blog.chromium.org/2024/04/fighting-cookie-theft-using-device.html)
telah melaporkan lonjakan besar dalam pencurian cookie sebagai vektor utama untuk
mengakses Akun Google, secara eksplisit menyebutkannya sebagai pendorong investasi mereka
dalam DBSC. Mereka mencatat bahwa ketika mereka memaksa mengaktifkan Verifikasi 2 Langkah
(2SV) dan kunci sandi, penyerang hanya mengubah taktik dari phising kredensial (yang
dihentikan oleh [2SV](https://www.corbado.com/blog/2sv-vs-2fa) / kunci sandi) menjadi pencurian cookie (yang
sering kali tidak dapat dihentikan oleh [2SV](https://www.corbado.com/blog/2sv-vs-2fa) / kunci sandi).
### 3.4 Batas "Sidik Jari Perangkat"
Secara historis, mesin risiko telah mencoba mendeteksi pencurian sesi dengan menganalisis
sidik jari perangkat, melihat string
[User-Agent](https://www.corbado.com/blog/client-hints-user-agent-chrome-safari-firefox), resolusi layar, font
yang diinstal, dan alamat IP. Jika cookie sesi tiba-tiba muncul dari IP baru dengan sidik
jari kanvas yang sedikit berbeda, server mungkin membatalkannya. **Masalahnya:** Inisiatif
privasi di browser (seperti Intelligent Tracking Prevention dari Safari dan Privacy
Sandbox dari Chrome) secara aktif mengurangi entropi sidik jari ini untuk menghentikan
pelacakan iklan. Hal ini membuat sidik jari yang "baik" untuk keamanan menjadi semakin
sulit. Selain itu, penyerang sekarang menggunakan "Anti-Detect Browsers" yang memungkinkan
mereka menipu sidik jari ini dengan sempurna agar sesuai dengan profil korban, membuat
deteksi heuristik tidak efektif. DBSC menggantikan permainan tebak-tebakan probabilistik
ini dengan bukti kriptografis deterministik.
## 4. Arsitektur Teknis: Cara Kerja DBSC
Kredensial Sesi Terikat Perangkat (DBSC) memperkenalkan
[API dan protokol terstandarisasi](https://developer.chrome.com/docs/web-platform/device-bound-session-credentials)
untuk membuat sesi yang terikat ke kunci di perangkat klien. Spesifikasi mensyaratkan
penyimpanan kunci "kuat terhadap ancaman yang dijelaskan" tetapi agnostik terhadap
implementasi. Chrome menggunakan TPM di Windows jika tersedia. Bagian ini merinci
mekanikanya sebagaimana didefinisikan dalam Draf Kerja W3C dan dokumentasi Chrome.
### 4.1 Komponen Inti
| **Komponen** | **Deskripsi** | **Peran di DBSC** |
| -------------------------- | ---------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------- |
| **User agent (browser)** | Aplikasi klien (Chrome, Edge, dll.). | Mengelola pasangan kunci, menangani interaksi HSM, dan menyadap permintaan jaringan untuk melampirkan bukti. |
| **Relying party (server)** | Aplikasi web (misalnya portal perbankan). | Menerbitkan tantangan, memverifikasi tanda tangan, dan mengelola siklus hidup sesi. |
| **Penyimpanan kunci** | Penyimpanan aman (TPM, Secure Enclave, atau lainnya) | Menyimpan kunci privat. Chrome menggunakan TPM di Windows jika tersedia; spesifikasi agnostik tentang implementasi. |
| **Cookie sesi** | Cookie HTTP standar. | Digunakan sebagai token pembawa, namun dengan masa hidup sangat pendek (misalnya, 5-10 menit). |
| **Bukti kepemilikan** | Tanda tangan kriptografis. | JWT yang dikirim oleh browser untuk membuktikan bahwa ia masih memiliki kunci privat. |
### 4.2 Siklus Hidup Protokol DBSC
Siklus hidup DBSC memungkinkan transisi yang mulus dari sesi standar ke sesi terikat,
memastikan kompatibilitas mundur dan peningkatan progresif.
```mermaid
sequenceDiagram
participant User
participant Browser
participant HSM as HSM (TPM/Secure Enclave)
participant Server
Note over User,Server: Fase 1: Autentikasi & Pengikatan
User->>Browser: Login dengan kredensial/kunci sandi
Browser->>Server: Permintaan autentikasi
Server->>Browser: Sukses + header registrasi DBSC
Browser->>HSM: Buat pasangan kunci
HSM->>Browser: Kunci Publik/Privat (privat tidak dapat diekspor)
Browser->>Server: Daftarkan kunci publik (JWT ditandatangani)
Server->>Server: Ikat sesi ke kunci publik
Server->>Browser: Cookie berumur pendek (5 mnt)
Note over User,Server: Fase 2: Penggunaan Normal
loop Setiap permintaan dalam waktu 5 menit
Browser->>Server: Permintaan dengan cookie
Server->>Browser: Respons
end
Note over User,Server: Fase 3: Segarkan (setelah kedaluwarsa)
Browser->>Server: Permintaan dengan cookie kedaluwarsa
Server->>Browser: 401 + Tantangan nonce
Browser->>HSM: Tanda tangani tantangan
HSM->>Browser: Tanda tangan
Browser->>Server: Bukti tanda tangan
Server->>Server: Verifikasi dengan kunci publik yang tersimpan
Server->>Browser: Cookie berumur pendek baru
Browser->>Server: Coba ulang permintaan asli
Server->>Browser: Respons sukses
```
#### 4.2.1 Fase 1: Inisiasi dan Pengikatan
Proses pengikatan dimulai segera setelah pengguna melakukan autentikasi menggunakan metode
standar (kata sandi, kunci sandi, dll.).
1. **Sinyal Server:** Setelah login berhasil, server menyetel cookie sesi (seperti biasa)
tetapi menambahkan header spesifik yang menunjukkan dukungan DBSC.
```
HTTP
HTTP/1.1 200 OK
Set-Cookie: session_id=xyz123...; Secure; HttpOnly; SameSite=Strict
Secure-Session-Registration: (ES256 RS256); path="/auth/dbsc/register"
```
- Header Secure-Session-Registration memberi tahu browser: "Saya mendukung algoritma
ES256 dan RS256. Harap daftarkan sesi yang terikat di endpoint /auth/dbsc/register."
2. **Pembuatan Kunci:** Browser mem-parsing header ini. Ia menghasilkan pasangan kunci
asimetris baru (misalnya, Elliptic Curve P-256), yang disimpan secara aman di
perangkat.
- **Catatan Implementasi:** Chrome menggunakan TPM di Windows jika tersedia;
spesifikasi agnostik tentang mekanisme penyimpanan, hanya mensyaratkan agar "kuat
terhadap ancaman yang dijelaskan."
- **Lingkup Privasi:** Kunci dibatasi pada asal web (misalnya, bank.com). Browser
memastikan kunci ini tidak pernah digunakan untuk retailer.com, mencegah pelacakan
lintas situs.
3. **Permintaan Registrasi:** Browser mengirimkan permintaan ke jalur registrasi yang
ditentukan. Permintaan ini menyertakan **Kunci Publik** yang baru dibuat di dalam JSON
Web Token (JWT), ditandatangani oleh Kunci Privat (pengesahan yang ditandatangani
sendiri).
```
HTTP
POST /auth/dbsc/register HTTP/1.1
Content-Type: application/jwt
\.\.\
```
4. **Pengikatan Sesi:** Server memvalidasi tanda tangan untuk memastikan kunci publik
berfungsi. Ia kemudian memperbarui basis datanya untuk mengaitkan sesi pengguna
(session_id=xyz123) dengan Kunci Publik spesifik ini. Sejak saat ini, sesi menjadi
"terikat."
#### 4.2.2 Fase 2: Putaran Cookie Berumur Pendek
Untuk menyeimbangkan keamanan dengan performa (operasi kunci yang aman dapat menambah
latensi), DBSC menggunakan sistem token ganda.
1. **Penerbitan:** Server menerbitkan cookie _baru_ yang berumur pendek (misalnya, berlaku
selama 5 menit). Sebut saja ini access_token.
2. **Penggunaan:** Browser menggunakan access_token ini untuk semua permintaan normal
(mengambil gambar, panggilan API, menavigasi halaman). Selama cookie tersebut valid,
tidak ada operasi kriptografis yang dilakukan. Hal ini memastikan penjelajahan tetap
cepat.
3. **Kedaluwarsa:** Setelah 5 menit, access_token kedaluwarsa.
#### 4.2.3 Fase 3: Segarkan (Bukti Kepemilikan)
Ini adalah jantung dari mekanisme keamanan. Ketika cookie berumur pendek kedaluwarsa,
penyerang pada perangkat yang berbeda terkunci, tetapi pengguna yang sah (dengan akses ke
kunci yang terikat) dapat melanjutkan.
1. **Deteksi:** Browser mencoba melakukan permintaan. Ia mendeteksi bahwa cookie telah
kedaluwarsa (atau server mengembalikan 401 atau header Secure-Session-Challenge
tertentu).
2. **Penyadapan:** Browser _menjeda_ permintaan jaringan. Ia tidak menampilkan pesan
kesalahan kepada pengguna.
3. **Permintaan Segarkan:** Browser secara otomatis memanggil endpoint segarkan yang
ditentukan dalam konfigurasi sesi.
- Server mengirimkan **Tantangan** (nonce) kriptografis.
- Browser menggunakan kunci yang terikat untuk menandatangani tantangan ini.
- Tanda tangan membuktikan kepemilikan kunci privat.
4. **Penyerahan:** Browser mengirimkan tantangan yang ditandatangani kembali ke server.
```
HTTP
POST /auth/dbsc/refresh HTTP/1.1
Sec-Secure-Session-Id: \
Secure-Session-Response: \
```
5. **Validasi:** Server menggunakan Kunci Publik yang disimpan untuk memverifikasi tanda
tangan.
- _Jika Valid:_ Server mengetahui permintaan berasal dari perangkat fisik yang sama
yang memulai sesi. Server menerbitkan access_token berumur pendek _baru_ (berlaku
untuk 5 menit lagi).
- _Jika Tidak Valid:_ Permintaan ditolak. Sesi diakhiri.
6. **Lanjutkan:** Browser mengambil cookie baru dan secara transparan mencoba ulang
permintaan yang ditunda secara asli.
[Pengguna tidak mengalami gangguan](https://developer.chrome.com/docs/web-platform/device-bound-session-credentials).
### 4.3 Nuansa Implementasi
#### 4.3.1 Pertahanan "Lift and Shift"
```mermaid
graph LR
subgraph "Perangkat Korban"
A[Sesi Pengguna
dengan DBSC]
B[Kunci Privat
HSM/TPM]
C[Cookie +
ID Sesi]
A --> B
A --> C
B -.->|Tidak dapat diekspor| X[Tidak Dapat Mengekstraksi
Kunci Privat]
end
subgraph "Skenario Serangan"
D[RedLine Stealer
Menginfeksi Perangkat]
D --> E[Mencuri Cookie
& ID Sesi]
E --> F[Ekspor ke
Penyerang]
end
subgraph "Perangkat Penyerang"
G[Mengimpor Cookie
Curian]
H[Mencoba
Menggunakan Sesi]
I[Server Meminta
Penyegaran DBSC]
J[Tidak Dapat Menandatangani
Tantangan]
K[Sesi Ditolak]
G --> H
H --> I
I --> J
J --> K
end
C -.->|Dicuri| E
F --> G
style D fill:#ff6b6b,color:#fff
style K fill:#51cf66,color:#fff
style B fill:#4c6ef5,color:#fff
style X fill:#51cf66,color:#fff
style J fill:#ff6b6b,color:#fff
```
Pertimbangkan penyerang yang menginfeksi PC pengguna dengan RedLine Stealer. Mereka
mencuri `access_token` dan `session_id`. Mereka mengimpornya ke browser mereka sendiri.
- **Skenario A (Dalam waktu 5 menit):** Penyerang mungkin mendapatkan akses selama
beberapa menit sampai token berumur pendek kedaluwarsa.
- **Skenario B (Setelah Kedaluwarsa):** Browser penyerang (di perangkat berbeda) mencoba
menggunakan token. Server menolaknya dan menuntut penyegaran. Browser penyerang melihat
header DBSC tetapi tidak dapat melakukan penyegaran karena tidak memiliki kunci privat
yang terikat. Serangan gagal.
#### 4.3.2 Cakupan dan Privasi
Privasi merupakan tujuan desain sentral DBSC.
[Spesifikasi W3C](https://www.w3.org/TR/dbsc/) secara eksplisit melarang penggunaan
pengenal global yang dapat melacak pengguna lintas situs.
- **Kunci Per-Asal (Per-Origin):** Browser membuat pasangan kunci yang unik untuk setiap
situs. google.com melihat Kunci A; amazon.com melihat Kunci B. Tidak ada korelasi di
antara mereka.
- **Pembersihan Pengguna:** Jika pengguna menghapus cookie/data situs mereka, browser juga
menghapus kunci DBSC terkait. Hal ini memastikan bahwa DBSC tidak dapat digunakan
sebagai "cookie super" untuk membangkitkan kembali identitas yang telah dihapus.
#### 4.3.3 Pertimbangan di Sisi Server
Implementasi DBSC mengharuskan server untuk mempertahankan state (status) mengenai kunci
publik.
- **Skema Basis Data:** Tabel sesi harus diperbarui untuk menyimpan `public_key` dan
`last_challenge` di samping `user_id` dan `session_expiry`.
- **Performa:** Operasi penyegaran melibatkan verifikasi kriptografis (misalnya,
memverifikasi tanda tangan ECDSA). Meskipun cepat, hal ini lebih membebani CPU
dibandingkan dengan memeriksa string sederhana. Namun, karena penyegaran hanya terjadi
setiap beberapa menit (tidak setiap permintaan), overhead-nya dapat diabaikan.
## 5. Implikasi Bisnis dan Produk
Di luar spesifikasi teknis, DBSC membawa implikasi signifikan terhadap strategi bisnis,
peta jalan produk, dan postur kepatuhan.
### 5.1 ROI Keamanan Tanpa Hambatan
Inisiatif keamanan sering dipandang sebagai pusat biaya (cost centers) atau penghasil
hambatan. DBSC membalik narasi ini. Diagram berikut menggambarkan bagaimana pengikatan
perangkat menciptakan efek berantai dari manfaat bisnis:
- **Pengurangan Penipuan:** Dengan menetralisir vektor utama untuk Pengambilalihan Akun
(ATO), bisnis dapat menghemat jutaan dalam kerugian penipuan.
- **Biaya Dukungan:** [Pemulihan akun](https://www.corbado.com/id/blog/cara-menjadi-sepenuhnya-tanpa-password)
mahal.
[Mencegah peretasan sejak awal](https://fidoalliance.org/white-paper-dbsc-dpop-as-complementary-technologies-to-fido-authentication/)
secara langsung mengurangi beban operasional ini.
- **Optimasi Konversi:** Dalam [e-commerce](https://www.corbado.com/passkeys-for-e-commerce), setiap prompt login
merupakan titik potensial di mana pengguna berhenti (drop-off). DBSC memungkinkan
kebijakan "tetap masuk" yang agresif, memungkinkan checkout instan tanpa prompt kata
sandi.
### 5.2 Kepatuhan dan "Kecanggihan Terkini" (State of the Art)
Kerangka kerja regulasi seperti GDPR (General Data Protection Regulation) di Eropa
mengharuskan organisasi untuk menerapkan "langkah-langkah teknis dan organisasional yang
tepat" untuk memastikan keamanan.
- **Keamanan yang Dapat Dipertanggungjawabkan:** Saat DBSC menjadi standar, kemungkinan
akan ditafsirkan sebagai "kecanggihan terkini" untuk manajemen sesi. Jika terjadi
pembobolan, menunjukkan bahwa DBSC telah diimplementasikan bisa menjadi pembelaan yang
kuat terhadap klaim kelalaian.
- **Standar Perbankan (PSD2):** [Payment](https://www.corbado.com/passkeys-for-payment) Services Directive 2
mensyaratkan "Autentikasi Pelanggan Kuat" (SCA). Meskipun [SCA](https://www.corbado.com/id/blog/psd2-passkeys)
berfokus pada login, [penautan dinamis](https://www.corbado.com/id/blog/penautan-dinamis-passkeys-spc) sesi ke
perangkat sejalan secara sempurna dengan tujuan regulasi untuk mengikat autentikasi ke
jumlah dan penerima pembayaran tertentu.
### 5.3 Kepastian Tinggi vs. Kepastian Menengah
[Makalah teknis (whitepapers) FIDO Alliance](https://fidoalliance.org/white-paper-high-assurance-enterprise-fido-authentication/)
menyoroti konsep "Tingkat Kepastian" (Assurance Levels).
- **Kepastian Menengah:** Menggunakan kunci sandi yang disinkronkan (seperti di
[iCloud Keychain](https://www.corbado.com/glossary/icloud-keychain)). Bagus untuk aplikasi konsumen, dapat
dipulihkan, mudah digunakan.
- **Kepastian Tinggi:** Membutuhkan kunci yang terikat perangkat. Di sinilah DBSC
bersinar. Untuk sumber daya perusahaan (portal SDM, repositori kode) atau
[perbankan](https://www.corbado.com/passkeys-for-banking) bernilai tinggi, organisasi dapat menerapkan
kebijakan yang _hanya_ memungkinkan akses dari sesi yang terikat ke perangkat yang
dikelola secara spesifik. DBSC menyediakan mekanisme penegakan teknis untuk kebijakan
ini.
## 6. DBSC vs. Alternatif
Untuk sepenuhnya menghargai DBSC, kita harus membandingkannya dengan teknologi lain yang
telah berusaha memecahkan masalah serupa.
```mermaid
graph RL
subgraph "Cookie Tradisional"
TC1[Hanya Token Pembawa]
TC2[Rentan Pencurian]
TC3[Sesi Panjang = Risiko]
TC1 --> TC2
TC2 --> TC3
end
subgraph "Token Binding"
TB1[Pengikatan Lapisan TLS]
TB2[❌ Gagal: Infrastruktur Kompleks]
TB3[Rusak di Penyeimbang Beban]
TB1 --> TB2
TB2 --> TB3
end
subgraph "DPoP"
DP1[Pengikatan Token OAuth]
DP2[✅ Perlindungan API]
DP3[Bukan untuk Sesi Browser]
DP1 --> DP2
DP2 --> DP3
end
subgraph "DBSC"
D1[Pengikatan Lapisan HTTP]
D2[✅ Perlindungan Kunci Perangkat Keras]
D3[✅ Bekerja dengan CDN/LB]
D4[✅ Sesi Browser]
D1 --> D2
D2 --> D3
D3 --> D4
end
style TC2 fill:#ff6b6b,color:#fff
style TB2 fill:#ff6b6b,color:#fff
style D2 fill:#51cf66,color:#fff
style D3 fill:#51cf66,color:#fff
style D4 fill:#51cf66,color:#fff
style DP2 fill:#51cf66,color:#fff
```
### 6.1 DBSC vs. Token Binding
Seperti disebutkan, Token Binding berusaha mengikat sesi ke lapisan TLS.
- **Token Binding:** Memerlukan dukungan dari klien, server, _dan_ setiap lompatan di
antaranya (Penyeimbang Beban, TLS Terminators). Ia rusak saat koneksi diakhiri dan
dienkripsi ulang.
- **DBSC:**
[Beroperasi di lapisan aplikasi HTTP](https://fidoalliance.org/white-paper-dbsc-dpop-as-complementary-technologies-to-fido-authentication/).
DBSC melewati Penyeimbang Beban secara transparan sebagai header/cookie standar. Jauh
lebih mudah diterapkan pada arsitektur cloud modern (AWS/GCP/Azure) di mana TLS sering
kali ditangani oleh jaringan tepi penyedia cloud.
### 6.2 DBSC vs. DPoP (Menunjukkan Bukti Kepemilikan)
[DPoP (RFC 9449)](https://datatracker.ietf.org/doc/html/rfc9449) adalah standar untuk
token OAuth "sender-constrained". Ia mengikat token akses _dan_ token penyegaran ke kunci
publik—penting karena token penyegaran sendiri adalah kredensial pembawa yang berumur
panjang. Setiap permintaan API menyertakan bukti DPoP: JWT yang ditandatangani dengan
metode HTTP, URL, stempel waktu, dan pengenal unik. Spesifikasi kepastian tinggi seperti
[FAPI 2.0](https://openid.net/specs/fapi-2_0-security-profile.html) mengamanatkan token
yang dibatasi oleh pengirim; DPoP adalah metode yang direkomendasikan saat mTLS tidak
tersedia.
**Perbedaan utama:** Kunci DPoP hidup dalam konteks aplikasi. Praktik terbaik adalah
menggunakan OS API untuk penyimpanan yang tidak dapat diekstraksi, tetapi ini tidak
dipaksakan—banyak implementasi menyimpan kunci dalam memori yang dapat diakses
[JavaScript](https://www.corbado.com/id/blog/aplikasi-crud-react-express-mysql). Jika penyerang dapat
mengeksekusi kode arbitrer (XSS, malware), mereka dapat mengakses kunci DPoP atau membuat
bukti sesuai permintaan. DPoP menghentikan pemutaran ulang token _antar klien yang
berbeda_, tetapi tidak dapat melindungi konteks browser yang disusupi.
DBSC memindahkan bukti kepemilikan ke dalam browser dan perangkat keras. Kunci privat
hidup di dalam TPM atau secure enclave yang tidak dapat dibaca atau diekspor oleh
[JavaScript](https://www.corbado.com/id/blog/aplikasi-crud-react-express-mysql). Browser menangani protokol dan
menghasilkan tanda tangan tanpa mengekspos kunci ke kode aplikasi. Bahkan jika
[aplikasi web](https://www.corbado.com/id/blog/aplikasi-crud-react-express-mysql) sepenuhnya disusupi, penyerang
tidak dapat mencetak bukti baru untuk cookie yang dicuri di mesin lain.
| Aspek | DPoP | DBSC |
| --------------------- | ------------------------------------------ | ---------------------------------------- |
| **Target** | Token akses + penyegaran OAuth | Cookie sesi browser |
| **Penyimpanan kunci** | Konteks aplikasi (praktik terbaik: OS API) | Didukung perangkat keras (TPM) |
| **Ketahanan XSS** | ⚠️ Tergantung implementasi | ✅ Kunci tidak dapat diekspor |
| **Penggunaan utama** | Aplikasi native, SPA, FAPI 2.0 | Sesi web yang berhadapan dengan pengguna |
**Sinergi:** Seperti
[catatan FIDO Alliance](https://fidoalliance.org/white-paper-dbsc-dpop-as-complementary-technologies-to-fido-authentication/),
kunci sandi menghilangkan phising saat login, sedangkan DBSC/DPoP melindungi token
pasca-autentikasi. Arsitektur modern menggabungkan keduanya: DPoP untuk OAuth API
(khususnya open perbankan yang diatur), DBSC untuk sesi browser. Bersama-sama mereka
menutup vektor serangan "lift and shift" di seluruh siklus hidup sesi.
### 6.3 DBSC vs. Cookie Berumur Pendek (Saja)
Cukup mempersingkat masa berlaku cookie (misalnya, menjadi 15 menit) akan meningkatkan
keamanan tetapi merusak UX. Pengguna dipaksa untuk sering login. DBSC memberikan keamanan
_efektif_ dari cookie 5 menit dengan _Pengalaman Pengguna_ dari cookie 30 hari.
## 7. Shared Signals dan Respons Dinamis (CAEP/RISC)
```mermaid
%%{init: {
"theme": "default",
"themeVariables": {
"actorBkg": "#ffffff",
"actorBorder": "#000000",
"noteBkgColor": "#f1f3f5",
"noteTextColor": "#000000",
"activationBkgColor": "#e0e0e0",
"actorColours": {
"ST": "#ff6b6b",
"IdP": "#4c6ef5"
}
}
}}%%
sequenceDiagram
participant ST as Alat Keamanan
(CrowdStrike, Defender)
participant IdP as Penyedia Identitas
(Okta, Google, Azure)
participant SP1 as Penyedia Layanan 1
(Slack)
participant SP2 as Penyedia Layanan 2
(Salesforce)
participant SP3 as Penyedia Layanan 3
(Aplikasi Bank)
participant Session as Sesi Pengguna
(Dilindungi DBSC)
Note over ST,Session: Fase Deteksi Ancaman
ST->>ST: Mendeteksi malware pada
perangkat pengguna
ST->>IdP: Sinyal RISC:
"Perangkat Disusupi"
Note over IdP,SP3: Fase Penyebaran Sinyal
IdP->>SP1: Acara CAEP:
"Perangkat Disusupi"
IdP->>SP2: Acara CAEP:
"Perangkat Disusupi"
IdP->>SP3: Acara CAEP:
"Perangkat Disusupi"
Note over SP1,Session: Fase Penegakan (dengan DBSC)
Session->>SP1: Upaya segarkan berikutnya
(dalam menit)
SP1-->>Session: x Tolak tanda tangan
Session->>SP2: Upaya segarkan berikutnya
SP2-->>Session: x Tolak tanda tangan
Session->>SP3: Upaya segarkan berikutnya
SP3-->>Session: x Tolak tanda tangan
Note over Session: Sesi dapat dihentikan pada upaya segarkan berikutnya
```
Potensi DBSC diperbesar saat dikombinasikan dengan
[**Shared Signals Framework (SSF)**](https://fidoalliance.org/white-paper-fido-and-the-shared-signals-framework/),
khususnya **Continuous Access Evaluation Profile (CAEP)** dan **Risk Management (RISC)**.
Catatan: SSF/CAEP adalah kemampuan ekosistem yang baru muncul—pola arsitekturnya
didefinisikan, namun penerapan lintas vendor secara luas masih dalam tahap pematangan.
Pada model lama, jika perangkat pengguna disusupi, Penyedia Identitas (IdP) tidak
mempunyai cara untuk memberitahu Penyedia Layanan (SP) untuk mematikan sesi _sekarang
juga_. SP harus menunggu cookie kedaluwarsa.
Alur DBSC + CAEP yang dibayangkan:
1. **Pemicu:** Alat keamanan titik akhir (seperti CrowdStrike atau Microsoft Defender)
mendeteksi malware di laptop pengguna.
2. **Sinyal:** Alat keamanan mengirimkan sinyal RISC ke Penyedia Identitas (misalnya,
Okta/Google).
3. **Penyebaran:** IdP mendorong kejadian CAEP ke aplikasi yang terhubung: "Perangkat
Disusupi."
4. **Penegakan (DBSC):** Saat berikutnya browser mencoba menyegarkan cookie berumur pendek
DBSC, server menolak tanda tangan dan mematikan sesi.\
[Pola arsitektur ini](https://fidoalliance.org/white-paper-fido-and-the-shared-signals-framework/) memungkinkan
pencabutan yang lebih cepat—latensi sebenarnya bergantung pada periode penyegaran situs
dan apakah mereka telah menerapkan DBSC dan SSF.
## 8. Dukungan Browser dan Ekosistem
Penerapan DBSC bergantung pada vendor browser. Lanskap pada tahun 2026 telah bergeser
secara material: Chrome memindahkan DBSC dari Origin Trial ke ketersediaan umum (GA) di
Windows pada April 2026, dengan macOS menyusul. Browser lain masih mengevaluasi.
### 8.1 Google Chrome
Google adalah pendorong utama DBSC dan browser pertama yang merilisnya secara luas.
- **Status (April 2026):**
[Chrome 146 merilis DBSC dalam ketersediaan umum di Windows](https://blog.google/security/protecting-cookies-with-device-bound-session-credentials/),
mengakhiri fase Origin Trial. Dukungan macOS, menggunakan Secure Enclave, diumumkan
untuk rilis Chrome mendatang.
- **Perangkat keras:** Windows menggunakan TPM, macOS akan menggunakan Secure Enclave.
Google telah menyatakan bahwa mereka juga sedang menjajaki **kunci berbasis perangkat
lunak** untuk memperluas perlindungan DBSC ke perangkat tanpa perangkat keras aman yang
didedikasikan.
- **Peta jalan:** Pengumuman GA Google juga mempublikasikan peta jalan langkah berikutnya:
- **Mengamankan identitas terfederasi:** pengikatan DBSC lintas asal sehingga sesi
pihak pengandal (RP) tetap terikat ke kunci perangkat yang sama dengan sesi penyedia
identitas (IdP), mempertahankan rantai kepercayaan yang tidak terputus melalui
[SSO](https://www.corbado.com/blog/passkeys-single-sign-on-sso).
- **Registrasi lanjutan:** mengikat sesi DBSC ke materi kunci tepercaya yang sudah ada
sebelumnya seperti **sertifikat mTLS** atau **kunci keamanan perangkat keras**,
alih-alih menghasilkan kunci baru saat masuk.
- **Dukungan perangkat yang lebih luas:** kunci berbasis perangkat lunak untuk
perangkat tanpa TPM / Secure Enclave.
- **Hasil operasional:** Selama peluncuran, Google melaporkan "pengurangan signifikan
dalam pencurian sesi" untuk sesi yang dilindungi oleh DBSC.
- **Akun Google:** Secara terpisah, Google telah meluncurkan perlindungan bergaya DBSC
untuk
[cookie akun Google di Chrome untuk Windows](https://support.google.com/chrome/a/answer/2657289),
yang dikendalikan melalui kebijakan perusahaan. Ini melindungi Gmail/Workspace dan kini
menjadi keluarga teknologi yang sama yang bersifat GA untuk web umum.
### 8.2 Microsoft Edge & Windows
Microsoft berpartisipasi secara aktif.
- **Status:** Edge menjalankan
[Origin Trial DBSC](https://developer.microsoft.com/microsoft-edge/origin-trials/trials/0c292c9b-58fe-4f23-b066-c3b58911024d)
di Windows yang berakhir pada Oktober 2025. Belum ada uji coba pengganti atau GA yang
diumumkan.
- **Konteks Perusahaan:** Edge menggunakan
[arsitektur "Primary Refresh Token" (PRT)](https://learn.microsoft.com/en-us/entra/identity/devices/concept-primary-refresh-token)
untuk [SSO](https://www.corbado.com/blog/passkeys-single-sign-on-sso) Entra/Azure AD, yang secara konseptual
mirip dengan DBSC. PRT tetap merupakan mekanisme khusus Microsoft; tidak ada rencana
yang diumumkan untuk menyatukannya dengan standar web DBSC untuk situs pihak ketiga.
### 8.3 Apple Safari (WebKit)
Sikap Apple sangat penting untuk cakupan seluler.
- **Status:** WebKit memiliki
[masalah standar posisi](https://github.com/WebKit/standards-positions/issues/281) yang
mengevaluasi DBSC dengan masalah kegunaan/privasi yang dicatat. Catatan rilis Safari
tidak menyebutkan DBSC. Tidak ada pernyataan publik "sedang menerapkan" yang ada.
- **Privasi Pertama:** Kekhawatiran utama Apple adalah bahwa DBSC dapat digunakan untuk
"cookie super" (pelacakan yang tidak dapat dihapus). Spesifikasi W3C mengatasi hal ini
dengan memastikan kunci dibersihkan bersama dengan data situs web.
- **Keterlibatan:** WebKit sedang terlibat dengan proses standar, namun status
implementasinya tidak jelas—"sedang didiskusikan" bukan "sedang dikembangkan."
### 8.4 Mozilla Firefox
Mozilla memiliki
[masalah standar posisi](https://github.com/mozilla/standards-positions/issues/912) yang
mengevaluasi DBSC dengan kekhawatiran yang dicatat tentang kompleksitas dan privasi. Tidak
ada komitmen publik untuk menerapkan setelah standar tersebut stabil.
## 9. Rekomendasi: Melindungi Pengguna Saat Ini
Mengingat dukungan ekosistem saat ini untuk DBSC dan kunci sandi, organisasi harus
mengambil pendekatan bertahap untuk menerapkan teknologi pelengkap ini. Peta jalan di
bawah ini menguraikan tindakan segera dan pencapaian perencanaan strategis:
### 9.1 Tindakan Segera (kini Chrome 146 adalah GA)
1. **Terapkan Kunci Sandi Terlebih Dahulu**: Mulai dengan
[implementasi kunci sandi](https://www.corbado.com/id/blog/passkey-day-2-problems) untuk mengamankan lapisan
autentikasi. Ini memberikan perlindungan langsung terhadap phising kredensial dan
merupakan prasyarat untuk mendapatkan nilai nyata dari DBSC.
2. **Kirim Endpoint Registrasi dan Penyegaran DBSC**: Dengan rilisnya Chrome 146 GA,
pekerjaan realistis saat ini adalah integrasi backend: tambahkan header
`Secure-Session-Registration` pada respons login dan terapkan `/dbsc/register` plus
endpoint penyegaran yang memverifikasi tantangan yang ditandatangani. Kode front-end
tidak perlu diubah.
3. **Terapkan Sesi Berumur Pendek dengan Token Penyegaran**: Jika Anda belum siap untuk
DBSC, terapkan pola arsitektur token berumur pendek dengan mekanisme penyegaran. Ini
mempersiapkan backend Anda untuk DBSC sekaligus meningkatkan keamanan saat ini.
### 9.2 Perencanaan Strategis (12 bulan ke depan)
1. **Adopsi Pendekatan Hibrida**: Gunakan deteksi fitur untuk menyajikan DBSC ke browser
yang mumpuni (saat ini Chrome 146+ di Windows, macOS Secure Enclave selanjutnya) sambil
mempertahankan opsi cadangan. Hal ini memaksimalkan keamanan tanpa mengecualikan
pengguna di Safari, Firefox, atau Edge.
2. **Bersiap untuk Item Peta Jalan Berikutnya**: Google secara eksplisit menyebutkan
identitas terfederasi (pengikatan SSO lintas asal), registrasi lanjutan (mTLS / kunci
perangkat keras), dan kunci berbasis perangkat lunak untuk cakupan perangkat yang lebih
luas. Jika Anda mengoperasikan lapisan SSO atau IdP, mulailah menentukan cakupan
pengikatan lintas asal dari sekarang.
3. **Integrasi dengan Penyedia Identitas**: Jika menggunakan Okta,
[Auth0](https://www.corbado.com/blog/auth0-passkeys-analysis), atau IdP serupa, bekerjalah dengan mereka untuk
mengaktifkan dukungan DBSC di SDK mereka. Banyak yang berpartisipasi dalam Origin
Trials dan secara aktif merilis kemampuan DBSC sekarang setelah Chrome berstatus GA.
### 9.3 Praktik Terbaik Implementasi
- **Mulai dengan Target Bernilai Tinggi**: Prioritaskan DBSC untuk panel admin, transaksi
finansial, dan akses data sensitif.
- **Gunakan Solusi Terkelola**: Pertimbangkan platform seperti Corbado yang menangani
kompleksitas implementasi DBSC dan kompatibilitas browser.
- **Ukur dan Iterasi**: Lacak metrik seperti upaya pembajakan sesi, tiket dukungan, dan
hambatan pengguna untuk menunjukkan ROI.
- **Bersiap untuk Kepatuhan**: Dokumentasikan implementasi DBSC Anda karena hal tersebut
kemungkinan akan menjadi persyaratan kepatuhan untuk menangani data sensitif.
## 10. Bagaimana Corbado dapat membantu: Jembatan ke Masa Depan
Mengimplementasikan DBSC dari awal merupakan upaya rekayasa yang berat. Ini membutuhkan
keahlian kriptografis, pengetahuan mendalam tentang inkonsistensi browser, dan
infrastruktur server yang tangguh untuk mengelola kunci dan tantangan. Di sinilah
**Corbado** berfungsi sebagai penggerak.
### 10.1 Fondasi: Kunci Sandi
Anda tidak dapat membangun sesi dengan kepastian tinggi di atas login dengan kepastian
rendah. Jika pengguna masuk dengan kata sandi yang lemah, sesi tersebut hanya seaman kata
sandi itu. Produk inti Corbado (**kunci sandi terkelola**) memberikan fondasi yang
diperlukan. Dengan mengintegrasikan Corbado, organisasi dapat dengan mudah menerapkan
kunci sandi, memastikan bahwa awal sesi tahan terhadap phising.
### 10.2 Masa Depan: DBSC untuk Deteksi Perangkat Tepercaya
Corbado akan memanfaatkan DBSC untuk meningkatkan deteksi perangkat yang tepercaya. Saat
sinyal DBSC tersedia, mereka memberikan bukti kriptografis bahwa sebuah sesi berasal dari
perangkat tertentu yang memungkinkan Corbado meningkatkan tingkat kepercayaan autentikasi
secara sesuai.
- **Memecahkan Ambiguitas Kunci Sandi yang Disinkronkan:** Kunci sandi yang disinkronkan
nyaman tetapi menciptakan celah kepercayaan: saat pengguna melakukan autentikasi dengan
kunci sandi yang disinkronkan, Anda tidak dapat membedakan apakah itu laptop biasa
mereka atau perangkat baru yang baru saja menyinkronkan kredensial. DBSC menutup celah
ini. Dengan memeriksa apakah perangkat memiliki pengikatan DBSC yang mapan, Corbado
dapat memverifikasi bahwa perangkat tersebut benar-benar dikenal dan dipercaya, bukan
hanya sinkronisasi pertama kali.
- **Kepercayaan yang Lebih Tinggi untuk Perangkat yang Dikenal:** Ketika sinyal DBSC
mengonfirmasi perangkat telah terlihat sebelumnya, Corbado dapat membuat keputusan
risiko yang lebih meyakinkan: lebih sedikit prompt
[step-up authentication](https://www.corbado.com/glossary/step-up-authentication) untuk pengguna yang kembali
secara sah, pengawasan yang lebih ketat untuk sesi dari perangkat yang tidak dikenali.
- **Melengkapi Kecerdasan Kunci Sandi:** Sinyal DBSC terintegrasi dengan mesin
[**Passkey Intelligence**](https://docs.corbado.com/corbado-connect/features/passkey-intelligence)
Corbado yang sudah ada. Kombinasi autentikasi berbasis kunci sandi dan pengikatan
perangkat berbasis DBSC menciptakan rantai kepercayaan lengkap mulai dari login hingga
seluruh siklus hidup sesi.
Untuk pertanyaan tentang bagaimana Corbado berencana mengintegrasikan DBSC ke platformnya,
[hubungi tim kami](https://www.corbado.com/contact).
### 10.3 Cadangan yang Anggun (Realitas "Hibrida")
Untuk beberapa tahun ke depan, web akan menjadi hibrida. Sebagian pengguna akan memiliki
browser yang mendukung DBSC (Chrome di [Windows 11](https://www.corbado.com/blog/passkeys-windows-11)); sebagian
lainnya akan berada di sistem lama. Menangani fragmentasi ini sulit. Mesin
[**Passkey Intelligence**](https://docs.corbado.com/corbado-connect/features/passkey-intelligence)
Corbado dirancang untuk menangani logika cadangan semacam ini menyajikan kunci sandi ke
perangkat yang mumpuni dan cadangan ke perangkat lain. Kecerdasan yang sama ini berlaku
pada pengikatan sesi, memastikan bahwa keamanan dimaksimalkan untuk setiap pengguna sesuai
dengan kemampuan perangkat mereka.
## 11. Kesimpulan: Jalan ke Depan untuk DBSC
Era "Token Pembawa" hampir berakhir. Manajemen sesi saat ini gagal secara masif — token
pembawa dapat dicuri oleh operasi malware skala industri dan digunakan dari perangkat apa
pun, memungkinkan pengambilalihan akun yang melewati metode autentikasi terkuat sekalipun.
Kerentanan mendasar ini telah menciptakan ekonomi bawah tanah bernilai miliaran.
Kredensial Sesi Terikat Perangkat (DBSC) mewakili jawaban industri yang sedang muncul.
Tidak seperti cookie aman tradisional dengan flag HttpOnly dan rahasia statisnya, DBSC
menambahkan bukti kepemilikan kriptografis melalui kunci yang terikat pada perangkat. Hal
ini membuat cookie yang dicuri menjadi jauh kurang berharga. Mereka tidak dapat disegarkan
dari perangkat lain. Ketika Token Binding gagal karena memerlukan perubahan lapisan TLS
yang kompleks di semua infrastruktur, DBSC berhasil dengan beroperasi di lapisan aplikasi
HTTP, kompatibel dengan arsitektur penyeimbang beban dan CDN yang ada. Catatan: DBSC telah
mendokumentasikan jalur cadangan di mana browser melewatkan pengikatan (TPM tidak
tersedia, kesalahan jaringan), sehingga ia sangat mengurangi tetapi tidak menghilangkan
risiko pencurian cookie.
Sinergi antara DBSC dan Kunci Sandi secara signifikan meningkatkan standar bagi penyerang
di seluruh perjalanan pengguna. Kunci sandi menghilangkan phising kredensial saat login,
sementara DBSC membuat pembajakan sesi melalui pencurian cookie jarak jauh jauh lebih
sulit - bersama-sama membentuk kerangka kerja identitas "kepastian tinggi" yang
dibayangkan oleh [FIDO Alliance](https://www.corbado.com/glossary/fido-alliance). Dengan
[Chrome 146 merilis DBSC dalam GA di Windows pada April 2026](https://blog.google/security/protecting-cookies-with-device-bound-session-credentials/)
dan dukungan Secure Enclave macOS yang mendarat selanjutnya, standar ini telah beralih
dari fase persiapan ke fase peluncuran. Peta jalan yang diterbitkan Google (identitas
terfederasi, registrasi mTLS / kunci perangkat keras, kunci berbasis perangkat lunak)
menandakan 12 bulan ekspansi ke depan.
Bagi Manajer Produk, kasus bisnisnya sangat menarik: DBSC memungkinkan sesi aman "tak
terbatas" yang secara dramatis mengurangi
[hambatan login](https://www.corbado.com/id/blog/hambatan-login-membunuh-konversi) sekaligus memotong kerugian
penipuan dan biaya dukungan. ROI terwujud dalam rasio konversi yang lebih tinggi, lebih
sedikit tiket reset kata sandi, dan insiden pengambilalihan akun yang dieliminasi.
Organisasi yang menggunakan OAuth dapat memanfaatkan konsep pengikatan kunci yang sama
melalui DPoP untuk token API, sementara integrasi dengan Shared Signals (CAEP/RISC)
memungkinkan respons ancaman waktu nyata — secara instan mencabut sesi yang disusupi pada
upaya penyegaran berikutnya.
Penerapan tidak mengharuskan membangun dari awal. Platform seperti
[Corbado](https://www.corbado.com/features) menyediakan infrastruktur kunci sandi dan
sedang melacak perkembangan DBSC untuk mengintegrasikan pengikatan perangkat seiring
pematangan dukungan browser. [Spesifikasi W3C](https://www.w3.org/TR/dbsc/) merupakan Draf
Kerja aktif, Chrome 146 sudah berstatus GA di Windows dan sedang diluncurkan ke macOS, dan
browser lainnya masih mengevaluasi standar tersebut.
Lintasannya jelas: organisasi yang mulai mengadopsi Kunci Sandi dan DBSC hari ini akan
berada pada posisi terbaik untuk masa depan tanpa kata sandi dan tahan phising.
Pertanyaannya bukanlah apakah akan menerapkan sesi terikat perangkat, tetapi seberapa
cepat Anda dapat menerapkannya untuk melindungi pengguna dan bisnis Anda. Masa depan
keamanan web tidak hanya diautentikasi; ia terikat secara kriptografis ke perangkat yang
kita percayai.
## Pertanyaan yang Sering Diajukan
### Bagaimana DBSC bekerja sama dengan CAEP dan RISC untuk mencabut sesi yang disusupi secara real-time?
Ketika alat keamanan titik akhir seperti CrowdStrike mendeteksi malware, alat tersebut
mengirimkan sinyal RISC ke Penyedia Identitas, yang kemudian mendorong peristiwa
'Perangkat Disusupi' CAEP ke aplikasi yang terhubung. Pada upaya segarkan DBSC berikutnya
(dalam hitungan menit), aplikasi tersebut menolak tanda tangan sesi dan memutus akses.
Penerapan CAEP/RISC lintas vendor masih dalam tahap pematangan.
### Apa perbedaan antara DBSC dan DPoP dalam melindungi sesi aplikasi web?
DPoP (RFC 9449) mengikat akses OAuth dan token penyegaran ke kunci publik pada lapisan
aplikasi, terutama untuk melindungi panggilan API di
[aplikasi native](https://www.corbado.com/id/blog/webauthn-relying-party-id-rpid-kunci-sandi) dan SPA. DBSC
mengikat cookie sesi browser ke kunci TPM yang didukung perangkat keras yang tidak dapat
dibaca atau diekspor oleh JavaScript, melindungi sesi yang berhadapan dengan pengguna
bahkan ketika [aplikasi web](https://www.corbado.com/id/blog/aplikasi-crud-react-express-mysql) itu sendiri
disusupi oleh XSS atau malware.
### Mengapa DBSC memungkinkan durasi sesi yang lebih panjang tanpa meningkatkan risiko keamanan?
Desain aman tradisional mengamanatkan waktu batas sesi (timeout) yang singkat untuk
membatasi kerusakan jika cookie dicuri dan diputar ulang dari jarak jauh. DBSC mengikat
kemampuan segarkan ke kunci privat perangkat asal, sehingga cookie curian yang digunakan
dari perangkat berbeda gagal dalam tantangan kriptografis. Sesi bisa menjadi tidak
terbatas secara efektif karena serangan pemutaran ulang jarak jauh telah dinetralkan.
### ROI bisnis apa yang dapat diharapkan perusahaan dari penerapan DBSC?
DBSC menetralkan pencurian cookie sebagai vektor utama Pengambilalihan Akun, secara
langsung mengurangi kerugian penipuan dan biaya dukungan
[pemulihan akun](https://www.corbado.com/id/blog/cara-menjadi-sepenuhnya-tanpa-password). Sesi panjang yang aman
menghilangkan prompt login berulang, meningkatkan rasio konversi di
[e-commerce](https://www.corbado.com/passkeys-for-e-commerce) dan mengurangi drop-off.
[FIDO Alliance](https://www.corbado.com/glossary/fido-alliance) memposisikan DBSC sebagai peningkatan standar
keamanan yang secara bersamaan menurunkan hambatan pengguna.