Cihazlara Bağlı Oturum Kimlik Bilgileri (DBSC) açıklandı

Kurumsal Passkey Whitepaper. Passkey programları için pratik rehberler, geçiş kalıpları ve KPI'lar.

Whitepaper al

Tarayıcı Destek Durumu

Gösterge: ✅ Genel erişimde | 🚧 Duyuruldu / geliştirme aşamasında | ⏸️ Deneme bitti | 🔄 Değerlendiriliyor/izleniyor | ❌ Henüz mevcut değil

Not: DBSC, Chrome 146 (Nisan 2026) itibarıyla TPM'ye sahip Windows'ta genel erişimdedir. Güvenli Bölge (Secure Enclave) üzerinden macOS desteği bir sonraki aşamada kullanıma sunuluyor. Google'ın belirtilen yol haritası, korumayı özel güvenli donanımı olmayan cihazlara genişletmek için yazılım tabanlı anahtarları da içermektedir.

Önemli Avantajlar: DBSC vs Mevcut Model

World Wide Web'in mimarisi, durumsuzluk (statelessness) ilkesi üzerine kurulmuştur. HTTP ilk tasarlandığında, istekler arasında kullanıcılar hakkında bilgi tutmuyordu. Bunu çözmek için, bir web sitesinden gönderilen ve kullanıcının bilgisayarında depolanan, sonraki her istekle web sitesine geri gönderilecek küçük bir veri parçası olan "çerez" (cookie) icat edildi. Onlarca yıl boyunca bu mekanizma, oturum yönetiminin temeli olarak hizmet etti. Bir kullanıcı giriş yaptığında, sunucu kimlik bilgilerini doğrular ve bir çerez verir. Bu çerez bir "taşıyıcı token" (bearer token) görevi görür. Fiziksel dünyada taşıyıcı belgesi, sahibine temsil ettiği hakları veya varlıkları veren bir belgedir; tahvili elinizde tutarsanız, tahvilin sahibi olursunuz. Benzer şekilde, HTTP'nin dijital dünyasında çerezi elinizde tutarsanız kullanıcı sizsiniz.

Bu taşıyıcı yeteneği, aynı zamanda web'in en büyük faydası ve en derin güvenlik açığıdır. Tüm oturumun ve dolayısıyla kullanıcının kimliğinin, verilerinin ve finansal varlıklarının güvenliği tamamen o çerez dizisinin gizliliğine dayanır. Kötü niyetli bir aktör bu diziyi kopyalayabilirse, ilk kimlik doğrulama kontrollerini tamamen atlayarak dünyanın herhangi bir yerinden, herhangi bir cihazdan kullanıcı kimliğine bürünebilir. Bu spesifik güvenlik açığı, endüstriyel ölçekte bir "çerez hırsızlığı" ve "oturum ele geçirme" yeraltı ekonomisinin doğmasına neden oldu.

Sektör, FIDO (Fast Identity Online) standartlarının ve Geçiş Anahtarlarının (Passkeys) benimsenmesiyle kimlik doğrulamanın "ön kapısını" başarıyla güçlendirirken, saldırganlar odaklarını "arka kapıya", yani aktif oturuma kaydırıyor. Bir parolayı oltalama yoluyla ele geçirmek (phishing) zorlaşıyor, ancak bir oturum çerezini çalmak tehlikeli derecede etkili olmaya devam ediyor. Sektörün artan bu tehdide yanıtı Cihazlara Bağlı Oturum Kimlik Bilgileridir (DBSC).

DBSC, web oturumlarının nasıl sürdürüldüğüne dair bir paradigma değişikliğini temsil eder. Oturumun kriptografik olarak cihaza bağlandığı bir modele doğru basit taşıyıcı tokenlerden uzaklaşmayı önerir. Chrome 146'nın (Nisan 2026) DBSC'yi Windows'ta GA olarak sunmasıyla, standart, web ekiplerinin bugün dağıtabileceği deneysel bir üretim yeteneğinden çıkmıştır. Chrome, Windows'ta TPM'leri kullanır ve ardından macOS'ta Secure Enclave (Güvenli Bölge) desteğini sunmaya hazırlanmaktadır; spesifikasyonun kendisi anahtar depolama konusunda agnostiktir, yalnızca "açıklanan tehdide karşı sağlam" olmasını gerektirir. Bu, çalınan çerezleri çok daha az değerli hale getirir. Bağlı anahtar olmadan başka bir cihazdan yenilenemezler.

Bu makale, güvenlik mimarları, ürün yöneticileri ve geliştiriciler için tasarlanmış DBSC'nin kapsamlı bir analizini sunmaktadır. Teknik mimariyi, "sürtünmesiz güvenliğin" ticari etkilerini, Paylaşılan Sinyaller (CAEP/RISC) gibi yeni ortaya çıkan standartlarla olan ilişkiyi ve kuruluşların Corbado gibi platformları kullanarak bu geleceğe nasıl hazırlanabileceğini araştırıyor.

Bu Makalenin Yanıtladığı Temel Sorular

1. Mevcut oturum yönetimi neden hesap devralmalarını önlemede başarısız oluyor?
2. DBSC, mevcut "Güvenli" (Secure) çerezlerden ve HttpOnly bayraklarından nasıl farklıdır?
3. DBSC ve Geçiş Anahtarları, oltalama saldırılarına karşı daha güçlü direnç için birlikte nasıl çalışır?
4. Token Binding'e ne oldu ve DBSC onun başarısız olduğu yerde neden başarılı oluyor?
5. Ürün Yöneticileri için ticari etkiler ve yatırım getirisi (ROI) fırsatları nelerdir?
6. DBSC'yi bugün hangi tarayıcılar ve işletim sistemleri destekliyor?
7. Kuruluşlar DBSC'yi sıfırdan oluşturmadan nasıl uygulayabilir?
8. DBSC, DPoP ve OAuth 2.0 arasındaki ilişki nedir?
9. DBSC, gerçek zamanlı tehdit yanıtı için Paylaşılan Sinyallerle (CAEP/RISC) nasıl entegre olur?

Bu yeni standardın karmaşıklığında gezinmek için, öncelikle mevcut oturum yönetimindeki temel sorunları ve DBSC'nin nasıl çözümler sunduğunu anlamalıyız. Bu alanların her biri, DBSC'nin ele aldığı kritik bir güvenlik açığını veya sınırlamayı temsil eder.

Mevcut oturum yönetiminin temel başarısızlığı, güvenin "taşınabilirliğidir". Bir sunucu bir oturum çerezi verdiğinde, aslında onu elinde tutan herkes için çalışan bir pasaport veriyor. Tarayıcılar HttpOnly ve Secure bayrakları (JavaScript erişimini engelleme ve HTTPS üzerinden iletimi sağlama) gibi savunmalar uygulamış olsa da, bu savunmalar yalnızca Siteler Arası Komut Dosyası Çalıştırma (XSS) veya ağ dinleme gibi belirli çıkarma vektörlerine karşı koruma sağlar. Ana bilgisayar cihazında çalışan kötü amaçlı yazılımlara karşı hiçbir koruma sunmazlar. "Bilgi Çalanlar" (Infostealers), özellikle diski tarayıcının çerez depolama dosyasını bulmak, şifresini çözmek (genellikle kullanıcının kendi işletim sistemi düzeyindeki kimlik bilgilerini kullanarak) ve içerikleri bir komuta ve kontrol sunucusuna sızdırmak için tasarlanmış kötü amaçlı yazılımlardır. Saldırgan çereze sahip olduğunda, oturumu ele geçirmek için çalınan tokeni kendi tarayıcısına enjekte ederek bir Çerez Aktarımı (Pass-the-Cookie) saldırısı gerçekleştirebilir. Sunucu, geçerli bir çerez görerek isteğin meşru olduğunu varsayar.

DBSC, kimlik doğrulamasının ikinci bir faktörünü oturum bakım döngüsünün kendisine dahil eder. Statik bir sır olan standart bir güvenli çerezin aksine, bir DBSC oturumu kısa ömürlü bir taşıyıcı token ve bir kriptografik sahiplik kanıtından oluşur. Tarayıcı, cihazda güvenli bir şekilde depolanan bir genel-özel anahtar çifti oluşturur. Sunucu, oturumu genel anahtara bağlar. Periyodik olarak, tarayıcı sunucudan gelen bir sorguyu imzalayarak özel anahtarı hala elinde tuttuğunu kanıtlamalıdır. Spesifikasyon, "açıklanan tehdide karşı sağlam" anahtar depolama gerektirir. Chrome, mevcut olduğunda Windows'ta TPM'yi kullanır. Bir saldırgan çerezi farklı bir cihazdan çalarsa, onu yenileyemez çünkü gerekli kriptografik imzayı oluşturamaz. "Taşıyıcı" yönü çok kısa bir pencereye indirgenirken, "bağlayıcı" yönü uzun vadeli süreklilik sağlar.

Geçiş Anahtarları ve DBSC, kullanıcı yaşam döngüsünün farklı aşamalarını güvence altına alan tamamlayıcı teknolojilerdir. Geçiş Anahtarları (FIDO2), parolalar olmadan bir oturum başlatmak için kimliği kanıtlama, kimlik doğrulama sorununu çözer ve böylece kimlik bilgisi avını ortadan kaldırır. DBSC, çerez hırsızlığı yoluyla oturum ele geçirmeyi önemli ölçüde zorlaştırarak kimlik doğrulama sonrası sorunu ele alır. FIDO Alliance, DBSC'yi oturum ele geçirmeye karşı "çıtayı yükselten" tamamlayıcı bir teknoloji olarak çerçeveler. Birlikte, giriş ve oturum yaşam döngüsü genelinde saldırı yüzeyini azaltırlar, ancak DBSC, devam eden cihaz erişimine sahip kötü amaçlı yazılımlara veya aynı cihazdaki gerçek zamanlı ortadaki tarayıcı (browser-in-the-middle) saldırılarına karşı koruma sağlamaz.

Geçiş Anahtarları ve DBSC nasıl birlikte çalışır?

DBSC, bu sorunu çözmeye yönelik ilk girişim değil. "Token Binding", çerezleri temel alınan TLS (Transport Layer Security - Taşıma Katmanı Güvenliği) bağlantısına bağlamaya çalışan önceki bir standarttı. Kriptografik olarak sağlam olmasına rağmen, TLS katmanına aşırı bağımlılığı nedeniyle Token Binding benimsenemedi. Modern web'de, TLS bağlantıları genellikle yük dengeleyiciler, CDN'ler veya ters proxy'lerde sonlandırılırken, uygulama mantığı bunların arkasındaki sunucularda bulunur. Token Binding bilgilerini bu karmaşık ağ katmanları aracılığıyla yaymak çok zor oldu. DBSC, tamamen Uygulama Katmanında (HTTP) çalışarak bu başarısızlıktan ders çıkarır. Temel ağ bağlantısına bağlı değildir, bu da onu mevcut yük dengeleyiciler, proxy'ler ve bulut altyapısıyla uyumlu hale getirir.

Ürün liderleri için DBSC, kullanıcı deneyimini (UX) iyileştirirken aynı zamanda güvenliği iyileştirme fırsatı sunar. Geleneksel olarak, yüksek güvenlik kısa oturum zaman aşımları anlamına geliyordu ve kullanıcıları sık sık (sürtünme) giriş yapmaya zorluyordu. Oturumu cihaza bağlayarak, uzaktan çerez hırsızlığı riski önemli ölçüde azalır. İşletmeler, çalınan çerezlerin başka bir cihazdan yenilenemeyeceğini bilerek daha uzun oturum süreleri düşünebilirler. Bununla birlikte, DBSC cihaz hırsızlığına, cihazdaki kalıcı kötü amaçlı yazılımlara veya kötü niyetli bir kullanıcı tarafından kötüye kullanıma karşı koruma sağlamadığından, oturum ömrü politikaları hala bu kalan riskleri yansıtmalıdır.

DBSC'nin arkasındaki aciliyeti anlamak için, modern tehdit ortamının karmaşıklığını takdir etmek gerekir. Oturum çerezlerinin çalınması, niş bir hacker hilesinden ölçeklenebilir, otomatikleştirilmiş bir sektöre dönüştü.

graph TD
    A[Kullanıcı Kötü Amaçlı Yazılım<br/>İndiriyor] -->|Yürütme| B[Bilgi Çalan (Infostealer) Cihazda<br/>Etkinleşiyor]
    B --> C[Tarayıcı Verilerini Buluyor]
    C --> D[Chrome/Edge/Firefox<br/>Çerez Depolaması]
    C --> E[Parola Veritabanı]
    C --> F[Kripto Cüzdanları]

    D --> G[İşletim Sistemi Kimlik Bilgilerini<br/>Kullanarak Şifreyi Çözüyor]
    E --> G
    F --> G

    G --> H[Çalınan Verilerle<br/>Günlük Dosyası Oluşturuyor]
    H --> I[C2 Sunucusuna Sızdırıyor]
    I --> J[Karanlık Web (Dark Web) Pazarı]

    J --> K[Saldırgan Günlüğü Satın Alıyor]
    K --> L[Çerezi Kendi<br/>Tarayıcısına Aktarıyor]
    L --> M[MFA'yı Atlıyor]
    M --> N[Hesabı Ele Geçirme<br/>Tamamlandı]

    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

Hizmet Olarak Kötü Amaçlı Yazılım (MaaS), siber suçlular için giriş engelini düşürdü. RedLine, Raccoon, Vidar ve Taurus gibi "Bilgi Çalanlar", öncelikli bir hedefle tasarlanmış, ticari olarak satılan kötü amaçlı yazılım türleridir: web tarayıcılarından veri sızdırma. Bu bilgi çalanlar oltalama e-postaları, kırılmış (cracked) yazılımlar veya kötü amaçlı reklamlar yoluyla dağıtılır. Yüklendikten sonra, Chrome, Edge ve Firefox gibi tarayıcıların verilerini depoladığı belirli dosya yollarını hedeflerler.

• Hedef: Çerez veritabanı (genellikle bir SQLite dosyası) ve Giriş Verileri veritabanı (kaydedilen parolalar).
• Mekanizma: Tarayıcılar, bu veritabanlarını kullanıcının işletim sistemi girişine bağlı Veri Koruma API'lerini (Windows'ta DPAPI) kullanarak şifreler. Kötü amaçlı yazılım kullanıcı olarak çalıştığı için, bu dosyaların şifresinin çözülmesini önemsiz bir şekilde isteyebilir.
• Çıktı: Kötü amaçlı yazılım, şifresi çözülmüş çerezleri, parolaları, sistem bilgilerini ve bazen kripto cüzdanı anahtarlarını içeren bir zip dosyası olan bir "günlük" (log) oluşturur.

Bu günlükler toplanır ve Genesis Market (kapatılmadan önce) ve Russian Market gibi karanlık web pazar yerlerinde satılır. Alıcılar, belirli yüksek değerli hedefler için aktif çerezler içeren günlükleri arayabilirler: "Salesforce," "Gmail," "Bank of America," veya "AWS Console."

Atlatma: Bir çerez günlüğünün değeri, Çok Faktörlü Kimlik Doğrulamayı (MFA) atlama yeteneğinde yatar. Çoğu MFA zorluğu (SMS, TOTP, Push) yalnızca giriş olayı sırasında ortaya çıkar. Oturum kurulduktan ve çerez verildikten sonra, sunucu kullanıcının güvenilir olduğunu varsayar. Geçerli bir oturum çerezini içe aktaran bir saldırgan, MFA kapısından kayarak geçer ve sunucuya aktif bir sekmeye dönen kullanıcı gibi görünür.

Bulut üretkenlik paketleri birincil hedeflerdir. Bir Google Workspace veya Microsoft Entra ID (eski adıyla Azure AD) hesabı için çalınan bir oturum çerezi, bir saldırgana kurumsal e-postalara, belgelere ve dahili sistemlere erişim sağlayabilir. Google'ın kendi tehdit istihbaratı, Google Hesaplarına erişmek için birincil vektör olarak çerez hırsızlığında büyük bir artış olduğunu bildirdi ve bunu DBSC'ye yaptıkları yatırımın arkasındaki itici güç olarak açıkça adlandırdı. 2 Adımlı Doğrulamayı (2SV) ve geçiş anahtarlarını zorunlu kıldıkça, saldırganların sadece kimlik bilgisi avından (2SV / geçiş anahtarlarının durdurduğu) çerez hırsızlığına (2SV / geçiş anahtarlarının genellikle durdurmadığı) yöneldiğini belirtiyorlar.

Tarihsel olarak, risk motorları User-Agent (Kullanıcı Aracısı) dizesine, ekran çözünürlüğüne, yüklü yazı tiplerine ve IP adresine bakarak cihaz parmak izlerini analiz ederek oturum hırsızlığını tespit etmeye çalıştı. Bir oturum çerezi aniden biraz farklı bir tuval (canvas) parmak izi ile yeni bir IP'den görünürse, sunucu bunu geçersiz kılabilir. Sorun: Tarayıcılardaki gizlilik girişimleri (Safari'nin Akıllı İzleme Koruması ve Chrome'un Privacy Sandbox'ı gibi), reklam izlemeyi durdurmak için bu parmak izlerinin entropisini aktif olarak azaltıyor. Bu, güvenlik için "iyi" parmak izi oluşturmayı giderek zorlaştırıyor. Ayrıca, saldırganlar artık kurbanın profiline mükemmel şekilde uyması için bu parmak izlerini taklit etmelerine olanak tanıyan, sezgisel algılamayı etkisiz hale getiren "Anti-Detect" (Algılama Karşıtı) Tarayıcılar kullanıyor. DBSC, bu olasılıksal tahmin oyununu deterministik kriptografik kanıtla değiştirir.

Cihazlara Bağlı Oturum Kimlik Bilgileri (DBSC), istemci cihazındaki bir anahtara bağlı oturumlar oluşturmak için standartlaştırılmış bir API ve protokol sunar. Spesifikasyon, "açıklanan tehdide karşı sağlam" anahtar depolama gerektirir ancak uygulama konusunda agnostiktir. Chrome, mevcut olduğunda Windows'ta TPM'yi kullanır. Bu bölüm, W3C Çalışma Taslağı ve Chrome belgelerinde tanımlanan mekaniği ayrıntılarıyla anlatmaktadır.

DBSC yaşam döngüsü, standart bir oturumdan bağlı bir oturuma sorunsuz bir geçiş sağlayarak geriye dönük uyumluluk ve aşamalı geliştirme sağlar.

sequenceDiagram
    participant User
    participant Browser
    participant HSM as HSM (TPM/Secure Enclave)
    participant Server

    Note over User,Server: Aşama 1: Kimlik Doğrulama ve Bağlama
    User->>Browser: Kimlik bilgileri/geçiş anahtarı ile giriş
    Browser->>Server: Kimlik doğrulama isteği
    Server->>Browser: Başarı + DBSC kayıt başlığı
    Browser->>HSM: Anahtar çifti oluştur
    HSM->>Browser: Genel/Özel anahtar (özel anahtar dışa aktarılamaz)
    Browser->>Server: Genel anahtarı kaydet (JWT imzalı)
    Server->>Server: Oturumu genel anahtara bağla
    Server->>Browser: Kısa ömürlü çerez (5 dk)

    Note over User,Server: Aşama 2: Normal Kullanım
    loop 5 dakika içinde her istek
        Browser->>Server: Çerezli istek
        Server->>Browser: Yanıt
    end

    Note over User,Server: Aşama 3: Yenileme (süresi dolduktan sonra)
    Browser->>Server: Süresi dolmuş çerezle istek
    Server->>Browser: 401 + Sorgu nonce (Challenge nonce)
    Browser->>HSM: Sorguyu imzala
    HSM->>Browser: İmza
    Browser->>Server: İmza kanıtı
    Server->>Server: Depolanan genel anahtarla doğrula
    Server->>Browser: Yeni kısa ömürlü çerez
    Browser->>Server: Orijinal isteği yeniden dene
    Server->>Browser: Başarı yanıtı

Bağlama işlemi, kullanıcı standart yöntemleri (parola, geçiş anahtarı vb.) kullanarak kimlik doğrulamasını başarıyla yaptıktan hemen sonra başlar.

1. Sunucu Sinyali: Başarılı giriş üzerine, sunucu bir oturum çerezi ayarlar (her zamanki gibi) ancak DBSC desteğini gösteren belirli bir başlık ekler.

   HTTP
   HTTP/1.1 200 OK
   Set-Cookie: session_id=xyz123...; Secure; HttpOnly; SameSite=Strict
   Secure-Session-Registration: (ES256 RS256); path="/auth/dbsc/register"
   

   • Secure-Session-Registration başlığı tarayıcıya şunu söyler: "ES256 ve RS256 algoritmalarını destekliyorum. Lütfen /auth/dbsc/register uç noktasında bağlı bir oturum kaydedin."

2. Anahtar Oluşturma: Tarayıcı bu başlığı ayrıştırır. Cihazda güvenli bir şekilde depolanan yeni bir asimetrik anahtar çifti (örn. Eliptik Eğri P-256) oluşturur.

   • Uygulama Notu: Chrome, mevcut olduğunda Windows'ta TPM kullanır; spesifikasyon, depolama mekanizması konusunda agnostiktir, yalnızca "açıklanan tehdide karşı sağlam" olmasını gerektirir.
   • Gizlilik Kapsamı: Anahtar, web kökenine (örn. bank.com) göre kapsamlandırılır. Tarayıcı, siteler arası izlemeyi önleyerek bu anahtarın retailer.com için asla kullanılmamasını sağlar.

3. Kayıt İsteği: Tarayıcı, belirtilen kayıt yoluna bir istek gönderir. Bu istek, Özel Anahtar (kendinden imzalı onay) tarafından imzalanmış, bir JSON Web Token (JWT) içindeki yeni oluşturulan Genel Anahtarı (Public Key) içerir.

   HTTP
   POST /auth/dbsc/register HTTP/1.1
   Content-Type: application/jwt
   
   \<JWT Header\>.\<JWT Payload containing Public Key\>.\<Signature\>
   

4. Oturum Bağlama: Sunucu, genel anahtarın işlevsel olduğundan emin olmak için imzayı doğrular. Ardından, kullanıcının oturumunu (session_id=xyz123) bu özel Genel Anahtar ile ilişkilendirmek için veritabanını günceller. Bu andan itibaren oturum "bağlıdır".

Güvenliği performansla dengelemek için (güvenli anahtar işlemleri gecikme ekleyebilir), DBSC çift tokenli bir sistem kullanır.

1. Verme: Sunucu yeni, kısa ömürlü bir çerez (örneğin 5 dakika geçerli) verir. Buna access_token diyelim.
2. Kullanım: Tarayıcı bu access_token'ı tüm normal istekler (görüntüleri getirme, API çağrıları, sayfalarda gezinme) için kullanır. Çerez geçerli olduğu sürece hiçbir kriptografik işlem yapılmaz. Bu, gezinmenin hızlı kalmasını sağlar.
3. Sona Erme: 5 dakika sonra access_token'ın süresi dolar.

Güvenlik mekanizmasının kalbi budur. Kısa ömürlü çerezin süresi dolduğunda, farklı bir cihazdaki saldırgan kilitlenir, ancak meşru kullanıcı (bağlı anahtara erişimi olan) devam edebilir.

1. Tespit: Tarayıcı bir istekte bulunmaya çalışır. Çerezin süresinin dolduğunu fark eder (veya sunucu 401 veya belirli bir Secure-Session-Challenge başlığı döndürür).
2. Kesişme: Tarayıcı ağ isteğini duraklatır. Kullanıcıya bir hata göstermez.
3. Yenileme İsteği: Tarayıcı, oturum yapılandırmasında tanımlanan yenileme uç noktasını otomatik olarak çağırır.
   • Sunucu kriptografik bir Sorgu (bir nonce) gönderir.
   • Tarayıcı, bu sorguyu imzalamak için bağlı anahtarı kullanır.
   • İmza, özel anahtarın sahipliğini kanıtlar.
4. Gönderim: Tarayıcı, imzalı sorguyu sunucuya geri gönderir.

   HTTP
   POST /auth/dbsc/refresh HTTP/1.1
   Sec-Secure-Session-Id: \<Session ID\>
   Secure-Session-Response: \<JWT Signature of Challenge\>
   

5. Doğrulama: Sunucu, imzayı doğrulamak için depolanan Genel Anahtarı kullanır.
   • Geçerliyse: Sunucu isteğin oturumu başlatan aynı fiziksel cihazdan geldiğini bilir. Yeni kısa ömürlü bir access_token (başka bir 5 dakika için geçerli) verir.
   • Geçersizse: İstek reddedilir. Oturum sonlandırılır.
6. Devam Etme: Tarayıcı yeni çerezi alır ve duraklatılan orijinal isteği şeffaf bir şekilde yeniden dener. Kullanıcı hiçbir kesinti yaşamaz.

graph LR
    subgraph "Kurbanın Cihazı"
        A[DBSC'li<br/>Kullanıcı Oturumu]
        B[HSM/TPM<br/>Özel Anahtarı]
        C[Çerez +<br/>Oturum Kimliği]
        A --> B
        A --> C
        B -.->|Dışa aktarılamaz| X[Özel Anahtar<br/>Çıkarılamaz]
    end

    subgraph "Saldırı Senaryosu"
        D[RedLine Çalıcı<br/>Cihaza Bulaşır]
        D --> E[Çerez ve Oturum Kimliğini<br/>Çalar]
        E --> F[Saldırgana<br/>Aktarır]
    end

    subgraph "Saldırganın Cihazı"
        G[Çalınan Çerezi<br/>İçe Aktarır]
        H[Oturumu Kullanmaya<br/>Çalışır]
        I[Sunucu DBSC<br/>Yenileme İster]
        J[Sorguyu<br/>İmzalayamaz]
        K[Oturum Reddedildi]

        G --> H
        H --> I
        I --> J
        J --> K
    end

    C -.->|Çalındı| 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

Kullanıcının bilgisayarına RedLine Stealer bulaştıran bir saldırgan düşünün. access_token ve session_id'yi çalarlar. Bunları kendi tarayıcılarına aktarırlar.

• Senaryo A (5 dakika içinde): Saldırgan, kısa ömürlü tokenin süresi dolana kadar birkaç dakika erişim sağlayabilir.
• Senaryo B (Süre dolduktan sonra): Saldırganın tarayıcısı (farklı bir cihazda) tokeni kullanmaya çalışır. Sunucu bunu reddeder ve yenileme talep eder. Saldırganın tarayıcısı DBSC başlıklarını görür, ancak bağlı özel anahtara sahip olmadığı için yenileme işlemini gerçekleştiremez. Saldırı başarısız olur.

Gizlilik, DBSC'nin merkezi bir tasarım hedefidir. W3C spesifikasyonu, kullanıcıları siteler arasında izleyebilecek küresel tanımlayıcıların kullanımını açıkça yasaklamaktadır.

• Köken Başına Anahtarlar: Tarayıcı, her site için benzersiz bir anahtar çifti oluşturur. google.com Anahtar A'yı görür; amazon.com Anahtar B'yi görür. Aralarında hiçbir korelasyon yoktur.
• Kullanıcı Temizleme: Kullanıcı çerezlerini/site verilerini temizlerse, tarayıcı da ilişkili DBSC anahtarlarını siler. Bu, DBSC'nin silinmiş kimlikleri diriltmek için bir "süper çerez" olarak kullanılamamasını sağlar.

DBSC'nin uygulanması, sunucunun genel anahtarlar hakkında durum bilgisini korumasını gerektirir.

• Veritabanı Şeması: Oturum tablosu, public_key ve last_challenge'ı user_id ve session_expiry ile birlikte depolamak üzere güncellenmelidir.
• Performans: Yenileme işlemi kriptografik doğrulama içerir (örneğin, bir ECDSA imzasının doğrulanması). Hızlı olmakla birlikte, basit bir dizeyi kontrol etmekten daha fazla CPU yoğunlukludur. Ancak, yenilemeler her istekte değil, her birkaç dakikada bir gerçekleştiğinden, genel yük önemsizdir.

Teknik spesifikasyonların ötesinde DBSC; iş stratejisi, ürün yol haritaları ve uyumluluk duruşları için önemli etkiler taşır.

Güvenlik girişimleri genellikle maliyet merkezleri veya sürtünme oluşturucular olarak görülür. DBSC bu anlatıyı tersine çevirir. Aşağıdaki diyagram, cihaz bağlamanın nasıl bir dizi ticari fayda yarattığını göstermektedir:

• Dolandırıcılıkta Azalma: Hesap Ele Geçirme (ATO) için birincil vektörü etkisiz hale getirerek, işletmeler dolandırıcılık kayıplarında milyonlar tasarruf edebilir.
• Destek Maliyetleri: Hesap kurtarma pahalıdır. Saldırıyı ilk etapta önlemek bu operasyonel yükü doğrudan azaltır.
• Dönüşüm Optimizasyonu: E-ticarette, her giriş istemi potansiyel bir ayrılma noktasıdır. DBSC, agresif "oturumu açık tut" politikalarına izin vererek, parola istemleri olmadan anında ödeme yapılmasını sağlar.

Avrupa'daki GDPR (Genel Veri Koruma Yönetmeliği) gibi yasal çerçeveler, kuruluşların güvenliği sağlamak için "uygun teknik ve organizasyonel önlemleri" uygulamasını gerektirir.

• Savunulabilir Güvenlik: DBSC bir standart haline geldikçe, oturum yönetimi için "en son teknoloji" olarak yorumlanması muhtemeldir. Bir ihlal durumunda, DBSC'nin uygulandığını kanıtlamak, ihmal iddialarına karşı güçlü bir savunma olabilir.
• Bankacılık Standartları (PSD2): Ödeme Hizmetleri Direktifi 2, "Güçlü Müşteri Kimlik Doğrulaması" (SCA) gerektirir. SCA girişe odaklansa da, oturumun cihaza dinamik olarak bağlanması, direktifin kimlik doğrulamayı belirli miktarlara ve alıcılara bağlama hedefleriyle mükemmel uyum sağlar.

FIDO Alliance teknik incelemeleri, "Güvence Düzeyleri" kavramını vurgulamaktadır.

• Orta Güvence: Senkronize geçiş anahtarlarını (iCloud Anahtar Zinciri'ndekiler gibi) kullanır. Tüketici uygulamaları için harikadır, kurtarılabilir, kullanımı kolaydır.
• Yüksek Güvence: Cihaza bağlı anahtarlar gerektirir. DBSC'nin parladığı yer burasıdır. Kurumsal kaynaklar (İK portalları, kod depoları) veya yüksek değerli bankacılık için kuruluş, yalnızca belirli bir yönetilen cihaza bağlı oturumlardan erişime izin veren bir politika uygulayabilir. DBSC, bu politika için teknik uygulama mekanizması sağlar.

DBSC'yi tam olarak takdir etmek için onu benzer sorunları çözmeye çalışan diğer teknolojilerle karşılaştırmalıyız.

graph RL
    subgraph "Geleneksel Çerezler"
        TC1[Yalnızca Taşıyıcı Token]
        TC2[Hırsızlığa Karşı Savunmasız]
        TC3[Uzun Oturumlar = Risk]
        TC1 --> TC2
        TC2 --> TC3
    end

    subgraph "Token Binding"
        TB1[TLS Katmanı Bağlaması]
        TB2[❌ Başarısız: Karmaşık Altyapı]
        TB3[Yük Dengeleyicilerde Kırıldı]
        TB1 --> TB2
        TB2 --> TB3
    end

    subgraph "DPoP"
        DP1[OAuth Token Bağlaması]
        DP2[✅ API Koruması]
        DP3[Tarayıcı Oturumları İçin Değil]
        DP1 --> DP2
        DP2 --> DP3
    end

    subgraph "DBSC"
        D1[HTTP Katmanı Bağlaması]
        D2[✅ Donanım Anahtarı Koruması]
        D3[✅ CDN'ler/YB'lerle Çalışır]
        D4[✅ Tarayıcı Oturumları]
        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

Belirtildiği gibi Token Binding, oturumu TLS katmanına bağlamaya çalıştı.

• Token Binding: İstemciden, sunucudan ve aradaki her adımdan (Yük Dengeleyiciler, TLS Sonlandırıcılar) destek gerektiriyordu. Bir bağlantı sonlandırılıp yeniden şifrelendiğinde kırılıyordu.
• DBSC: HTTP uygulama katmanında çalışır. Standart başlıklar/çerezler olarak Yük Dengeleyicilerden şeffaf bir şekilde geçer. TLS'nin genellikle bulut sağlayıcısının uç ağı tarafından işlendiği modern bulut mimarilerinde (AWS/GCP/Azure) dağıtımı çok daha kolaydır.

DPoP (RFC 9449), "gönderen kısıtlamalı" OAuth tokenleri için standarttır. Hem erişim (access) tokenlerini hem de yenileme (refresh) tokenlerini ortak bir anahtara bağlar—yenileme tokenleri de uzun ömürlü taşıyıcı kimlik bilgileri olduğu için bu kritiktir. Her API isteği bir DPoP kanıtı içerir: HTTP yöntemi, URL, zaman damgası ve benzersiz tanımlayıcı içeren imzalı bir JWT. FAPI 2.0 gibi yüksek güvenceli spesifikasyonlar, gönderen kısıtlamalı tokenleri zorunlu kılar; mTLS kullanılamadığında önerilen yöntem DPoP'dur.

Temel fark: DPoP anahtarları uygulama bağlamında yaşar. En iyi uygulama, dışa aktarılamayan depolama için OS API'lerini kullanmaktır, ancak bu zorunlu değildir—birçok uygulama anahtarları JavaScript erişimine açık bellekte tutar. Bir saldırgan rastgele kod yürütebilirse (XSS, kötü amaçlı yazılım), DPoP anahtarlarına erişebilir veya isteğe bağlı olarak kanıtlar oluşturabilir. DPoP, tokenin farklı istemciler arasında tekrar oynatılmasını (replay) durdurur, ancak güvenliği ihlal edilmiş bir tarayıcı bağlamını koruyamaz.

DBSC, sahiplik kanıtını tarayıcıya ve donanıma taşır. Özel anahtar, JavaScript'in okuyamayacağı veya dışa aktaramayacağı bir TPM veya güvenli bölgede yaşar. Tarayıcı protokolü işler ve uygulama koduna anahtarları ifşa etmeden imzalar üretir. Web uygulaması tamamen tehlikeye atılsa bile, bir saldırgan başka bir makinedeki çalınmış çerezler için yeni kanıtlar basamaz.

Sinerji: FIDO Alliance'ın belirttiği gibi, geçiş anahtarları girişte oltalama saldırılarını ortadan kaldırırken, DBSC/DPoP kimlik doğrulama sonrası tokenleri korur. Modern bir mimari her ikisini birleştirir: OAuth API'leri için DPoP (özellikle düzenlenmiş açık bankacılık), tarayıcı oturumları için DBSC. Birlikte, tüm oturum yaşam döngüsü boyunca "al ve taşı" saldırı vektörünü kapatırlar.

Çerez ömürlerini kısaltmak (örneğin 15 dakikaya), güvenliği artırır ancak UX'i mahveder. Kullanıcılar sürekli giriş yapmaya zorlanır. DBSC, 30 günlük bir çerezin Kullanıcı Deneyimi ile 5 dakikalık bir çerezin etkili güvenliğine olanak tanır.

%%{init: {
  "theme": "default",
  "themeVariables": {
    "actorBkg": "#ffffff",
    "actorBorder": "#000000",
    "noteBkgColor": "#f1f3f5",
    "noteTextColor": "#000000",
    "activationBkgColor": "#e0e0e0",
    "actorColours": {
      "ST": "#ff6b6b",
      "IdP": "#4c6ef5"
    }
  }
}}%%

sequenceDiagram
    participant ST as Güvenlik Araçları<br/>(CrowdStrike, Defender)
    participant IdP as Kimlik Sağlayıcı<br/>(Okta, Google, Azure)
    participant SP1 as Hizmet Sağlayıcı 1<br/>(Slack)
    participant SP2 as Hizmet Sağlayıcı 2<br/>(Salesforce)
    participant SP3 as Hizmet Sağlayıcı 3<br/>(Bankacılık Uygulaması)
    participant Session as Kullanıcı Oturumu<br/>(DBSC Korumalı)

    Note over ST,Session: Tehdit Algılama Aşaması
    ST->>ST: Kullanıcı cihazında<br/>kötü amaçlı yazılım algılar
    ST->>IdP: RISC Sinyali:<br/>"Cihaz Ele Geçirildi"

    Note over IdP,SP3: Sinyal Yayılma Aşaması
    IdP->>SP1: CAEP Olayı:<br/>"Cihaz Ele Geçirildi"
    IdP->>SP2: CAEP Olayı:<br/>"Cihaz Ele Geçirildi"
    IdP->>SP3: CAEP Olayı:<br/>"Cihaz Ele Geçirildi"

    Note over SP1,Session: Yürütme Aşaması (DBSC ile)
    Session->>SP1: Bir sonraki yenileme denemesi<br/>(dakikalar içinde)
    SP1-->>Session: x İmzayı reddet
    Session->>SP2: Bir sonraki yenileme denemesi
    SP2-->>Session: x İmzayı reddet
    Session->>SP3: Bir sonraki yenileme denemesi
    SP3-->>Session: x İmzayı reddet

    Note over Session: Oturumlar bir sonraki yenileme denemesinde sonlandırılabilir

DBSC'nin potansiyeli, Paylaşılan Sinyaller Çerçevesi (SSF), özellikle Sürekli Erişim Değerlendirme Profili (CAEP) ve Risk Yönetimi (RISC) ile birleştirildiğinde daha da artar. Not: SSF/CAEP gelişmekte olan bir ekosistem yeteneğidir—mimari desen tanımlanmıştır, ancak yaygın çapraz satıcı dağıtımı hala olgunlaşmaktadır.

Eski modelde, bir kullanıcının cihazı ele geçirilirse, Kimlik Sağlayıcının (IdP) Hizmet Sağlayıcıya (SP) oturumu hemen şimdi sonlandırmasını söylemesinin bir yolu yoktu. SP'nin çerezin süresinin dolmasını beklemesi gerekirdi.

Öngörülen DBSC + CAEP akışı:

1. Tetikleyici: Bir uç nokta güvenlik aracı (CrowdStrike veya Microsoft Defender gibi), kullanıcının dizüstü bilgisayarında kötü amaçlı yazılım algılar.
2. Sinyal: Güvenlik aracı, Kimlik Sağlayıcıya (örn. Okta/Google) bir RISC sinyali gönderir.
3. Yayılma: IdP, bağlı uygulamalara bir CAEP olayı gönderir: "Cihaz Ele Geçirildi."
4. Yürütme (DBSC): Tarayıcı kısa ömürlü DBSC çerezini yenilemeye çalıştığında, sunucu imzayı reddeder ve oturumu sonlandırır.
   Bu mimari desen daha hızlı iptale olanak tanır—gerçek gecikme, sitenin yenileme süresine ve hem DBSC hem de SSF'yi uygulayıp uygulamadıklarına bağlıdır.

DBSC'nin benimsenmesi tarayıcı satıcılarına bağlıdır. 2026'daki manzara önemli ölçüde değişti: Chrome, Nisan 2026'da DBSC'yi Origin Trial'dan (Orijin Denemesi) Windows'ta genel kullanıma taşıdı, macOS ise sırada. Diğer tarayıcılar hala değerlendirme aşamasında.

Google, DBSC'nin birincil itici gücü ve onu geniş çapta sunan ilk tarayıcıdır.

• Durum (Nisan 2026): Chrome 146, DBSC'yi Windows'ta genel erişime sundu ve Origin Trial aşamasını sonlandırdı. Secure Enclave'i kullanan macOS desteğinin yaklaşan bir Chrome sürümü için duyuruldu.
• Donanım: Windows TPM'yi kullanır, macOS Secure Enclave'i kullanacak. Google, özel güvenli donanımı olmayan cihazlara DBSC korumasını genişletmek için yazılım tabanlı anahtarları da araştırdığını belirtti.
• Yol Haritası: Google'ın GA duyurusu ayrıca bir sonraki adım yol haritasını yayınladı:
  • Federe kimliği güvence altına alma: çapraz kökenli DBSC bağlamaları, böylece bağlı taraf (RP) oturumu kimlik sağlayıcı (IdP) oturumuyla aynı cihaz anahtarına bağlı kalır ve SSO aracılığıyla kesintisiz bir güven zincirini korur.
  • Gelişmiş kayıt: DBSC oturumlarını, oturum açarken yeni bir anahtar oluşturmak yerine mTLS sertifikaları veya donanım güvenlik anahtarları gibi önceden var olan güvenilir anahtar materyaline bağlama.
  • Daha geniş cihaz desteği: TPM / Secure Enclave olmayan cihazlar için yazılım tabanlı anahtarlar.
• Operasyonel sonuçlar: Kullanıma sunulması sırasında Google, DBSC tarafından korunan oturumlar için "oturum hırsızlığında önemli bir azalma" bildirdi.
• Google Hesapları: Ayrı olarak Google, kurumsal politika aracılığıyla kontrol edilen Windows için Chrome'daki Google hesabı çerezleri için DBSC tarzı korumayı zaten kullanıma sunmuştu. Bu, Gmail/Workspace'i korur ve artık genel web için GA olan aynı teknoloji ailesidir.

Microsoft aktif olarak katılıyor.

• Durum: Edge, Ekim 2025'te sona eren Windows'ta bir DBSC Origin Trial çalıştırdı. Yedek deneme veya GA duyurulmadı.
• Kurumsal Bağlam: Edge, kavramsal olarak DBSC'ye benzeyen Entra/Azure AD SSO için "Birincil Yenileme Belirteci" (PRT) mimarisini kullanır. PRT, Microsoft'a özgü bir mekanizma olmaya devam ediyor; üçüncü taraf siteler için DBSC web standardıyla birleştirmeye yönelik açıklanmış bir plan yok.

Apple'ın duruşu mobil kapsama alanı için kritik.

• Durum: WebKit'te, kullanılabilirlik/gizlilik endişeleri belirtilerek DBSC'yi değerlendiren bir standart konum sorunu (standards-position issue) var. Safari sürüm notları DBSC'den bahsetmiyor. Halka açık bir "aktif olarak uygulanıyor" açıklaması mevcut değil.
• Önce Gizlilik: Apple'ın temel endişesi, DBSC'nin "süper çerezler" (silinemeyen izleme) için kullanılabilmesidir. W3C spesifikasyonu, anahtarların web sitesi verileriyle birlikte temizlenmesini sağlayarak bunu ele alır.
• Katılım: WebKit standart sürece katılıyor, ancak uygulama durumu belirsiz—"geliştirme aşamasında" olmaktan çok "tartışma aşamasında".

Mozilla'nın, karmaşıklık ve gizlilikle ilgili belirtilen endişelerle DBSC'yi değerlendiren bir standart konum sorunu var. Standart istikrara kavuştuktan sonra uygulamak için kamuya açık bir taahhüt yoktur.

DBSC ve geçiş anahtarları için mevcut ekosistem desteği göz önüne alındığında, kuruluşlar bu tamamlayıcı teknolojileri uygulamak için aşamalı bir yaklaşım benimsemelidir. Aşağıdaki yol haritası, acil eylemleri ve stratejik planlama kilometre taşlarını ana hatlarıyla belirtmektedir:

1. Önce Geçiş Anahtarlarını Dağıtın: Kimlik doğrulama katmanını güvence altına almak için geçiş anahtarı uygulamasıyla başlayın. Bu, kimlik bilgisi avına karşı anında koruma sağlar ve DBSC'den gerçek değer elde etmenin önkoşuludur.

2. DBSC Kayıt ve Yenileme Uç Noktalarını Gönderin: Chrome 146 GA ile gerçekçi çalışma artık arka uç entegrasyonudur: giriş yanıtlarına Secure-Session-Registration başlıkları ekleyin ve /dbsc/register'ı, imzalı sorguları doğrulayan bir yenileme uç noktasıyla birlikte uygulayın. Ön uç kodunun değişmesi gerekmez.

3. Yenileme Tokenleri ile Kısa Ömürlü Oturumları Uygulayın: Henüz DBSC'ye hazır değilseniz, yenileme mekanizmaları ile kısa ömürlü tokenlerin mimari desenini benimseyin. Bu, bugün güvenliği artırırken arka ucunuzu DBSC'ye hazırlar.

1. Hibrit Bir Yaklaşım Benimseyin: Geri dönüş seçeneklerini (fallback) korurken yetenekli tarayıcılara (şu anda Windows'ta Chrome 146+, sırada macOS Secure Enclave) DBSC sunmak için özellik algılamayı kullanın. Bu, Safari, Firefox veya Edge'deki kullanıcıları dışlamadan güvenliği en üst düzeye çıkarır.

2. Sonraki Yol Haritası Öğelerine Hazırlanın: Google, daha geniş cihaz kapsamı için federe kimlik (çapraz kökenli SSO bağlamaları), gelişmiş kayıt (mTLS / donanım anahtarları) ve yazılım tabanlı anahtarları açıkça belirtti. Bir SSO veya IdP katmanı çalıştırıyorsanız, şimdiden çapraz kökenli bağlamayı (cross-origin binding) kapsamaya başlayın.

3. Kimlik Sağlayıcılarla Entegre Olun: Okta, Auth0 veya benzer IdP'leri kullanıyorsanız, SDK'larında DBSC desteğini etkinleştirmek için onlarla birlikte çalışın. Birçoğu Origin Trial'lara (Orijin Denemelerine) katıldı ve Chrome GA olduğuna göre DBSC özelliklerini aktif olarak kullanıma sunuyor.

• Yüksek Değerli Hedeflerle Başlayın: Yönetici panelleri, finansal işlemler ve hassas veri erişimi için DBSC'ye öncelik verin.
• Yönetilen Çözümleri Kullanın: DBSC uygulamasının ve tarayıcı uyumluluğunun karmaşıklığını ele alan Corbado gibi platformları düşünün.
• Ölçün ve Tekrarlayın: ROI'yi göstermek için oturum ele geçirme girişimleri, destek biletleri ve kullanıcı sürtünmesi gibi metrikleri izleyin.
• Uyumluluğa Hazırlanın: Hassas verilerin işlenmesinde muhtemelen bir uyumluluk gereksinimi haline geleceği için DBSC uygulamanızı belgeleyin.

DBSC'yi sıfırdan uygulamak büyük bir mühendislik yüküdür. Kriptografik uzmanlık, tarayıcı tutarsızlıkları hakkında derin bilgi ve anahtarları ve sorguları yönetmek için sağlam bir sunucu tarafı altyapısı gerektirir. İşte bu noktada Corbado bir etkinleştirici olarak hizmet eder.

Düşük güvenceli bir girişin üzerine yüksek güvenceli bir oturum kuramazsınız. Bir kullanıcı zayıf bir parolayla giriş yaparsa, oturum yalnızca o parola kadar güvenli olur. Corbado'nun temel ürünü (yönetilen geçiş anahtarları) gerekli temeli sağlar. Kuruluşlar, Corbado'yu entegre ederek geçiş anahtarlarını kolayca dağıtabilir ve oturumun başlangıcının oltalama saldırılarına karşı dirençli olmasını sağlar.

Corbado, güvenilir cihaz tespitini geliştirmek için DBSC'den yararlanacaktır. DBSC sinyalleri mevcut olduğunda, bir oturumun belirli bir cihazdan kaynaklandığına dair kriptografik kanıt sağlarlar ve bu da Corbado'nun kimlik doğrulama güven düzeylerini buna göre artırmasına olanak tanır.

• Senkronize Geçiş Anahtarı Belirsizliğini Çözmek: Senkronize geçiş anahtarları (synced passkeys) kullanışlıdır ancak bir güven boşluğu yaratır: bir kullanıcı senkronize edilmiş bir geçiş anahtarıyla kimlik doğruladığında, bunun onun her zamanki dizüstü bilgisayarı mı yoksa kimlik bilgisini yeni senkronize eden yepyeni bir cihaz mı olduğunu anlayamazsınız. DBSC bu boşluğu kapatır. Corbado, cihazın kurulu bir DBSC bağına sahip olup olmadığını kontrol ederek, cihazın sadece ilk senkronizasyon değil, gerçekten bilinen ve güvenilen bir cihaz olduğunu doğrulayabilir.
• Bilinen Cihazlar İçin Daha Yüksek Güven: DBSC sinyalleri bir cihazın daha önce görüldüğünü onayladığında, Corbado daha emin risk kararları verebilir: meşru dönen kullanıcılar için daha az ek kimlik doğrulama (step-up authentication) istemi, tanınmayan cihazlardan gelen oturumlar için daha sıkı inceleme.
• Geçiş Anahtarı Zekasını Tamamlama: DBSC sinyalleri, Corbado'nun mevcut Passkey Intelligence motoruyla entegre olur. Geçiş anahtarı tabanlı kimlik doğrulama ve DBSC tabanlı cihaz bağlamanın birleşimi, girişten tüm oturum yaşam döngüsüne kadar eksiksiz bir güven zinciri oluşturur.

Corbado'nun DBSC'yi platformuna nasıl entegre etmeyi planladığına dair sorularınız için ekibe ulaşın.

Önümüzdeki birkaç yıl boyunca web hibrit (karma) olacak. Bazı kullanıcılar DBSC yetenekli tarayıcılara (Windows 11'de Chrome) sahip olacak; diğerleri ise eski sistemlerde olacak. Bu parçalanmayı idare etmek zordur. Corbado'nun Passkey Intelligence motoru, yetenekli cihazlara geçiş anahtarları ve diğerlerine geri dönüşler (fallbacks) sunarak tam olarak bu tür geri dönüş mantığını işlemek üzere tasarlanmıştır. Aynı zeka, oturum bağlamaya da uygulanır ve güvenliğin her kullanıcı için cihazlarının yeteneklerine göre en üst düzeye çıkarılmasını sağlar.

"Taşıyıcı Token" dönemi sona eriyor. Mevcut oturum yönetimi feci şekilde başarısız oluyor — taşıyıcı tokenler, endüstriyel ölçekteki kötü amaçlı yazılım operasyonları tarafından çalınabilir ve en güçlü kimlik doğrulama yöntemlerini bile atlayan hesap ele geçirmelerine olanak tanıyarak herhangi bir cihazdan kullanılabilir. Bu temel güvenlik açığı, milyarlarca dolar değerinde bir yeraltı ekonomisi yarattı.

Cihazlara Bağlı Oturum Kimlik Bilgileri (DBSC), sektörün gelişmekte olan yanıtını temsil ediyor. HttpOnly bayrakları ve statik sırlarıyla geleneksel güvenli çerezlerin aksine DBSC, cihaza bağlı anahtarlar aracılığıyla kriptografik sahiplik kanıtı ekler. Bu, çalınan çerezleri çok daha az değerli hale getirir. Başka bir cihazdan yenilenemezler. Token Binding, tüm altyapıda karmaşık TLS katmanı değişiklikleri gerektirerek başarısız olduğu yerde, DBSC mevcut yük dengeleyiciler ve CDN mimarileriyle uyumlu olarak HTTP uygulama katmanında çalışarak başarılı olur. Not: DBSC'nin tarayıcının bağlamayı atladığı (TPM kullanılamıyor, ağ hataları) belgelenmiş geri dönüş (fallback) yolları vardır, bu nedenle çerez hırsızlığı riskini ortadan kaldırmaz ancak büyük ölçüde azaltır.

DBSC ve Geçiş Anahtarları (Passkeys) arasındaki sinerji, kullanıcı yolculuğu boyunca saldırganlar için çıtayı önemli ölçüde yükseltir. Geçiş anahtarları, girişte kimlik bilgisi oltalama saldırılarını ortadan kaldırırken, DBSC, uzaktan çerez hırsızlığı yoluyla oturum ele geçirmeyi çok daha zorlaştırır - ikisi birlikte, FIDO Alliance'ın öngördüğü "yüksek güvenceli" kimlik çerçevesini oluşturur. Chrome 146'nın Nisan 2026'da Windows'ta GA olarak DBSC sunmasıyla ve macOS Secure Enclave desteğinin de sırada olmasıyla, standart hazırlık aşamasından çıkıp sunum aşamasına geçmiştir. Google'ın yayınlanan yol haritası (federe kimlik, mTLS / donanım anahtarı kaydı, yazılım tabanlı anahtarlar) önümüzdeki 12 aylık genişlemenin sinyalini veriyor.

Ürün Yöneticileri için iş senaryosu (business case) ilgi çekicidir: DBSC, dolandırıcılık kayıplarını ve destek maliyetlerini aynı anda azaltırken, giriş sürtünmesini önemli ölçüde azaltan "sınırsız" güvenli oturumlara olanak tanır. ROI, daha yüksek dönüşüm oranları, daha az parola sıfırlama bileti ve ortadan kalkan hesap ele geçirme olayları olarak kendini gösterir. OAuth kullanan kuruluşlar, API tokenleri için DPoP aracılığıyla aynı anahtar bağlama konseptinden yararlanabilirken, Paylaşılan Sinyaller (CAEP/RISC) ile entegrasyon, gerçek zamanlı tehdit yanıtını mümkün kılar — tehlikeye atılmış oturumları bir sonraki yenileme girişiminde anında iptal eder.

Uygulamanın sıfırdan oluşturulması gerekmez. Corbado gibi platformlar geçiş anahtarı altyapısı sağlar ve tarayıcı desteği olgunlaştıkça cihaz bağlamayı entegre etmek için DBSC gelişmelerini takip etmektedir. W3C spesifikasyonu aktif bir Çalışma Taslağıdır (Working Draft), Chrome 146 Windows'ta GA'dır ve macOS'a sunulmaktadır ve diğer tarayıcılar hala standardı değerlendirmektedir.

Gidişat nettir: Bugün Geçiş Anahtarlarını ve DBSC'yi benimsemeye başlayan kuruluşlar, parolasız, oltalamaya dirençli gelecek için en iyi şekilde konumlanacaktır. Soru, cihaza bağlı oturumların uygulanıp uygulanmayacağı değil, kullanıcılarınızı ve işinizi korumak için bunları ne kadar hızlı dağıtabileceğinizdir. Web güvenliğinin geleceği yalnızca kimliği doğrulanmış (authenticated) değil; güvendiğimiz cihazlara kriptografik olarak bağlıdır.

Corbado Hakkında

Corbado, büyük ölçekte tüketici kimlik doğrulaması yöneten CIAM ekipleri için Passkey Intelligence Platform'tur. IDP loglarının ve genel analytics araçlarının göremediğini görmenizi sağlarız: hangi cihazların, OS sürümlerinin, tarayıcıların ve credential manager'ların passkey desteklediğini; kayıtların neden girişe dönüşmediğini; WebAuthn akışının nerede başarısız olduğunu; bir OS ya da tarayıcı güncellemesinin girişi sessizce ne zaman bozduğunu — hem de Okta, Auth0, Ping, Cognito veya kendi IDP'nizi değiştirmeden. İki ürün: Corbado Observe, passkey'ler ve diğer tüm giriş yöntemleri için observability sağlar. Corbado Connect, analytics entegre managed passkey'ler sunar (IDP'nizin yanında). VicRoads, Corbado ile 5M+ kullanıcı için passkey çalıştırıyor (%80+ passkey aktivasyonu). Bir Passkey uzmanıyla görüşün →

CrowdStrike gibi uç nokta güvenlik araçları kötü amaçlı yazılım algıladığında, Kimlik Sağlayıcıya bir RISC sinyali gönderir, bu da bağlı uygulamalara bir CAEP 'Cihaz Ele Geçirildi' olayı gönderir. Bir sonraki DBSC yenileme girişiminde (dakikalar içinde), bu uygulamalar oturum imzasını reddeder ve erişimi sonlandırır. Çapraz satıcı CAEP/RISC dağıtımı hala olgunlaşmaktadır.

DPoP (RFC 9449), öncelikle yerel uygulamalarda ve SPA'larda API çağrılarını koruyarak OAuth erişim ve yenileme tokenlerini uygulama katmanında genel bir anahtara bağlar. DBSC, tarayıcı oturum çerezlerini JavaScript'in okuyamayacağı veya dışa aktaramayacağı donanım destekli TPM anahtarlarına bağlar ve web uygulamasının kendisi XSS veya kötü amaçlı yazılım tarafından tehlikeye atılmış olsa bile kullanıcıya dönük oturumları korur.

Geleneksel güvenli tasarım, bir çerez çalınıp uzaktan yeniden oynatıldığında (replayed) hasarı sınırlamak için kısa oturum zaman aşımlarını zorunlu kılar. DBSC, yenileme yeteneğini kaynağı olan cihazın özel anahtarına bağlar, böylece farklı bir cihazdan kullanılan çalınmış bir çerez kriptografik sorguda başarısız olur. Uzaktan yeniden oynatma saldırıları etkisiz hale getirildiği için oturumlar etkili bir şekilde süresiz olabilir.

DBSC, birincil Hesap Ele Geçirme vektörü olarak çerez hırsızlığını etkisiz hale getirir ve doğrudan dolandırıcılık kayıplarını ve hesap kurtarma destek maliyetlerini azaltır. Güvenli uzun oturumlar, tekrarlanan giriş istemlerini ortadan kaldırarak e-ticarette dönüşüm oranlarını iyileştirir ve müşteri kaybını (drop-off) azaltır. FIDO Alliance, DBSC'yi kullanıcı sürtünmesini aynı anda azaltırken güvenlik çıtasını yükselten bir teknoloji olarak konumlandırır.