Yıllardır onlarla yaşadığımız için normalleştirdiğimiz şeylerden biri de şifreler. Kullanıcılar bunları unutuyor, yeniden kullanıyor, yazmamaları gereken yerlere yazıyor. Ekipler sıfırlamaları, politikaları, karmaları, sızıntıları, kimlik avını ve desteği yönetmelidir.
passkey kimlik doğrulamayı mükemmel yapmaz ancak büyük bir sorunu ortadan kaldırır: Sunucunun artık kullanıcıyla paylaşılan bir sırrı saklaması gerekmez.
Gerçekten ne oluyor
passkey, WebAuthn'ye dayalı bir kimlik bilgisidir. Kullanıcı bunu oluşturduğunda cihaz bir anahtar çifti oluşturur:
- cihazda veya şifre yöneticisinde kalan özel bir anahtar;
- sunucunun kaydedebileceği ortak anahtar.
Sunucuya giriş yaparken "bana şifreyi söyle" sormuyor. Rastgele bir meydan okuma gönderin. Cihaz bunu özel anahtarla imzalar. Sunucu imzayı ortak anahtarla doğrular.
İşin güzel tarafı da bu: Eğer veritabanı çalınırsa içeride kırılacak şifreler olmaz. Ve eğer bir kullanıcı sahte bir alan adı alırsa, passkey bu alan adı için geçerli değildir. Bu sadece kolaylık değil, aynı zamanda kimlik avına karşı somut bir korumadır.
Tarayıcı köprü görevi görür
Tarayıcıda iki ana API şunlardır:
navigator.credentials.create()passkey oluşturmak için;navigator.credentials.get()oturum açma sırasında kullanmak için.
Ama önemli olan mantık sunucudadır. Sunucunun sorgulamayı oluşturması, geçici olarak kaydetmesi, yanıtı doğrulaması, kaynağı kontrol etmesi ve Relying Party ID, ardından oturumu oluşturması gerekir.
Müşteri kısmı neredeyse sıkıcı olmalı:
const options = await fetch('/api/passkeys/login/options').then((r) => r.json()); const credential = await navigator.credentials.get({ publicKey: PublicKeyCredential.parseRequestOptionsFromJSON(options), }); await fetch('/api/passkeys/login/verify', { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify(credential?.toJSON()), });
Kendinizi WebAuthn şifrelemeyi elle uygularken bulursanız durun. Sağlam bir sunucu tarafı kitaplığı kullanın. Buradaki hatalar "sevimli böcekler" değil, kimlik doğrulama delikleridir.
Veritabanına ne kaydedilmeli
Dünyanın yarısını kurtarmaya gerek yok. Genellikle yeterli:
- Kimlik bilgilerinin kimliği;
- genel anahtar;
- bağlı kullanıcı;
- herhangi bir doğrulama sayacı veya meta verisi;
- UX için yararlıysa aktarımlar;
- kullanıcı tarafından seçilen ad;
- oluşturulma tarihi ve son kullanım.
Minimal bir tablo şöyle görünebilir:
create table passkey_credentials ( id uuid primary key default gen_random_uuid(), user_id uuid not null references users(id), credential_id text not null unique, public_key text not null, name text, created_at timestamptz not null default now(), last_used_at timestamptz );
Daha sonra denetim günlükleri ve bildirimler eklerdim: Birisi hesabımda yeni bir passkey oluşturursa bunu bilmek isterim.
UX demodan daha önemlidir
passkey'nin demosu her zaman güzeldir: tıklarsınız, Face ID, içeri girersiniz. Gerçek ürün daha karmaşıktır.
Birisi telefonunu değiştiriyor. Birisi kilitli bir şirket bilgisayarını kullanıyor. Bazı insanlar tarayıcının neden passkey önerdiğini anlamıyor. Birisi cihazına erişimini kaybeder.
Bu yüzden "bugünden itibaren herkese şifre yok" diyerek başlamayacağım. Şöyle başlardım:
- passkey dahili kullanıcılar için isteğe bağlıdır;
- Başarılı bir giriş yaptıktan sonra bir tane oluşturma önerisi;
- yeniden adlandırmak ve kaldırmak için hesap sayfası passkey;
- geri dönüşü temizleyin;
- Ana girişte kademeli olarak kullanıma sunma.
Arayüzdeki metin basit olmalıdır. "Cihazınızın kilit ekranını kullanın", "yerleşik FIDO2 kimlik bilgileriyle kimlik doğrulaması yapmak"tan daha iyidir.
Kaçınacağım hatalar
Müşteri üzerinde zorluklar yaratmayın. Mücadele sunucuda oluşturulur ve yalnızca bir kez doğrulanması gerekir.
Yalnızca kimlik bilgilerine güvenmeyin. İmzayı, sorgulamayı, kaynağı ve Relying Party ID doğrulamanız gerekir.
İyi bir kurtarma akışına sahip olmadan geri dönüşleri silmeyin. Parolasız, "telefonunuzu kaybederseniz sonsuza kadar dışarıda kalırsınız" şeklinde olmak zorunda değildir.
passkey'yi yalnızca ön uç düğmesi olarak görmeyin. Bir düğmeyi gizlemek güvenlik değildir: gerçek doğrulama sunucu tarafındadır.
Passkey-ilk mi yoksa passkey-dostu mu?
Yeni bir ürün için önce passkey düşünebilirsiniz. Mevcut bir uygulama için passkey-dostu tercih ediyorum: Önerilen yöntem olarak passkey'yi ekleyin, başarıyı ve sorunları ölçün, ardından şifre ağırlığını sakin bir şekilde azaltın.
İdeal göç hissedilmez. Kullanıcı, şirketin kimlik doğrulama protokolünü değiştirdiğini değil, oturum açmanın daha kolay olduğunu keşfeder.
Sonuç
passkey ilginçtir çünkü güvenliği ve kullanıcı deneyimini aynı anda geliştirirler ki bu da nadirdir. Bunlar sihirli bir değnek değil: kurtarma, uyumluluk, destek ve kullanıma sunmanın iyi tasarlanması gerekiyor.
Ancak temel değişiklik güçlüdür. Kullanıcılardan sırları icat etmelerini ve korumalarını istemeyi bırakın. Cihazın alan adınıza bağlı bir kriptografik kanıt imzalamasına izin verirsiniz. Daha az insan hafızası, daha az kimlik avı, daha az şifre sıfırlama. Ciddiye alınmaya değer olduklarını söyleyebilirim.