Debugger kode TOTP / 2FA

Apa sebenarnya keenam digit itu

Sebuah kode TOTP — angka yang digulirkan aplikasi autentikator setiap tiga puluh detik — tidak acak dan tidak disimpan di mana pun. Ia dihitung, baik di ponsel Anda maupun di server, dari dua hal yang sudah mereka bagi: sebuah rahasia yang disetel sekali saat Anda mengaktifkan autentikasi dua faktor, dan waktu saat ini. Karena kedua sisi bisa menghitungnya secara mandiri, tak ada yang harus berpindah di antara mereka saat Anda masuk; server cukup menjalankan perhitungan yang sama dan memeriksa bahwa jawabannya cocok dengan jawaban Anda.

TOTP (RFC 6238) adalah lapisan tipis di atas skema yang lebih tua, HOTP (RFC 4226). HOTP mengubah sebuah rahasia dan sebuah penghitung menjadi sebuah kode; TOTP hanyalah HOTP dengan penghitung disetel ke jumlah langkah waktu sejak epoch Unix. Itulah seluruh gagasannya: bagi waktu Unix saat ini dengan panjang langkah (30 detik secara default) dan berikan hasilnya ke HOTP. Alat ini menampilkan setiap langkah perhitungan itu, karena ketika sebuah kode tak terverifikasi, jawabannya hampir selalu terlihat di suatu tempat dalam derivasi.

Derivasi, langkah demi langkah

Lima langkah membawa rahasia dan waktu ke digit yang Anda ketik. Alat mencetak masing-masing agar Anda bisa membandingkan dengan implementasi Anda sendiri:

• Penghitung. Ambil waktu Unix dalam detik, kurangi T0 (0 di setiap penyebaran nyata), bagi dengan periode, dan bulatkan ke bawah. Pada langkah 30 detik, setiap momen dalam setengah menit yang sama memberi penghitung yang sama, itulah sebabnya sebuah kode bertahan selama ia bertahan.
• HMAC. Tulis penghitung sebagai 8 bita big-endian dan hitung HMAC(rahasia, penghitung) dengan hash yang dipilih — SHA-1 di hampir setiap aplikasi. Ini menghasilkan digest 20 bita untuk SHA-1 (32 untuk SHA-256, 64 untuk SHA-512).
• Offset. Ambil empat bit rendah dari bita terakhir digest. Itu angka dari 0 sampai 15, dan mengatakan di mana membaca dalam digest — pemotongan dinamis, agar rahasia yang sama tak selalu memakai bita yang sama.
• Nilai 31-bit. Baca empat bita mulai dari offset dan masker bit teratas (untuk menghindari kekeliruan tanda). Tersisa sebuah bilangan bulat 31-bit.
• Kode. Ambil bilangan bulat itu modulo 10^digit dan isi dengan nol di kiri. Enam digit adalah pilihan hampir universal; tujuh dan delapan ada dan diizinkan.

Pemaskeran bit teratas dan modulo adalah satu-satunya langkah yang berkehilangan: banyak digest berbeda memetakan ke enam digit yang sama, dan itu tak apa, karena kode hanya perlu sulit ditebak dalam tiga puluh detik ia hidup, bukan unik selamanya.

Mengapa sebuah kode tak cocok — tiga penyebab yang biasa

Ketidakcocokan TOTP tak pernah datang dengan pesan galat; kodenya sekadar salah. Dalam praktik hampir selalu satu dari tiga hal, dan panel di sini disusun untuk membedakannya:

• Rahasia dibaca dalam format yang salah. Rahasia autentikator adalah Base32, tetapi karakter yang sama dibaca sebagai hex — atau rahasia yang sebenarnya hex dibaca sebagai Base32 — menghasilkan bita yang sama sekali berbeda dan kode yang sama sekali berbeda. Alihkan sakelar format dan lihat mana yang memberi kode yang Anda harapkan.
• Sebuah parameter berbeda. Default yang menyeluruh adalah HMAC-SHA-1, 6 digit, periode 30 detik. Sebuah server yang memakai SHA-256, atau 8 digit, atau langkah 60 detik, akan tak sepakat dengan aplikasi yang dibiarkan pada default. otpauth:// URI membawa ketiganya, itulah sebabnya memindai QR mendapatkannya dengan benar dan mengetik rahasia dengan tangan sering tidak.
• Jam menyimpang. TOTP mengasumsikan kedua sisi sepakat tentang waktu. Jika jam sebuah ponsel cepat semenit, kodenya semenit di depan kode server. Untuk itulah jendela drift: memverifikasi kode terhadap langkah di kedua sisi sekarang mengatakan bukan hanya apakah ia cocok tetapi seberapa jauh jam menyimpang.

RFC 6238 menyarankan jendela validasi paling banyak satu langkah di tiap sisi — cukup untuk menyerap penyimpangan jam biasa dan lomba di saat pergantian, tanpa memperlebar ruang tebakan lebih dari perlunya. Alat ini memakai ±1 secara default dan membiarkan Anda memperlebarnya saat men-debug.

Rahasia, Base32, dan otpauth:// URI

Rahasia dibagi sekali, saat penyiapan, dan segala sesuatu setelahnya diturunkan darinya. Aplikasi autentikator mengodekannya dalam Base32 (RFC 4648) — alfabet A–Z dan 2–7, yang menghindari karakter yang mudah keliru dibaca dan bertahan dicetak di bawah sebuah QR. Alat ini membaca Base32 secara default, mengabaikan spasi yang ditambahkan aplikasi untuk keterbacaan dan besar-kecil huruf, dan juga menerima hex agar Anda bisa mereproduksi vektor uji RFC 6238, yang rahasianya diberikan sebagai bita mentah.

Kode QR yang Anda pindai saat penyiapan juga bukan sihir: ia mengodekan sebuah otpauth:// URI teks-polos yang membawa rahasia dan semua parameter. Tempel satu di sini untuk mengisi bidang, atau bangun satu dari bidang untuk memindahkan sebuah penyiapan antar aplikasi:

otpauth://totp/GitHub:[email protected]?secret=JBSWY3DPEHPK3PXP&issuer=GitHub&algorithm=SHA1&digits=6&period=30

Hanya tipe totp yang diterima. Sebuah otpauth://hotp URI membawa penghitung alih-alih periode, dan memperlakukannya sebagai TOTP akan diam-diam menghasilkan kode yang salah — jadi ia ditolak alih-alih ditebak.

Algoritme, digit, dan periode

RFC 6238 mengizinkan HMAC-SHA-1, SHA-256, atau SHA-512, enam sampai delapan digit, dan panjang langkah apa pun. Dalam praktik dunia mengendap pada SHA-1, enam digit, dan tiga puluh detik, dan kebanyakan aplikasi hanya mengimplementasikan kombinasi itu — jadi server yang memilih hal lain harus berharap aplikasi pengguna mengikuti, dan banyak yang tidak. Pilihan yang aman untuk saling-operasi adalah yang membosankan.

Layak membahas soal SHA-1 secara langsung, karena alat hash di situs ini menandai SHA-1 sebagai rusak. Kedua pernyataan itu benar. SHA-1 tak terpakai untuk tanda tangan digital karena penyerang bisa membuat tumbukan — dua dokumen dengan hash yang sama. TOTP tak bergantung pada sifat itu: keamanannya datang dari kunci rahasia di dalam HMAC, bukan dari ketahanan hash terhadap tumbukan, dan HMAC-SHA-1 tetap kukuh. Memakai SHA-256 di sini bisa dibela tetapi memberi sedikit, dan menelan saling-operasi dengan aplikasi yang hanya melakukan SHA-1.

Apa yang dilindungi dan tak dilindungi alat ini

Semua di sini berjalan di browser Anda. HMAC dihitung dengan Web Crypto API di perangkat Anda sendiri — primitif yang sama yang dipakai alat hash dan HMAC — dan tak ada yang Anda ketik — rahasia, kode, atau otpauth URI — diunggah, disimpan, atau dicatat. Itu adalah sifat dari kode yang berada di sisi klien, bukan janji yang harus Anda percayai.

Meski begitu, sebuah rahasia TOTP adalah faktor kedua: siapa pun yang memilikinya bisa menghasilkan kode Anda. Menempel rahasia produksi ke halaman web mana pun — termasuk ini — menaruhnya di papan-klip dan mungkin di riwayat browser, jadi perlakukan dengan kehati-hatian yang sama seperti kata sandi, dan lebih baik pakai rahasia sekali-pakai atau uji ketika Anda hanya perlu memahami mekanismenya. Alat ini ada untuk men-debug dan belajar, bukan untuk menjadi tempat faktor kedua asli Anda tinggal.