Penjelasan Kredensial Sesi Terikat Perangkat (DBSC)

Whitepaper Passkey Enterprise. Panduan praktis, pola peluncuran, dan KPI untuk program passkeys.

Dapatkan whitepaper

Status Dukungan Browser

Keterangan: ✅ Tersedia secara umum | 🚧 Diumumkan / dalam pengembangan | ⏸️ Uji coba berakhir | 🔄 Mengevaluasi/memantau | ❌ Belum tersedia

Catatan: DBSC berstatus GA di Windows dengan TPM pada Chrome 146 (April 2026). Dukungan macOS melalui 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

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 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 melalui adopsi standar FIDO (Fast Identity Online) dan kunci sandi, penyerang mengalihkan fokus mereka ke "pintu belakang": sesi aktif. Melakukan phising kata sandi menjadi lebih sulit, tetapi mencuri cookie sesi tetap sangat efektif. Tanggapan industri terhadap ancaman yang meningkat ini adalah Kredensial Sesi Terikat Perangkat (DBSC).

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. Dengan Chrome 146 (April 2026) merilis DBSC dalam GA di Windows, 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 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, 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 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?
9. Bagaimana DBSC terintegrasi dengan Shared Signals (CAEP/RISC) untuk respons ancaman waktu nyata?

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.

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 (mencegah akses JavaScript 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 yang berjalan pada perangkat host. "Infostealers" adalah 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, menyuntikkan token curian ke browser mereka sendiri untuk membajak sesi. Server, melihat cookie yang valid, berasumsi bahwa permintaan tersebut sah.

DBSC memperkenalkan faktor autentikasi 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 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.

Kunci sandi 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, sehingga menghilangkan phising kredensial. DBSC mengatasi masalah pasca-autentikasi membuat pembajakan sesi melalui pencurian cookie jauh lebih sulit. FIDO Alliance membingkai DBSC 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 dengan akses perangkat berkelanjutan atau serangan browser-in-the-middle waktu nyata pada perangkat yang sama.

Bagaimana Kunci Sandi dan DBSC bekerja sama

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). DBSC tidak bergantung pada koneksi jaringan yang mendasarinya, membuatnya kompatibel dengan penyeimbang beban, proksi, dan infrastruktur cloud yang ada.

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.

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.

graph TD
    A[Pengguna Mengunduh<br/>Perangkat Lunak Berbahaya] -->|Eksekusi| B[Infostealer Aktif<br/>di Perangkat]
    B --> C[Menemukan Data Browser]
    C --> D[Penyimpanan Cookie<br/>Chrome/Edge/Firefox]
    C --> E[Basis Data Kata Sandi]
    C --> F[Dompet Kripto]

    D --> G[Mendekripsi Menggunakan<br/>Kredensial OS]
    E --> G
    F --> G

    G --> H[Membuat File Log<br/>dengan Data Curian]
    H --> I[Eksfiltrasi ke Server C2]
    I --> J[Pasar Web Gelap]

    J --> K[Penyerang Membeli Log]
    K --> L[Mengimpor Cookie ke<br/>Browser Sendiri]
    L --> M[Bypass MFA]
    M --> N[Pengambilalihan Akun<br/>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) 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, informasi sistem, dan terkadang kunci dompet kripto.

Log-log ini dikumpulkan dan dijual di pasar 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."

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, tampak bagi server seolah-olah pengguna kembali ke tab yang aktif.

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 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 / kunci sandi) menjadi pencurian cookie (yang sering kali tidak dapat dihentikan oleh 2SV / kunci sandi).

Secara historis, mesin risiko telah mencoba mendeteksi pencurian sesi dengan menganalisis sidik jari perangkat, melihat string User-Agent, 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.

Kredensial Sesi Terikat Perangkat (DBSC) memperkenalkan API dan protokol terstandarisasi 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.

Siklus hidup DBSC memungkinkan transisi yang mulus dari sesi standar ke sesi terikat, memastikan kompatibilitas mundur dan peningkatan progresif.

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

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
   
   \<JWT Header\>.\<JWT Payload containing Public Key\>.\<Signature\>
   

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."

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.

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: \<Session ID\>
   Secure-Session-Response: \<JWT Signature of Challenge\>
   

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.

graph LR
    subgraph "Perangkat Korban"
        A[Sesi Pengguna<br/>dengan DBSC]
        B[Kunci Privat<br/>HSM/TPM]
        C[Cookie +<br/>ID Sesi]
        A --> B
        A --> C
        B -.->|Tidak dapat diekspor| X[Tidak Dapat Mengekstraksi<br/>Kunci Privat]
    end

    subgraph "Skenario Serangan"
        D[RedLine Stealer<br/>Menginfeksi Perangkat]
        D --> E[Mencuri Cookie<br/>& ID Sesi]
        E --> F[Ekspor ke<br/>Penyerang]
    end

    subgraph "Perangkat Penyerang"
        G[Mengimpor Cookie<br/>Curian]
        H[Mencoba<br/>Menggunakan Sesi]
        I[Server Meminta<br/>Penyegaran DBSC]
        J[Tidak Dapat Menandatangani<br/>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.

Privasi merupakan tujuan desain sentral DBSC. Spesifikasi W3C 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.

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.

Di luar spesifikasi teknis, DBSC membawa implikasi signifikan terhadap strategi bisnis, peta jalan produk, dan postur kepatuhan.

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 mahal. Mencegah peretasan sejak awal secara langsung mengurangi beban operasional ini.
• Optimasi Konversi: Dalam 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.

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 Services Directive 2 mensyaratkan "Autentikasi Pelanggan Kuat" (SCA). Meskipun SCA berfokus pada login, penautan dinamis sesi ke perangkat sejalan secara sempurna dengan tujuan regulasi untuk mengikat autentikasi ke jumlah dan penerima pembayaran tertentu.

Makalah teknis (whitepapers) FIDO Alliance menyoroti konsep "Tingkat Kepastian" (Assurance Levels).

• Kepastian Menengah: Menggunakan kunci sandi yang disinkronkan (seperti di 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 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.

Untuk sepenuhnya menghargai DBSC, kita harus membandingkannya dengan teknologi lain yang telah berusaha memecahkan masalah serupa.

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

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. 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.

DPoP (RFC 9449) 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 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. 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. Browser menangani protokol dan menghasilkan tanda tangan tanpa mengekspos kunci ke kode aplikasi. Bahkan jika aplikasi web sepenuhnya disusupi, penyerang tidak dapat mencetak bukti baru untuk cookie yang dicuri di mesin lain.

Sinergi: Seperti catatan FIDO Alliance, 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.

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.

%%{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<br/>(CrowdStrike, Defender)
    participant IdP as Penyedia Identitas<br/>(Okta, Google, Azure)
    participant SP1 as Penyedia Layanan 1<br/>(Slack)
    participant SP2 as Penyedia Layanan 2<br/>(Salesforce)
    participant SP3 as Penyedia Layanan 3<br/>(Aplikasi Bank)
    participant Session as Sesi Pengguna<br/>(Dilindungi DBSC)

    Note over ST,Session: Fase Deteksi Ancaman
    ST->>ST: Mendeteksi malware pada<br/>perangkat pengguna
    ST->>IdP: Sinyal RISC:<br/>"Perangkat Disusupi"

    Note over IdP,SP3: Fase Penyebaran Sinyal
    IdP->>SP1: Acara CAEP:<br/>"Perangkat Disusupi"
    IdP->>SP2: Acara CAEP:<br/>"Perangkat Disusupi"
    IdP->>SP3: Acara CAEP:<br/>"Perangkat Disusupi"

    Note over SP1,Session: Fase Penegakan (dengan DBSC)
    Session->>SP1: Upaya segarkan berikutnya<br/>(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), 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 memungkinkan pencabutan yang lebih cepat—latensi sebenarnya bergantung pada periode penyegaran situs dan apakah mereka telah menerapkan DBSC dan SSF.

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.

Google adalah pendorong utama DBSC dan browser pertama yang merilisnya secara luas.

• Status (April 2026): Chrome 146 merilis DBSC dalam ketersediaan umum di Windows, 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.
  • 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, yang dikendalikan melalui kebijakan perusahaan. Ini melindungi Gmail/Workspace dan kini menjadi keluarga teknologi yang sama yang bersifat GA untuk web umum.

Microsoft berpartisipasi secara aktif.

• Status: Edge menjalankan Origin Trial DBSC 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) untuk 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.

Sikap Apple sangat penting untuk cakupan seluler.

• Status: WebKit memiliki masalah standar posisi 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."

Mozilla memiliki masalah standar posisi yang mengevaluasi DBSC dengan kekhawatiran yang dicatat tentang kompleksitas dan privasi. Tidak ada komitmen publik untuk menerapkan setelah standar tersebut stabil.

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:

1. Terapkan Kunci Sandi Terlebih Dahulu: Mulai dengan implementasi kunci sandi 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.

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, 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.

• 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.

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.

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.

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 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 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.

Untuk beberapa tahun ke depan, web akan menjadi hibrida. Sebagian pengguna akan memiliki browser yang mendukung DBSC (Chrome di Windows 11); sebagian lainnya akan berada di sistem lama. Menangani fragmentasi ini sulit. Mesin 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.

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. Dengan Chrome 146 merilis DBSC dalam GA di Windows pada April 2026 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 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 menyediakan infrastruktur kunci sandi dan sedang melacak perkembangan DBSC untuk mengintegrasikan pengikatan perangkat seiring pematangan dukungan browser. Spesifikasi W3C 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.

Tentang Corbado

Corbado adalah Passkey Intelligence Platform untuk tim CIAM yang menjalankan autentikasi consumer dalam skala besar. Kami membantu Anda melihat apa yang tidak bisa ditunjukkan oleh log IDP dan tool analytics generik: device, versi OS, browser, dan credential manager mana yang mendukung passkey; mengapa enrollment tidak menjadi login; di mana flow WebAuthn gagal; dan kapan update OS atau browser diam-diam merusak login — semuanya tanpa mengganti Okta, Auth0, Ping, Cognito, atau IDP internal Anda. Dua produk: Corbado Observe menambah observability untuk passkey dan metode login lainnya. Corbado Connect menghadirkan managed passkey dengan analytics terintegrasi (berdampingan dengan IDP Anda). VicRoads menjalankan passkey untuk 5M+ pengguna dengan Corbado (aktivasi passkey +80%). Bicara dengan pakar Passkey →

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.

DPoP (RFC 9449) mengikat akses OAuth dan token penyegaran ke kunci publik pada lapisan aplikasi, terutama untuk melindungi panggilan API di aplikasi native 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 itu sendiri disusupi oleh XSS atau malware.

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.

DBSC menetralkan pencurian cookie sebagai vektor utama Pengambilalihan Akun, secara langsung mengurangi kerugian penipuan dan biaya dukungan pemulihan akun. Sesi panjang yang aman menghilangkan prompt login berulang, meningkatkan rasio konversi di e-commerce dan mengurangi drop-off. FIDO Alliance memposisikan DBSC sebagai peningkatan standar keamanan yang secara bersamaan menurunkan hambatan pengguna.