WebAuthn dalam kehidupan nyata

Pada bulan September 2019, tim Mail.ru mendukung teknologi WebAuthn. Kami menjadi layanan email pertama di dunia yang menerapkan kemampuan untuk masuk ke akun Anda menggunakan kunci elektronik alih-alih kata sandi. Sekarang kesempatan ini tersedia untuk semua pengguna kami, Anda dapat mengikat kunci elektronik ke akun Anda di pengaturan dan setelah itu bebas menggunakannya untuk masuk.



Kami sudah menulis berita tentang acara ini di sini, di HabrΓ©. Dalam artikel ini saya ingin berbicara lebih banyak tentang alasan penerapan WebAuthn di layanan kami dan tentang aspek teknis dari bekerja dengan teknologi ini.

Apa itu WebAuthn dan mengapa itu diperlukan


Di dunia modern, sebagian besar layanan Internet menggunakan kata sandi untuk mengotentikasi pengguna. Keuntungan kata sandi adalah kesederhanaannya: untuk mengakses sumber yang diperlukan Anda hanya perlu mengetahui kata sandi dan memasukkannya dengan benar.

Namun, kelemahan kata sandi sering kali lebih besar daripada keuntungannya:

  • jika kata sandinya sederhana - Anda dapat mengambilnya;
  • jika kata sandi yang sama digunakan di beberapa layanan, maka melanggar salah satunya penyerang mendapatkan akses ke yang lain;
  • kata sandi rentan terhadap serangan phishing;
  • kata sandi yang kuat dan unik sulit untuk diingat, sehingga pengguna dipaksa untuk menuliskan kata sandi pada stiker dan menempelkannya pada monitor, dari tempat itu dapat dengan mudah dilihat, dicuri atau hilang.

Untuk menghilangkan kekurangan kata sandi dan membuat proses otentikasi lebih aman, berbagai cara untuk mengganti kata sandi muncul - ini adalah penggunaan kode satu kali yang dikirimkan kepada pengguna melalui SMS atau melalui pemberitahuan PUSH, atau penggunaan aplikasi generator kode-TOTP khusus yang dengannya pengguna dapat login akun tanpa memasukkan kata sandi Anda.

Perusahaan seperti Microsoft , Yahoo , Amazon berpikir tentang menggunakan metode otentikasi tanpa kata sandi dan sepenuhnya meninggalkan penggunaan kata sandi dalam layanan mereka. Mail.ru tidak terkecuali, kami telah lama mendukung proses masuk menggunakan kode satu kali, yang memungkinkan pengguna untuk tidak mengingat kata sandi yang rumit dan kuat dan dengan cepat mendapatkan akses ke akun mereka.

Alternatif lain untuk kata sandi adalah otentikasi menggunakan kunci elektronik (kunci keamanan, nama lain - autentikator elektronik). Prinsip operasinya didasarkan pada penggunaan kriptografi asimetris dan dijelaskan dalam keluarga protokol FIDO2, yang dikembangkan oleh aliansi FIDO (Fast IDentity Online).

Pada Maret 2019, W3C merilis versi standar pertama., yang menjelaskan JS API berbasis browser yang memungkinkan Anda berinteraksi dengan kunci elektronik. Standar menerima status rekomendasi dan nama Otentikasi Web: API untuk akses ke kredensial menggunakan kunci publik: level satu (Otentikasi Web: API untuk mengakses Kredensial Kunci Publik Level 1) - singkatnya, WebAuthn.

Bagaimana WebAuthn Bekerja


Aktor utama berikut dalam proses otentikasi menggunakan WebAuthn diidentifikasi:

  • Klien (Klien WebAuthn) - browser yang mendukung API WebAuthn;
  • Aplikasi web - aplikasi yang berjalan di klien menggunakan WebAuthn API untuk berinteraksi dengan kredensial;
  • kredensial (Kredensial Kunci Publik) - sepasang kunci kriptografi publik dan pribadi yang dikaitkan dengan akun pengguna;
  • Authenticator - perangkat atau program - membuat kredensial pengguna dan menandatangani permintaan dari pihak yang mengandalkan kredensial ini (nama lain adalah kunci elektronik);
  • pihak yang mengandalkan (WebAuthn Relying Party) - server web - menyimpan kunci publik yang terkait dengan akun pengguna, memverifikasi validitas penandatanganan permintaan mereka dengan kunci pribadi yang disimpan dalam autentikator.

API WebAuthn memungkinkan Anda melakukan hanya dua operasi. Ini memungkinkan Anda untuk membuat kredensial baru dan menandatangani permintaan dari server dengan kredensial yang sudah dibuat.

Pembuatan kredensial ( MakeCredential )



Skema panggung dengan penciptaan kredensial, diambil dari w3.org .

Pada tahap ini, kunci elektronik terdaftar di akun pengguna. Di dalam autentikator, sepasang kunci publik dan pribadi baru dihasilkan, dan kunci publik dikirim dan disimpan dalam akun pengguna di server.

const credential = await navigator.credentials.create({
    publicKey: publicKeyMakeCredentialOptions
});

Menandatangani permintaan dengan kredensial yang telah dibuat ( GetAssertion )



Skema panggung dengan verifikasi kredensial, diambil dari w3.org .

Pada langkah ini, diperiksa apakah pengguna memiliki autentikator yang kunci publiknya disimpan dalam akun pengguna. Token acak ditandatangani dengan kunci pribadi di dalam autentikator dan dikirim ke server, di mana server memeriksa tanda tangan sudah benar. Dengan demikian, jika tanda tangan sudah benar, maka kami menyimpulkan bahwa pengguna benar-benar memiliki autentikator ini.

const assertion = await navigator.credentials.get({
    publicKey: publicKeyGetAssertionOptions
});

Anda dapat melihat demonstrasi proses memasukkan Mail.ru Mail menggunakan WebAuthn dalam video ini .

Anda dapat mempelajari lebih lanjut tentang WebAuthn API itu sendiri dalam spesifikasi WebAuthn dan, misalnya, dalam artikel Medium ini .

Jadi, pekerjaan WebAuthn didasarkan pada penggunaan kunci elektronik. Apa itu?

Kunci elektronik


Kunci elektronik (Saya kadang-kadang akan menyebutnya juga "Kunci WebAuthn", kunci Keamanan Keamanan) adalah perangkat atau program yang menerapkan protokol interaksi FIDO2.

Dalam spesifikasi WebAuthn dan di tingkat rumah tangga, semua kunci elektronik diklasifikasikan dalam satu dari dua kategori:

  • kunci platform-independen (autentikator roaming);
  • Otentikator Platform

Kunci yang bebas platform adalah perangkat fisik eksternal, seperti Yubikey dari Yubico atau Titan Security Key dari Google. Biasanya, autentikator tersebut terhubung ke komputer atau ponsel cerdas pengguna melalui USB, NFC atau BLE. Komunikasi dengan perangkat tersebut berlangsung menggunakan protokol CTAP khusus (Client to Authenticator Protocol).

Untuk mulai bekerja dengan kunci elektronik fisik, pengguna perlu mengikatnya sekali ke akunnya. Setelah itu, pengguna mendapat kesempatan untuk menggunakan kunci elektronik ini untuk masuk pada perangkat lain dan di browser apa pun.


Contoh berbagai kunci platform- independen , diambil dari theverge.com .

Jika mekanisme pengoperasian jenis kunci pertama lebih atau kurang jelas, maka saya ingin membahas lebih detail pada kategori kedua.

Dalam kasus kedua, kunci kriptografi publik dan pribadi dibuat dan disimpan tidak di dalam perangkat fisik eksternal, tetapi dengan beberapa modul perangkat lunak di dalam komputer atau smartphone. Modul perangkat lunak ini dapat diimplementasikan pada level aplikasi tertentu, atau pada level sistem operasi. Misalnya, dalam chip yang aman di dalam komputer, yang OS Anda hanya akan memberikan akses jika Anda masuk dan telah membuktikan bahwa Anda benar-benar Anda.

Pada sebagian besar implementasi modern di browser yang berbeda, OS mengharuskan pengguna untuk mengkonfirmasi diri mereka dengan sidik jari atau dengan memasukkan kata sandi untuk akun pengguna. Penting untuk mengklarifikasi bahwa meskipun pengguna perlu meletakkan jarinya pada pemindai sidik jari untuk menggunakan kunci tersebut, sidik jari itu sendiri tidak disimpan di mana pun dan tidak dikirim ke mana pun. Ini hanya cara di mana sistem operasi atau browser memvalidasi pengguna.


Penggunaan autentikator khusus platform.

Hanya informasi kunci publik yang disandikan atau token acak yang ditandatangani dikembalikan ke layanan web dari WebAuthn API, yang kemudian disimpan dan diperiksa di sisi server.

Oleh karena itu, dalam kasus autentikator bawaan, akan dimungkinkan untuk menggunakannya hanya di browser dan perangkat di mana ia dilampirkan ke akun. Dengan kata lain, kunci yang bergantung pada platform harus didaftarkan secara terpisah pada setiap perangkat / browser tempat Anda bermaksud untuk masuk ke akun Anda.

Di masa mendatang, akan muncul lebih banyak cara yang memungkinkan pengguna untuk mengaktifkan penggunaan autentikator khusus platform, misalnya, dengan menggunakan pemindaian wajah, atau dengan memasukkan kode PIN dari perangkat.

Saat membuat kredensial atau menghitung tanda tangan, Anda dapat menentukan jenis autentikator yang disukai dalam parameter khusus yang mengambil dua nilai - cross-platformdan platform. Dalam hal ini, pengguna akan diminta untuk hanya menggunakan salah satu dari jenis kunci elektronik.

const credential = await navigator.credentials.create({
    publicKey: {
        authenticatorSelection: {
            authenticatorAttachment: 'cross-platform',
        },
        ...,
    },
});

Manfaat WebAuthn


Apa manfaat teknologi WebAuthn bagi pengguna dan pengembang?

  • Pengguna tidak perlu mengingat dan memasukkan kata sandi apa pun, dan server tidak masing-masing menyimpan kata sandi pengguna, semua kekurangan yang dimiliki kata sandi hilang. Mencuri autentikator fisik dari pengguna jauh lebih sulit daripada memotong kata sandi yang dikirimkan secara elektronik melalui koneksi yang tidak aman, dan kebocoran kunci publik di situs tidak akan membuka kunci pribadi yang tersembunyi di perangkat.
  • origin , . origin . , (thesslstore.com, yubico.com) .
  • WebAuthn - . - web- , .
  • WebAuthn sendiri sebagai API menyediakan pengembang dengan abstraksi atas implementasi autentikator dan memungkinkan Anda untuk menulis kode sekali, yang kemudian akan bekerja dengan semua jenis dan jenis kunci elektronik. Jadi WebAuthn adalah solusi scalable untuk otentikasi pengguna.

Bahkan lebih banyak tentang mengapa WebAuthn lebih aman daripada kata sandi - WebAuthn untuk pengembang: 5 langkah untuk otentikasi yang lebih baik , Memulai dengan kunci keamanan .

Dukungan WebAuthn


Otentikasi dongle berfungsi atau tidak pada perangkat Anda tergantung pada beberapa faktor berbeda. Mulai dari apakah browser Anda mendukung WebAuthn API, dan diakhiri dengan konektor apa yang ada di komputer Anda dan metode komunikasi apa yang didukung oleh autentikator Anda. Kinerja WebAuthn juga sangat bergantung pada perangkat dan OS yang Anda gunakan.

Pada saat penulisan, menurut caniuse.com, WebAuthn API didukung oleh 80,5% pengguna. Menurut statistik pada pengguna Mail.ru, angka ini memiliki urutan yang sama - 79,8%. Namun, untuk menggunakan WebAuthn di semua browser ini, Anda pasti akan membutuhkan kunci elektronik eksternal.

Tidak semua browser yang mendukung API WebAuthn dapat bekerja dengan kunci yang bergantung pada platform (untuk kenyamanan, saya akan menyebut kunci ini sebagai "Sidik Jari" nanti). Selain itu, untuk bekerja dengan tombol-tombol seperti itu, tidak cukup untuk memasang browser yang dapat bekerja dengannya. Perangkat dan OS Anda juga perlu memiliki modul / sensor yang sesuai dan dapat berinteraksi dengannya. Dari semua pengguna Mail.ru, hanya 9,0% yang memiliki kemampuan untuk menambahkan kunci khusus platform.

Saya akan memberi tahu Anda secara singkat tentang dukungan WebAuthn oleh berbagai OS dan browser.

Windows


Dukungan WebAuthn pada Windows sangat baik. Subsistem otentikasi Windows Hello dapat bekerja dengan kunci elektronik. Karena itu, semua versi peramban terbaru untuk OS ini - Microsoft Edge, Google Chrome, Opera dan Mozilla Firefox - mendukung kerja dengan kunci asing dan sidik jari. API Internet Explorer WebAuthn tidak mendukung.


Linux


Otentikator eksternal biasanya didukung oleh distribusi Linux modern, serta peramban seperti Google Chrome, Chromium, dan Mozilla Firefox. Namun, pada beberapa sistem, pengaturan tambahan mungkin diperlukan untuk bekerja dengan kunci asing .

Android


Dukungan WebAuthn di Android juga bagus. Google Chrome, Opera dan Mozilla Firefox - mendukung kerja dengan kunci asing dan sidik jari. Tetapi Microsoft Edge untuk Android sama sekali tidak mendukung WebAuthn API. Ada juga bug di Firefox - menetapkan jenis autentikator yang disukai menggunakan opsi tidak berfungsi untuk itu authenticatorAttachment.


iOS


Di antara semua browser untuk sistem operasi iOS, WebAuthn hanya mendukung Safari versi 13.3. Selain itu, ia hanya dapat bekerja dengan kunci elektronik eksternal. Peramban lain untuk iOS belum mendukung WebAuthn sama sekali.

macOS


Dukungan Microsoft Edge, Google Chrome, Opera dan Mozilla Firefox bekerja dengan kunci asing di macOS. Google Chrome juga mendukung sidik jari, memungkinkan Anda menggunakan WebAuthn dengan Touch ID.


Jika di Edge, Opera dan Chrome antarmuka untuk berinteraksi dengan WebAuthn adalah sama, maka Firefox telah membedakan dirinya di sini. Alih-alih popup cantik di Firefox, saat menggunakan WebAuthn, notifikasi kecil muncul di sudut layar. Jika Anda secara tidak sengaja mengklik pada sebuah halaman, itu hanya runtuh, membuat pengguna bingung apa yang terjadi sekarang.



Namun, Safari belum mendukung WebAuthn. Dukungan WebAuthn diumumkan di Safari 13, yang akan tersedia di macOS 10.15 Catalina. Namun, pada saat penulisan, cek saya menunjukkan bahwa API WebAuthn di Safari, meskipun ada, sangat tidak stabil dan tidak berfungsi dengan semua autentikator. Seperti versi selulernya, Safari tidak berfungsi dengan kunci elektronik bawaan. Selain itu, belum mendukung salah satu kunci elektronik asing.

Jadi, kami menyadari bahwa selain masalah dukungan, WebAuthn memiliki perbedaan yang lebih besar di UI. Perbedaan-perbedaan ini mengarah pada fakta bahwa Anda harus menjelaskan secara lebih rinci kepada pengguna apa yang diperlukan darinya untuk menggunakan pintu masuk melalui kunci elektronik. Selain itu, dengan setiap rilis browser baru, pop-up ini dapat berubah, dan proses menggunakan WebAuthn saat ini bisa sangat berbeda dari apa yang kemarin.

Jelas mengapa ini terjadi. Teknologi WebAuthn masih sangat muda, dan pengembang browser masih bereksperimen dengan berbagai jenis implementasi. Orang hanya dapat berharap bahwa seiring waktu dukungan untuk WebAuthn di browser akan stabil dan kami akan dapat menggunakannya tanpa batasan.

Pendaftaran Authenticator


Jika kami memberi pengguna kesempatan untuk mendaftarkan kunci elektronik yang berbeda di akunnya, maka ia harus memiliki kesempatan untuk melihat daftar mereka dan menghapus yang usang atau tidak perlu dari itu. Ini mungkin berguna, misalnya, dalam hal terjadi kompromi dengan salah satu kunci.

API WebAuthn dirancang sehingga saat membuat dan menggunakan kredensial, klien tidak tersedia informasi apa pun tentang jenis, tipe, dan nama autentikator yang digunakan. Karenanya, kami tidak memiliki data apa pun sehingga kami dapat membedakan satu kunci dari yang lain. Semua kunci dalam daftar akan disajikan secara merata tanpa fitur yang membedakan. Pertanyaan: apa yang harus dilakukan?


Anda dapat memperoleh beberapa informasi tentang autentikator yang digunakan jika Anda meminta kredensial yang disebut saat membuat kredensial. sertifikasi. Sertifikasi adalah cara bagi autentikator untuk membuktikan keasliannya ke server. Dalam beberapa kasus, informasi tentang produsen utama dapat diperoleh dari sertifikasi. Namun dalam kasus umum, data yang digunakan masih belum cukup untuk membedakan satu kunci elektronik yang terkait dengan akun dari yang lain.

const credential = await navigator.credentials.create({
    publicKey: {
        attestation: 'direct',
         ...,
    },
});

Oleh karena itu, setelah menghubungkan kunci ke akun di Mail, kami memberikan pengguna kesempatan untuk menetapkan beberapa nama ke catatan yang baru dibuat. Dan sudah lebih jauh pengguna dapat membedakan satu kunci dari yang lain dengan nama ini.

Fakta bahwa informasi yang tersedia untuk klien dan server tidak mengandung data tentang jenis autentikator menyebabkan fitur WebAuthn yang tidak menyenangkan.

Bayangkan seorang pengguna yang hanya menambahkan satu sidik jari ke akunnya, misalnya, di ponsel cerdasnya. Saat kami ingin masuk menggunakan API WebAuthn, kami meneruskan panggilan fungsinavigator.credentials.getdaftar semua kunci yang terkait dengan akun. Tetapi browser tidak dapat menentukan dari daftar ini mana autentikator yang hadir pada perangkat dan mana yang tidak. Oleh karena itu, ia terpaksa selalu menawarkan pengguna untuk menggunakan WebAuthn.

Oleh karena itu, bahkan ketika mencoba masuk ke akun di komputer yang tidak mendukung otentikasi melalui sidik jari, pengguna masih akan ditawari untuk menggunakan WebAuthn.

Untuk menerapkan perilaku yang benar dalam situasi seperti itu, Anda perlu memperbaiki standar WebAuthn itu sendiri. Misalnya, untuk menyandikan informasi tentang apakah kunci lintas platform atau sidik jari digunakan untuk membuatnya dan tidak menawarkan kepada pengguna WebAuthn jika diketahui sebelumnya bahwa ia tidak akan dapat menggunakannya.

Ada beberapa cara untuk mengatasi perilaku ini dalam beberapa situasi. Sebagai contoh, izinkan pengguna untuk mendaftarkan sidik jari dan kunci fisik hanya satu per satu. Dan ketika menggunakan kunci, filter sidik jari pada perangkat yang jelas tidak mendukungnya. Tetapi metode ini tidak menyelesaikan masalah sepenuhnya. Dan tidak ada cara yang dapat diandalkan untuk menyelesaikan masalah ini.

Pengguna kami belum menerima keluhan tentang perilaku ini, jadi saat ini kami sedang menyelidiki fitur ini dan memutuskan apa yang harus dilakukan di masa depan.

WebAuthn bekerja pada subdomain yang berbeda


Seperti yang saya katakan sebelumnya, WebAuthn memberikan perlindungan di luar kotak terhadap phishing. Saat mendaftarkan kunci elektronik, informasi disimpan origindi mana kunci ini didaftarkan. WebAuthn tidak mengizinkan penggunaan kunci elektronik ini pada sumber daya, dengan yang lain origin.

Layanan web besar seperti Mail.ru sering menggunakan beberapa domain berbeda untuk pekerjaan mereka. Misalnya, kami memiliki domain e.mail.ruuntuk Mail dan cloud.mail.ruuntuk Cloud. Dan pada masing-masing dari mereka kita memiliki bentuk otorisasi yang sama. Dalam hal ini, pengaturan standar WebAuthn tidak cukup. Agar kita dapat menggunakan originkunci yang terdaftar pada yang lain di satu origin, perlu bahwa kedua domain ini memiliki akhiran yang sama (subdomain umum lebih dari tingkat pertama).

Misalnya di domaine.mail.rudan cloud.mail.ruakhiran umum adalah mail.ru.

Dalam hal ini, saat mendaftar dan menggunakan kunci elektronik, kita dapat menentukan parameter yang rpIdsama dalam opsi permintaan mail.ru, dan kemudian kita dapat menggunakan kunci yang sama pada subkunci itu sendiri https://mail.rudan pada subdomainnya.

const credential = await navigator.credentials.create({
    publicKey: {
        rp: {
            name: 'Mail.ru Group',
            id: 'mail.ru',
        },
        ...,
    },
});

WebAuthn berfungsi di iframe


Untuk alasan keamanan, panggilan ke metode WebAuthn dilarang dari iframe lintas asal. Proyek kami menggunakan formulir otorisasi tunggal, itu terletak di https://account.mail.ru/login , dan ketika kami ingin menunjukkan formulir otorisasi pada proyek lain, misalnya, di Mail atau di Cloud, iframe sebenarnya ditambahkan ke halaman di mana url ini terbuka. Solusi ini memungkinkan kami untuk secara bersamaan memperbarui formulir itu sendiri pada semua proyek yang menggunakannya, dan menyederhanakan pengumpulan statistik, dan juga meningkatkan UX pengguna, memungkinkannya untuk tetap berada di layanan yang sama di tempat ia semula.



Dalam kasus kami, pembatasan panggilan ke metode WebAuthn dari dalam iframe membuat kami mencari cara untuk mengatasinya, karena kami ingin memungkinkan kami untuk masuk melalui WebAuthn di mana pun kami menunjukkan formulir otorisasi.

Apa yang telah kita lakukan. Untuk membuka formulir otorisasi pada semua layanan, kami menggunakan perpustakaan kecil, yang pada dasarnya hanya membuat iframe pada halaman dengan url yang benar dan setelah memuat isinya menunjukkan iframe pada halaman. Perpustakaan ini mendukung komunikasi dengan iframe melalui postMessagedan menggunakannya, misalnya, untuk mengubah ukuran iframe ketika mengubah ukuran isinya.

Kami datang dan menerapkan mekanisme berikut:

  1. dalam aplikasi otorisasi saat menggunakan WebAuthn, kami menentukan apakah kami sekarang terbuka di dalam iframe atau tidak;
  2. jika kita terbuka di dalam iframe, maka alih-alih memanggil browser WebAuthn API, kita membuat serialisasi parameter panggilan dan mengirimkannya melalui postMessagejendela induk;
  3. di jendela induk kami deserialize parameter ini dan memanggil metode WebAuthn;
  4. ketika kami menerima jawaban, kami mengurutkannya dengan cara yang sama dan mengirimkannya melalui bagian postMessagedalam iframe, tempat kami menerima jawaban ini dan melakukan pemrosesan lebih lanjut.

Dengan demikian, kami menghindari larangan ini dan menyadari kemungkinan menggunakan kunci yang sama selama otorisasi di semua layanan perusahaan.

Otomasi Uji WebAuthn


Di tim kami untuk semua proyek dan fitur baru, kami selalu menulis autotest UI integrasi menggunakan solusi selenium dan protokol WebDriver. Oleh karena itu, selama pengembangan WebAuthn, muncul pertanyaan tentang bagaimana menulis autotests UI di atasnya.

Kesulitan dalam menulis autotests tersebut adalah bahwa protokol WebDriver belum memiliki metode untuk mengotomatisasi interaksi dengan WebAuthn. Dan dalam standar itu sendiri masih belum ada dukungan untuk pengujian otomasi WebAuthn API (tetapi ada masalah pada topik ini). Gagasan pertama tentang bagaimana otomatisasi ini dapat diatur dijelaskan dalam konsep Otentikasi Web: API untuk mengakses Kredensial Kunci Publik Level 2 dan belum dipublikasikan, belum lagi didukung di tempat lain. Karena itu, saya harus mencari solusi alternatif.

Karena kami tidak dapat bekerja dengan implementasi asli fungsi WebAuthn di autotests (tidak ada metode untuk mengontrol browser), maka kami harus melakukan hal berikut.

Di suatu tempat di autotest, sebelum mencoba menggunakan WebAuthn, kami menambal objek host global browser dan mengganti fungsi asli dengan implementasi kami. Di sini kita menyimpan argumen yang dengannya fungsi-fungsi asli dipanggil menjadi variabel dan mengembalikan janji.

//    WebAuthn   
navigator.credentials.create = (options) => {
    window.credentialsCreateArgs = options;

    return new Promise((resolve, reject) => {
        window.credentialsCreateSuccess = resolve;
        window.credentialsCreateFail = reject;
    });
};

Selanjutnya, kita perlu entah bagaimana mendapatkan hasil fungsi untuk mengembalikannya untuk meniru pekerjaan WebAuthn dalam pengujian. Kami selalu dapat mengembalikan semacam jawaban dengan kode tetap.

// -    
const credentialsCreateResponse = { /* constant object */ };

window.credentialsCreateSuccess(credentialsCreateResponse);

Dalam hal ini, kami harus mengajari server kami untuk menerima jawaban ini dan tidak memvalidasinya, tetapi menganggapnya sudah benar secara otomatis.

Apa kerugian dari tes semacam itu? Dalam hal ini, kami tidak akan dapat:

  • periksa apakah klien dengan benar membentuk dan memutar parameter ke fungsi WebAuthn;
  • periksa kebenaran perubahan backend saat meluncurkan rilis backend.

Dengan demikian, tes semacam itu tidak akan cukup andal, dan ini tidak cocok untuk kita.

Kami memutuskan untuk mengambil jalan yang lebih sulit dan sebagai hasilnya kami menulis implementasi protokol dan algoritma FIDO2 kami sendiri di Node.js, dengan bantuan yang kami berhasil mengunci fungsi-fungsi ini sedekat mungkin dengan implementasi asli.

Yaitu, kami menulis fungsi yang, berdasarkan pada parameter permintaan, menghitung respons untuk fungsi WebAuthn yang dikunci sehingga server menganggapnya benar.

// -    
const credentialsCreateResponse =
    calcCredentialsCreateResponse(window.credentialsCreateArgs);
 
window.credentialsCreateSuccess(credentialsCreateResponse);

Akibatnya, skema operasi autotest adalah sebagai berikut:

  1. dapatkan argumen bahwa metode WebAuthn dipanggil dengan;
  2. kami menjalankan argumen ini melalui fungsi yang mengimplementasikan algoritma yang sama seperti di dalam autentikator nyata;
  3. kami mendapatkan hasilnya, dan mengembalikannya dari fungsi yang kami ganti;
  4. semua kode lainnya dalam layanan kami memproses respons ini dalam mode biasa dan sebagai hasilnya, semua perilaku layanan tidak berbeda dari perilaku pengguna yang sebenarnya.

Sumber autotest semacam itu dan implementasi autentikator paling rahasia ada di repositori github , Anda dapat memulai dan menyelidiki pekerjaan mereka nanti. Saat menulis autentikator, kami hanya dipandu oleh spesifikasi w3.org dan dokumentasi Node.js.

Sekarang dan Masa Depan WebAuthn


Jadi apa yang kita miliki saat ini.

Kami meluncurkan entri kunci elektronik yang berfungsi penuh pada akhir September 2019. Sekarang kami tidak mengiklankan jenis entri ini, dan itu tidak digunakan dengan sangat aktif - kurang dari seratus pengguna unik per hari. Tetapi kami yakin bahwa seiring waktu jumlah mereka hanya akan bertambah, dan cepat atau lambat, pencatatan kunci elektronik akan menjadi salah satu jenis utama pencatatan ke dalam akun Anda.

Yang membuat kami tidak aktif mempromosikan entri semacam itu adalah bahwa WebAuthn sendiri masih belum cukup andal dan stabil di browser, dan ada banyak nuansa mengenai dukungan dan operasinya.

Mengapa WebAuthn sekarang menjadi fitur bukan untuk khalayak luas?

Faktor paling mendasar di sini adalah mengharuskan pengguna untuk memiliki perangkat khusus - kunci elektronik. Sekarang kebutuhan untuk itu tidak begitu terasa oleh pengguna. Banyak pengguna tidak menyadari keberadaan mereka. Namun seiring waktu, ketika semakin banyak layanan mulai mendukung cara masuk ini, jumlah pengguna dengan kunci tersebut juga akan mulai bertambah.

Sebuah lompatan maju yang signifikan dalam popularitas WebAuthn dapat terjadi ketika para insinyur Google menyelesaikan pengembangan dan pengujian kemungkinan menggunakan smartphone di Android dan iOS sebagai kunci elektronik fisik eksternal untuk WebAuthn dan membuka peluang ini untuk semua layanan Internet. Dalam hal ini, setiap pemilik smartphone modern pada dasarnya akan mendapatkan kesempatan untuk menggunakannya sebagai kunci WebAuthn dan jumlah pengguna WebAuthn akan meningkat secara dramatis. Sekarang fitur ini hanya tersedia untuk pengguna layanan email Google.



Bagaimana lagi Anda bisa menggunakan WebAuthn?


Mail.ru menggunakan WebAuthn sekarang sebagai alternatif kata sandi untuk memasukkan akun. Tetapi pada dasarnya WebAuthn dapat digunakan seperti faktor otorisasi apa pun. Ini dapat digunakan sebagai pengganti faktor pertama dalam otentikasi satu faktor. Jadi alih-alih yang kedua - sebagai perlindungan kata sandi tambahan dengan dua faktor. Selain itu, konfirmasi melalui kunci elektronik dapat digunakan, misalnya, ketika mengembalikan akses ke akun jika pengguna telah kehilangan atau lupa kata sandinya.

WebAuthn dapat digunakan sebagai langkah pengamanan tambahan saat mengedit pengaturan kritis akun Anda. Bayangkan betapa nyamannya itu - Anda pergi ke pengaturan profil di layanan favorit Anda, dan Anda tidak perlu mengingat dan memasukkan kata sandi untuk mengubahnya! Cukup letakkan jari Anda pada pemindai sidik jari, dan Anda akan diteruskan.

Anda dapat menemukan skenario yang lebih berbeda untuk menggunakan WebAuthn di artikel Medium ini .

Pertanyaan dan jawaban populer


Di mana saya bisa membeli kunci elektronik?


Sejauh ini, tidak banyak tempat di Rusia tempat Anda dapat membeli kunci elektronik yang kompatibel dengan protokol FIDO2. Sebagian besar pemasok hanya menjualnya secara massal, dalam batch 10 atau lebih. Anda dapat membeli kunci elektronik sepotong demi sepotong di toko-toko berikut:


Selain itu, kunci tersebut dapat dipesan di toko online yang ramah, misalnya, di Amazon . Pada artikel ini, ada karakteristik komparatif sakelar elektronik 10 model dengan tautan ke toko tempat sakelar itu dapat dibeli.

Bagaimana jika saya kehilangan kunci elektronik saya?


Dengan menggunakan kunci elektronik, Anda harus memperlakukannya dengan perhatian yang sama dengan kunci apartemen atau mobil. Jika kami kehilangan kunci apartemen, kami biasanya mengganti kunci dan mendapatkan kunci baru. Hal yang sama terjadi dengan kunci elektronik: jika hilang, Anda harus segera menghapusnya dari semua akun yang ditautkan, dan melampirkan autentikator baru ke semua akun.

Jika kehilangan kunci elektronik utama, Anda harus memiliki beberapa metode otentikasi tambahan. Misalnya, menggunakan aplikasi untuk menghasilkan kode, atau menggunakan kunci cadangan yang dapat disimpan di tempat yang dilindungi khusus: di tempat yang aman atau di sel bank.

Apa yang harus saya lakukan jika orang lain mendapatkan akses ke kunci elektronik saya?


Jika otentikasi dua faktor termasuk dalam akun Anda dan kunci elektronik hanyalah salah satu faktor, maka dalam hal ini akun Anda akan dilindungi dari peretasan. Kecuali jika penyerang memiliki akses ke faktor kedua.

Jika kunci elektronik adalah satu-satunya faktor yang cukup untuk memasuki akun, maka bahkan dalam kasus ini penyerang harus mengetahui nama akun di mana kunci elektronik ini didaftarkan. Informasi ini tidak disimpan di dalam kunci elektronik, dan oleh karena itu kunci elektronik yang hilang secara tidak sengaja dengan tingkat probabilitas yang tinggi akan sama sekali tidak berguna bagi orang yang lewat yang menemukannya.

Namun, ada skema di mana kunci elektronik dapat digunakan sebagai pengganti tidak hanya untuk kata sandi, tetapi juga untuk login. Dalam skenario ini, server hanya menyediakan kredensial saat meminta kredensial.origin, dan kredensial itu sendiri sepenuhnya disimpan dalam autentikator. Dalam hal ini, kunci elektronik yang hilang sudah dapat dengan mudah digunakan untuk masuk ke akun Anda, dan kemudian Anda harus lebih berhati-hati dengan autentikator Anda. Untuk perlindungan dalam skenario seperti itu, Anda dapat menggunakan kunci elektronik dengan langkah-langkah keamanan tambahan, misalnya, kunci, untuk aktivasi yang Anda perlu memasukkan kode PIN.

Dalam hal apa pun, segera setelah Anda melihat kehilangan kunci Anda, Anda harus segera melepaskannya dari semua akun di semua layanan, tempat Anda dapat menggunakannya untuk masuk. Itu sebabnya semua layanan harus menyediakan kemampuan untuk mengelola daftar autentikator terikat. Semakin cepat Anda melihat kerugiannya, semakin sedikit waktu yang dimiliki penyerang untuk mendapatkan akses ke data Anda.

Sekarang data biometrik saya akan disimpan di server Mail.ru/Google/Microsoft?


Ketika WebAuthn bekerja dengan autentikator bawaan (misalnya, menggunakan Touch ID pada Mac OS), hanya sensor yang sesuai dan sistem operasi itu sendiri yang memiliki akses ke data biometrik Anda. Layanan web tidak menerima atau memproses informasi biometrik apa pun, ia hanya berfungsi dengan kunci kriptografi publik dan dengan data yang ditandatangani dengan kunci pribadi.

Dan di server itu sendiri, hanya informasi tentang kunci publik yang disimpan. Oleh karena itu, WebAuthn tidak menggunakan data biometrik Anda dengan cara apa pun untuk bekerja dengan autentikator bawaan.

Kesimpulan


Seperti yang kami ketahui, WebAuthn memiliki banyak keunggulan penting dibandingkan kata sandi:

  • saat menggunakan WebAuthn tidak perlu mengingat dan memasukkan kata sandi;
  • WebAuthn - , ;
  • WebAuthn ;
  • WebAuthn β€” .

Namun, kata sandi tidak boleh dibuang. Kunci fisik masih bisa dicuri atau hilang, seperti kata sandi. Tetapi kata sandi memiliki keunggulan penting. Selama mereka hanya disimpan di kepala, mereka tidak akan bisa mengenalinya tanpa sepengetahuan pemilik.

Kesimpulannya, saya ingin mengatakan bahwa teknologi WebAuthn adalah teknologi yang sangat menjanjikan yang mengubah elemen dasar dan penting dari berfungsinya semua layanan web modern sebagai otentikasi. Ini juga merupakan teknologi yang cukup muda dan pengguna belum terbiasa. Tetapi itu adalah kekuatan kita untuk membuatnya lebih populer dan nyaman.

Saya harap pengalaman kami dalam mengimplementasikan WebAuthn di Mail.ru Mail akan membantu Anda mendukungnya di layanan Anda, dan bersama-sama kami akan membuat Internet lebih aman dan modern!

Bahan tambahan



All Articles