Passkey dan WebAuthn: log masuk tanpa kata laluan, tanpa sihir

Kata laluan ialah salah satu perkara yang telah kami biasakan hanya kerana kami telah tinggal bersama mereka selama bertahun-tahun. Pengguna melupakannya, menggunakannya semula, menulisnya di tempat yang tidak sepatutnya. Pasukan mesti mengurus tetapan semula, dasar, cincang, kebocoran, pancingan data dan sokongan.

passkey tidak menjadikan pengesahan sempurna, tetapi ia menghapuskan masalah besar: pelayan tidak perlu lagi menyimpan rahsia yang dikongsi dengan pengguna.

Apa sebenarnya yang berlaku

A passkey ialah kelayakan berdasarkan WebAuthn. Apabila pengguna menciptanya, peranti menjana pasangan kunci:

• kunci peribadi, yang kekal pada peranti atau dalam pengurus kata laluan;
• kunci awam, yang boleh disimpan oleh pelayan.

Apabila log masuk pelayan tidak bertanya "beritahu saya kata laluan". Hantar cabaran rawak. Peranti menandatanganinya dengan kunci peribadi. Pelayan mengesahkan tandatangan dengan kunci awam.

Itulah bahagian yang bagus: jika pangkalan data dicuri, tiada kata laluan di dalamnya untuk dipecahkan. Dan jika pengguna berakhir pada domain palsu, passkey tidak sah untuk domain tersebut. Ia bukan sekadar kemudahan, ia adalah perlindungan konkrit terhadap pancingan data.

Pelayar bertindak sebagai jambatan

Dalam pelayar, dua API utama ialah:

• navigator.credentials.create() untuk mencipta passkey;
• navigator.credentials.get() untuk menggunakannya semasa log masuk.

Tetapi logik penting adalah pada pelayan. Pelayan mesti menjana cabaran, menyimpannya buat sementara waktu, mengesahkan respons, menyemak sumber dan Relying Party ID, kemudian mencipta sesi.

Bahagian pelanggan sepatutnya hampir membosankan:

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()),
});

Jika anda mendapati diri anda melaksanakan penyulitan WebAuthn dengan tangan, hentikan. Gunakan perpustakaan sisi pelayan yang mantap. Ralat di sini bukan "pepijat comel", ia adalah lubang pengesahan.

Perkara yang perlu disimpan dalam pangkalan data

Tidak perlu menyelamatkan separuh dunia. Biasanya cukup:

• ID kelayakan;
• kunci awam;
• pengguna yang bersambung;
• mana-mana kaunter pengesahan atau metadata;
• mengangkut, jika berguna untuk UX;
• nama yang dipilih oleh pengguna;
• tarikh penciptaan dan penggunaan terakhir.

Jadual minimum mungkin kelihatan seperti ini:

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
);

Kemudian saya akan menambah log audit dan pemberitahuan: jika seseorang mencipta passkey baharu pada akaun saya, saya ingin tahu mengenainya.

UX lebih penting daripada demo

Demo passkey sentiasa cantik: anda klik, Face ID, anda masuk. Produk sebenar lebih rumit.

Seseorang menukar telefon mereka. Seseorang menggunakan komputer syarikat yang berkunci. Sesetengah orang tidak faham mengapa penyemak imbas mencadangkan passkey. Seseorang kehilangan akses kepada peranti mereka.

Itulah sebabnya saya tidak akan bermula dengan "mulai hari ini tiada lagi kata laluan untuk semua orang". Saya akan mulakan seperti ini:

1. passkey pilihan untuk pengguna dalaman;
2. cadangan untuk mencipta satu selepas log masuk berjaya;
3. halaman akaun untuk menamakan semula dan mengalih keluar passkey;
4. sandaran yang jelas;
5. pelancaran beransur-ansur dalam log masuk utama.

Teks dalam antara muka hendaklah ringkas. "Gunakan skrin kunci peranti anda" adalah lebih baik daripada "sahkan dengan kelayakan FIDO2 pemastautin."

Kesilapan yang saya akan elakkan

Jangan menjana cabaran kepada pelanggan. Cabaran dibuat pada pelayan dan mesti disahkan sekali sahaja.

Jangan hanya mempercayai ID kelayakan. Anda perlu mengesahkan tandatangan, cabaran, asal dan Relying Party ID.

Jangan padamkan sandaran sebelum anda mempunyai aliran pemulihan yang baik. Tanpa kata laluan tidak perlu menjadi "jika anda kehilangan telefon anda, anda akan keluar selama-lamanya".

Jangan anggap passkey sebagai butang bahagian hadapan semata-mata. Menyembunyikan butang bukan keselamatan: pengesahan sebenar adalah bahagian pelayan.

Passkey-pertama atau passkey-mesra?

Untuk produk baru anda boleh fikir passkey-dahulu. Untuk apl sedia ada, saya lebih suka passkey-mesra: tambah passkey sebagai kaedah yang disyorkan, ukur kejayaan dan masalah, kemudian kurangkan berat kata laluan dengan tenang.

Penghijrahan yang ideal tidak dirasai. Pengguna mendapati bahawa log masuk lebih mudah, bukannya syarikat itu telah menukar protokol pengesahannya.

Kesimpulan

passkey menarik kerana ia meningkatkan keselamatan dan UX pada masa yang sama, yang jarang berlaku. Mereka bukan tongkat ajaib: pemulihan, keserasian, sokongan dan pelancaran kekal direka bentuk dengan baik.

Tetapi perubahan asas adalah kuat. Berhenti meminta pengguna mencipta dan melindungi rahsia. Anda membenarkan peranti menandatangani bukti kriptografi yang terikat pada domain anda. Kurang ingatan manusia, kurang pancingan data, kurang penetapan semula kata laluan. Saya akan katakan mereka patut diambil serius.

Sumber

• MDN: Passkeys
• MDN: Web Authentication API
• W3C: Web Authentication
• passkeys.dev