Wawancara dengan Insinyur Sertifikasi Senior FIDO Alliance tentang Otentikasi Tanpa Kata Sandi
Pengguna kami meminta kami menerapkan otentikasi dua faktor melalui aplikasi Google. Dan baru-baru ini, kami telah
memberi mereka kesempatan ini. Sekitar waktu yang sama, konsorsium FIDO Alliance menerbitkan standar untuk otentikasi tanpa kata sandi di situs, dalam aplikasi seluler dan layanan web - WebAuthn dan CTAP.
Kami menjadi tertarik pada topik ini dan
menyiapkan bahan tentang Habré , di mana kami berbicara tentang metode yang mendasari protokol baru.
Kemudian, untuk mengklarifikasi beberapa poin mengenai seluk beluk standar, kami berbicara dengan Yuri Akkermann (
herrjemand ), insinyur sertifikasi senior di FIDO Alliance. Dia menjawab beberapa pertanyaan kami tentang otentikasi FIDO di masa lalu, sekarang, dan di masa depan. Kami mempersembahkan teks wawancara untuk Anda.
/ Flickr / zhrefch / PDTolong beritahu kami tentang latar belakang dan pengalaman Anda di bidang IT secara keseluruhan. Bagaimana Anda memulai pekerjaan Anda di industri ini?
Saya telah melakukan pemrograman sejak saya berusia lima belas tahun. Setelah sekolah, saya pergi ke universitas, tempat saya belajar ilmu komputer dan matematika. Pada tahun kedua saya menjadi tertarik pada kriptografi, masalah keamanan informasi dan "tersandung" pada FIDO. Saya sangat menyukai protokol mereka, dan pada akhirnya saya menulis perpustakaan U2F untuk Python Flask dan membuat presentasi.
Pekerjaan saya dihargai oleh FIDO. Apalagi mereka hanya mencari insinyur sertifikasi. Pada akhirnya, saya menjadi bertanggung jawab untuk sertifikasi teknis.
Berapa lama Anda berurusan dengan topik yang terkait dengan otentikasi dengan FIDO? Tugas apa yang Anda selesaikan dalam proses pengembangan standar baru?
Saya telah bekerja dengan protokol FIDO selama tiga tahun - dua di antaranya di FIDO Alliance. Peran utama saya adalah sertifikasi teknis dan alat otomatis untuk menguji implementasi sesuai spesifikasi. Tanggung jawab saya termasuk mengembangkan dan mendukung alat itu sendiri, serta menulis rencana pengujian - daftar tes untuk memeriksa server, klien, dan autentikator. Saya pikir menulis rencana pengujian adalah proses yang paling memakan waktu, karena itu memerlukan pemahaman tentang semua seluk-beluk protokol dan standar yang digunakan di dalamnya.
Saya juga memberi saran kepada kelompok kerja tentang kemungkinan peningkatan spesifikasi, membuat presentasi, dan menulis artikel dari waktu ke waktu.
Bagaimana ide menciptakan standar baru untuk otentikasi lahir? Mengapa Anda memutuskan bahwa dunia dan komunitas membutuhkan solusi baru di bidang ini? Apa kerugian dari format yang sudah ada yang ingin ditutup oleh WebAuthn?
FIDO Alliance didirikan pada 2013 oleh Agnitio, Infineon Technologies, Lenovo, Nok Nok Labs, PayPal, dan Validitas, yang mengembangkan UAF. Beberapa saat kemudian mereka bergabung dengan Google, Yubico dan NXP - ini bekerja pada pendahulu U2F dan berpikir akan menguntungkan untuk bergabung, karena ide-ide mereka bertepatan dengan ide-ide Aliansi. Mereka berusaha melindungi pengguna internet dari phising, memecahkan masalah kegunaan kata sandi, dan juga mengembangkan aksesibilitas dan keamanan teknologi biometrik.
Apakah sudah ada studi pendahuluan yang dilakukan yang memperkuat niat untuk menciptakan standar, atau mendorong penciptaannya? Jika ya, data seperti apa yang Anda analisis?
Anggota aliansi seperti Google, Microsoft, Samsung, Yubico dan lainnya aktif bekerja untuk menciptakan dan mempromosikan standar. Mereka sedang menjajaki pasar, mencoba memahami bagaimana FIDO dapat "masuk" ke dalam berbagai ekosistem. Google, misalnya,
melakukan penelitian tentang migrasi faktor kedua dari kata sandi satu kali ke U2F.
Bagaimana protokol CTAP lahir? Bagaimana ini terkait dengan WebAuthn?
FIDO terdiri dari tiga bagian: server, klien (browser) dan autentikator. Server mengirim panggilan ke klien, klien meneruskan panggilan ke autentikator, yang menandatanganinya dan mengembalikannya ke klien, dan yang sudah dikirim ke server.
Agar server menggunakan otentikasi FIDO, klien memiliki WebAuthn JS API. Klien berkomunikasi dengan autentikator dengan menggunakan protokol CTAP2 tingkat rendah (Klien-ke-Otentator Protokol 2). CTAP2 menjelaskan struktur dan transport permintaan CBOR, seperti USB, NFC, dan BLE untuk berkomunikasi dengan autentikator. Kombinasi kedua standar ini disebut FIDO2.
Salah satu tujuan membuat format adalah untuk melindungi dari phishing. Apa saja kelebihan dibandingkan dengan solusi lain?
Jika kita berbicara tentang solusi yang ada, satu-satunya hal yang dapat dibandingkan dengan FIDO adalah sertifikat klien atau TLS CCA (Otentikasi Sertifikat Klien). FIDO dan CCA adalah protokol respons panggilan-aman phising pada kunci publik. Tetapi mereka memiliki perbedaan yang signifikan.
CCA tidak dilindungi dari serangan replay. Mereka menggunakan kembali satu sertifikat di beberapa situs, yang dapat menyebabkan deanonimisasi pengguna. Di FIDO, kami membuat pasangan kunci unik baru untuk setiap pendaftaran untuk menjaga privasi.
CCA juga memiliki masalah dengan menyimpan kunci, karena dalam banyak kasus kunci pribadi dienkripsi dalam PKCS12, atau hanya terletak pada clear. Dengan demikian, bahkan aplikasi yang tidak terjangkau dapat mencurinya tanpa masalah. Dalam FIDO, semua kunci disimpan dengan aman, misalnya, dalam penyimpanan SecureEnclave satu arah. Memulihkan kunci dari jenis penyimpanan ini sangat sulit.
CCA memiliki kesulitan dengan implementasi yang tepat di sisi server, karena dukungan CCA penuh meninggalkan banyak yang diinginkan. Dan karena kerumitan bekerja dengan TLS, pengembang membuat banyak kesalahan. FIDO hanya membutuhkan dukungan untuk kriptografi dasar itu sendiri. CCA dapat diimplementasikan melalui HTTP, yang tidak dapat dilakukan di WebAuthn. CCA juga memiliki masalah dengan portabilitas dan kemudahan penggunaan.
Saya tidak percaya bahwa Aliansi menemukan sesuatu yang baru. Kami hanya mengembangkan protokol yang baik yang mencakup mekanisme keamanan yang ada.
/ Flickr / markus spiske / PDApakah penggunaan standar tidak akan mengungkapkan vektor serangan tambahan yang terkait dengan fakta bahwa perlu menyimpan sejumlah besar informasi biometrik?
Salah satu prinsip dasar kami adalah privasi. Informasi biometrik disimpan pada chip yang aman dan tidak pernah meninggalkannya. Perusahaan kami bekerja dengan pembaca yang disertifikasi oleh FIDO atau FIPS.
Kami juga tidak menggunakan informasi biometrik untuk hal lain selain untuk mengonfirmasi keberadaan pengguna. Dan kami memiliki program sertifikasi biometrik untuk menguji autentikator.
Anda pernah mengatakan bahwa otentikasi dengan kode SMS adalah opsi 2FA yang buruk. Bagaimana Anda bisa mengomentari ini?
Kode SMS atau OTP SMS adalah otentikasi dua faktor dengan kata sandi satu kali yang dikirimkan melalui SMS. Karena itu, ternyata solusi ini rentan terhadap phising. Jika pengguna Anda terjebak dalam phising dan memberikan nama pengguna dan kata sandi, apa yang akan menghentikannya dari mentransmisikan kode SMS ke penjahat cyber?
Kita seharusnya tidak melupakan masalah menggunakan SMS sebagai transportasi. Tiga tahun lalu, 400 ribu akun diretas ke bank Jerman karena kerentanan dalam protokol SS7, yang digunakan untuk merutekan informasi telekomunikasi antara operator telekomunikasi yang berbeda. Penyerang yang mendapatkan akses tidak sah ke jaringan SS7, di mana tidak ada otentikasi, dapat mendaftarkan jumlah korban sendiri dan mendapatkan kode mereka.
Juga, hari ini siapa pun dapat membeli stasiun pangkalan GSM seharga $ 500-600 dan mencegat SMS menggunakan serangan MITM. Dan akhirnya, ada bahaya yang terkait dengan rekayasa sosial. Saya pikir banyak
yang akrab dengan cerita ketika penyerang mencuri sejumlah besar uang dari rekening bank dengan mengeluarkan duplikat kartu SIM korban. Ini terjadi di Rusia dan negara-negara lain dengan keteraturan yang patut ditiru.
Bagaimana jika Anda perlu memasukkan layanan pada beberapa perangkat atau beberapa orang menggunakan layanan yang sama sekaligus? Apakah standar mendukung mode operasi ini?
Tidak seperti kata sandi, mungkin ada banyak autentikator. Pengguna dapat mendaftarkan ponsel, laptop, token, dan menggunakannya untuk otentikasi. Selain itu, satu token dapat "diikat" ke beberapa akun tanpa kehilangan privasi.
Tetapi bagaimana jika token itu hilang? Apakah mungkin untuk mengembalikan akses ke layanan?
Otentikasi FIDO harus dianggap sebagai kunci rumah. Jika Anda kehilangan kunci, Anda selalu dapat mengambil cadangan dari istri, anak-anak, ibu, nenek, atau, dalam kasus terburuk, mendapatkannya dari bawah keset pintu. Karena itu, kami menyarankan Anda selalu memiliki pengidentifikasi cadangan dan menyimpannya, misalnya, di brankas.
Jika kita berbicara tentang memulihkan akses ke layanan, maka ini benar-benar masalah yang sulit. Pemulihan bukan bagian dari standar, karena sumber daya yang berbeda mengembalikan akses ke akun dengan cara yang berbeda. Pendekatan klasik adalah kode satu kali yang tidak dilindungi terhadap phishing. Facebook memungkinkan Anda untuk mendapatkan kembali akses melalui teman.
Solusi yang paling menjanjikan hingga saat ini adalah
Delegated Recovery - sebuah protokol pemulihan berdasarkan penyimpanan rahasia terenkripsi di layanan lain. Kebetulan, itu ditulis oleh salah satu pencipta U2F Bratt Hill (Bratt Hill). Pemulihan adalah masalah yang agak sulit dan menarik, solusinya masih harus ditemukan.
Kunci pribadi dalam autentikator harus dilindungi salinan. Dalam bentuk apa dan di mana pengidentifikasi disimpan? Bagaimana mereka dipertukarkan?
Pada setiap pendaftaran, autentikator menghasilkan pasangan kunci unik baru dan menetapkannya sebagai pengenal acak yang disebut ID kredensial atau kredid. Kunci pribadi disimpan dalam penyimpanan yang aman, seperti SecureEnclave, TPM, atau TEE.
Kunci pribadi tidak pernah meninggalkan autentikator, karena ini tidak diperlukan. Jika pengguna ingin menambahkan autentikator lainnya, maka ia hanya mendaftarkannya, menghasilkan pasangan kunci dan pengidentifikasi baru, dan mentransfer kunci publik dengan pengidentifikasi ke situs. Selama otentikasi, situs menerjemahkan pengidentifikasi ke authenticator, dan authenticator menemukan pasangan kunci dengannya dan menandatangani panggilan.
Bagaimana standar baru ini terkait dengan persyaratan undang-undang perlindungan data (mis. GDPR)?
Prinsip kami sangat konsisten dengan GDPR. Bahkan dalam mode dua faktor, kami membuat otentikasi phishing aman. Jika kita berbicara tentang otentikasi tanpa kata sandi, maka tidak ada kata sandi yang dikirimkan di sini sama sekali. Selain itu, tidak seperti sertifikat klien, protokol kami tidak dapat digunakan sebagai cookie super. Oleh karena itu, banyak perusahaan sudah mengerjakan implementasi protokol kami.
Dan siapa yang sudah menerapkan standar?
Google, Facebook, Dropbox, Tenaga Penjualan, Bank of America, NTT Docomo ... Kami memiliki ratusan perusahaan dan setengah miliar pengguna setiap hari. Kami tumbuh setiap hari. Tapi tetap saja, beralih ke otentikasi tanpa kata sandi penuh akan memakan waktu.
Seberapa cepat standar memungkinkan transisi dari metode otentikasi lain?
Beralih dari solusi otentikasi dua faktor yang ada (misalnya, dari OTP) ke FIDO cukup sederhana. Anda hanya perlu menghubungkan perpustakaan dan menerapkan beberapa perubahan di sisi klien. Di FIDO2, opsi untuk otentikasi tanpa kata sandi hanyalah tanda tambahan saat pendaftaran. Mentransfer seluruh ekosistem ke otentikasi tanpa kata sandi penuh akan memakan waktu. Kami memperkirakan bahwa dalam 10 tahun transisi ini akan menyelesaikan 80% dari semua layanan.
Apa rencana FIDO untuk mengembangkan standar? Perbaikan apa yang direncanakan akan dilakukan dalam waktu dekat? Dan dalam jangka panjang?
Sejauh ini, kami telah fokus mempromosikan standar. Ada jutaan situs di dunia - ini artinya kita memiliki sejuta hal untuk dilakukan. Dalam jangka panjang, kami berencana untuk bekerja menerapkan standar untuk Internet hal untuk meningkatkan keamanan gadget IoT. Rencana tersebut juga mencakup pengerjaan sistem otentikasi negara, eID, paspor, dan sistem identifikasi terdesentralisasi.
Bagaimana Anda berencana untuk terus bekerja di WebAuthn? Bagaimana komunitas TI dapat membantu Anda?
Saya, seperti sebelumnya, melanjutkan pekerjaan saya sebagai duta besar di komunitas pengembang: Saya menerbitkan artikel, bekerja pada sumber terbuka, membuat presentasi, dan melakukan pelatihan. Adapun bantuan masyarakat, saya hanya bisa mengatakan: "Kami membutuhkan lebih banyak emas open source."
PS Yuri Akkermann juga menyiapkan artikel tentang Habré, di mana ia menggambarkan mekanisme keamanan utama FIDO2 dan meninjau API JS untuk bekerja dengannya.