⏱️ Kriptografi & Protokol RFC ✓ Analisis Standar IETF

Penjelasan TOTP vs HOTP: Perbedaan Utama, Keamanan & Prinsip Kerja

Jutaan pengembang dan insinyur keamanan melihat kode verifikasi 6 digit bergulir setiap hari, tetapi sedikit yang memahami mekanisme matematika elegan yang beroperasi di balik layar. Dari counter berbasis peristiwa RFC 4226 (HOTP) pada tahun 2005 hingga langkah waktu diskrit RFC 6238 (TOTP) pada tahun 2011, panduan ini menguraikan algoritma Dynamic Truncation tingkat bita, kerentanan desinkronisasi counter, toleransi clock drift, dan mengapa TOTP berhasil menaklukkan web modern.

2FA
Tim Rekayasa Keamanan 2FA-Tool
Diperbarui Oktober 2026
Estimasi Waktu Baca: 14 menit (2.600+ kata)
RFC 6238 RFC 4226 Dynamic Truncation
💡 Poin Penting Kriptografi (TL;DR)
  • Perbedaan Input Mendasar: HOTP menghitung hash dari counter C yang bertambah secara monoton, sedangkan TOTP menggantikan C dengan langkah waktu epoch T (CurrentUnixTime / 30).
  • Pewarisan Langsung: Secara matematis TOTP merupakan spesialisasi dari HOTP: TOTP(K, Time) = HOTP(K, T). Kedua algoritma mengimplementasikan fungsi Dynamic Truncation yang sama persis.
  • Faktor Penentu Arsitektural: HOTP bersifat stateful (server wajib mengunci dan menyimpan counter ke disk pada setiap validasi). TOTP bersifat stateless, memungkinkan layanan mikro cloud modern memvalidasi token di seluruh klaster beban terdistribusi tanpa operasi penulisan basis data terpusat.
01

Akar Sejarah: Dari Token Perangkat Keras Kepemilikan (Proprietary) ke Standar Web Terbuka

Pada awal tahun 2000-an, autentikasi dua faktor di lingkungan korporat didominasi oleh perangkat token perangkat keras kepemilikan (proprietary hardware token) seperti RSA SecurID. Perangkat tertutup dan berbiaya mahal ini memuat osilator kristal kuarsa internal yang disinkronkan dengan server perusahaan proprietary. Jika suatu organisasi ingin menyediakan keamanan multi-faktor untuk ribuan karyawan, biaya pengadaan perangkat keras fisik dan lisensi proprietary sangatlah membebani.

Untuk membebaskan autentikasi dari vendor monopoli tertutup, konsorsium OATH (Initiative for Open Authentication) didirikan oleh para pemimpin industri guna menghasilkan standar terbuka IETF bebas royalti yang dapat diinspeksi, diimplementasikan, dan diaudit secara bebas oleh setiap insinyur perangkat lunak:

📜 2005: RFC 4226 (HOTP)

HMAC-Based One-Time Password Algorithm. Dirancang untuk mikrokontroler berdaya rendah dengan tombol tekan fisik. Menekan tombol akan menaikkan counter internal dan menampilkan token 6 digit pada layar LCD.

📜 2011: RFC 6238 (TOTP)

Time-Based One-Time Password Algorithm. Dirancang seiring dengan melonjaknya adopsi ponsel pintar (smartphone). Dengan memanfaatkan sinkronisasi waktu jaringan NTP seluler, TOTP sepenuhnya mengeliminasi ketidaksesuaian status tombol fisik.

02

Arsitektur HOTP (RFC 4226) & Mekanika Bita Dynamic Truncation

Definisi matematika inti dari HOTP sangat ringkas dan elegan:

HOTP(K, C) = Truncate(HMAC-SHA-1(K, C)) mod 10DigitCount

Rincian Parameter:

  • K: Kunci rahasia simetris bersama (biasanya urutan biner 160-bit / 20-byte hasil dekode Base32).
  • C: Counter integer big-endian 8-byte (64-bit).
  • HMAC-SHA-1: Keyed-hash message authentication code yang menghasilkan digest kriptografi 20-byte (160-bit).

🔍 Cara Dynamic Truncation (DT) Mengonversi 20 Byte Menjadi 6 Digit:

Digest HMAC-SHA1 memuat 160 bit (20 byte). Mengekstrak 6 digit desimal yang seragam membutuhkan mekanisme seleksi deterministik dan tahan terhadap kolisi seperti yang didefinisikan dalam Bagian 5.3 dari RFC 4226:

// Langkah 1: Hitung Offset Dinamis
Offset = HS[19] & 0x0F
Ambil byte terakhir (indeks 19) dari digest 20-byte. Operasi masking dengan 0x0F mengisolasi 4 bit orde rendah, menghasilkan bilangan bulat antara 0 dan 15 (0x0 hingga 0xF). Hal ini memastikan ekstraksi 4 byte berikutnya tidak pernah melebihi buffer 20 byte (karena 15 + 4 = 19).
// Langkah 2: Ekstrak 4 Byte Berurutan dengan Masking
P = ( (HS[Offset] & 0x7F) << 24 ) | ( (HS[Offset+1] & 0xFF) << 16 ) | ( (HS[Offset+2] & 0xFF) << 8 ) | ( HS[Offset+3] & 0xFF )
Ekstrak 4 byte mulai dari Offset. Masker 0x7F menolkan bit paling signifikan (MSB) untuk menghindari overflow integer bertanda pada berbagai arsitektur CPU (memastikan integer 31-bit positif yang bersih).
// Langkah 3: Aritmetika Modulo untuk Digit Akhir
OTP = P mod 106 = P mod 1000000
Menerapkan modulo 1.000.000 mengisolasi 6 digit desimal akhir, menambahkan awalan angka nol (leading zeroes) jika diperlukan (misalnya 748 menjadi "000748").
🧪 Vektor Uji Konkret dari RFC 4226 Lampiran D:

Misalkan kunci rahasia dalam ASCII adalah "12345678901234567890" dan Counter C = 0. Digest HMAC-SHA1 yang dihasilkan dalam heksadesimal adalah:

cc 93 cf 18 50 8d 94 93 4c 64 b6 6d 8b fb 87 fb 23 cb 4b 71

1. Byte terakhir adalah 0x71. 0x71 & 0x0F = 0x01, sehingga Offset = 1.
2. Byte 1 sampai 4 adalah: 93 cf 18 50. Menolkan MSB menghasilkan 0x13cf1850, yang dalam desimal sama dengan 332.339.280.
3. 332339280 mod 1000000 = 339280. OTP 6 digit yang dihasilkan adalah 339280!

03

Evolusi TOTP (RFC 6238): Keajaiban Langkah Waktu

HOTP membutuhkan sinkronisasi counter pada klien dengan server. Pada perangkat lunak, menghitung penekanan tombol atau aksi pengguna memicu kesalahan manusia yang terus-menerus.

RFC 6238 menggantikan counter C dengan langkah waktu diskrit T yang diturunkan langsung dari jam epoch Unix:

T = ⌊ (CurrentUnixTime - T0) / X ⌋
  • CurrentUnixTime: Detik yang telah berlalu sejak 1970-01-01 00:00:00 UTC.
  • T0: Referensi inisialisasi epoch (standar bernilai 0 di seluruh sistem modern).
  • X (Jendela Langkah Waktu / Time Step Window): Durasi standar yang direkomendasikan sebesar 30 detik.
  • Fungsi Floor ⌊ ⌋: Untuk setiap timestamp dalam jendela 30 detik, T tetap konstan (invarian). Misalnya, antara detik epoch 1728211200 dan 1728211229, nilai T menghasilkan integer 64-bit yang persis sama.

Serialisasi Biner: Setelah T dihitung, nilainya dikemas ke dalam buffer byte biner big-endian 8-byte (identik dalam struktur memori dengan counter C pada HOTP). Akibatnya, formula terpadu disederhanakan menjadi:
TOTP(K, Time) = HOTP(K, T) Keanggunan matematika ini menjelaskan mengapa aplikasi autentikator memperbarui token secara sinkron setiap 30 detik tanpa membutuhkan sinkronisasi status persisten.

Dukungan RFC 6238 untuk SHA-256 dan SHA-512: Meskipun RFC 4226 secara ketat mendefinisikan HMAC-SHA-1, RFC 6238 memperluas dukungan untuk HMAC-SHA-256 dan HMAC-SHA-512. Pada SHA-256 (digest 32-byte), offset diambil dari byte 31 (HS[31] & 0x0F); pada SHA-512 (digest 64-byte), offset diambil dari byte 63 (HS[63] & 0x0F). Namun, di 99,9% situs web komersial (Google, Microsoft, GitHub, AWS), SHA-1 tetap menjadi default yang dominan demi kompatibilitas klien seluler lawas.
04

Matriks Perbandingan Komprehensif (HOTP vs. TOTP)

Dimensi HOTP (RFC 4226) TOTP (RFC 6238)
Variabel Input Counter Peristiwa C (bertambah secara monoton) Langkah Waktu T (jendela epoch Unix 30 detik)
Masa Berlaku Token Tidak terbatas (valid hingga digunakan pada login berikutnya) Tepat 30 detik (kedaluwarsa otomatis)
Arsitektur Server Stateful (membutuhkan penulisan basis data atomik per login) Stateless (verifikasi independen berbasis NTP)
Paparan Serangan Replay Sedang (token yang dicegat tetap valid sampai digunakan) Minimal (terbatas pada sisa detik dalam jendela aktif saat ini)
Modus Kegagalan Utama Desinkronisasi Counter (penekanan tombol yang tidak disengaja) Clock Drift (pergeseran waktu pada ponsel klien)
Hash Kriptografi yang Didukung HMAC-SHA-1 eksklusif HMAC-SHA-1, HMAC-SHA-256, HMAC-SHA-512
Adopsi Industri Token perbankan lawas, gerbang fisik khusus 99,9% aplikasi autentikator web modern
05

Desinkronisasi vs. Time Drift: Solusi Rekayasa Teknis

Dalam lingkungan produksi terdistribusi, waktu antara klien dan server pasti mengalami pergeseran. Para pakar kriptografi merancang jendela kompensasi eksplisit untuk menjaga keandalan:

⚙️ Mitigasi HOTP: Look-Ahead Verification Window (s)

Jika pengguna menekan tombol token 5 kali tanpa mengirimkannya, counter klien mencapai C+5 sementara server tetap berada di C.
RFC 4226 menetapkan bahwa saat autentikasi berlangsung, server menghitung jendela look-ahead yang mencakup rentang [C+1, C+s] (biasanya s=20). Jika kecocokan ditemukan, server segera melompat maju dan menyinkronkan counter C secara langsung.

⏱️ Mitigasi TOTP: Toleransi Skew Waktu (Jendela ±1)

Akibat latensi jaringan atau clock drift perangkat klien (misalnya jam ponsel terlambat 10 detik), token dapat tiba di langkah waktu yang berdekatan.
Server produksi mengevaluasi larik 3 jendela: [T-1, T, T+1], yang secara efektif memperluas jendela penerimaan menjadi 90 detik.

Aturan Wajib Anti-Replay: Untuk mencegah serangan replay dalam jendela toleransi 90 detik, server harus menyimpan dalam cache dan mengunci token yang telah terpakai di memori (misalnya Redis) selama 90 detik, menolak pengiriman ulang yang duplikat.
🛡️ Perbandingan String Constant-Time (Pertahanan Serangan Timing):

Ketika server memverifikasi apakah kode yang dikirimkan pengguna cocok dengan kode yang dihitung, pemeriksaan kesetaraan string sederhana (seperti userOtp === serverOtp) berhenti pada karakter pertama yang tidak cocok. Penyerang yang mengukur waktu respons bolak-balik jaringan secara mikroskopis dapat merekonstruksi setiap digit secara bertahap. Backend kelas enterprise menerapkan perbandingan kesetaraan constant-time (misalnya crypto.timingSafeEqual di Node.js) guna menggagalkan analisis timing saluran samping (side-channel timing attacks).

06

Mengapa TOTP Menaklukkan Internet Modern

Kemenangan mutlak TOTP atas HOTP di seluruh lanskap web didorong oleh tiga keharusan arsitektur:

☁️ Skalabilitas Cloud Tanpa Status (Stateless)

Dalam arsitektur layanan mikro (microservices) multi-kawasan yang terdistribusi, setiap instans server dengan jam yang disinkronkan via NTP dapat memvalidasi token TOTP tanpa perlu melakukan kueri atau mengunci rekaman basis data terpusat.

📱 Sinergi Ekosistem Ponsel Cerdas

Ponsel pintar secara berkesinambungan mengkalibrasi jam sistemnya melalui menara BTS seluler dan GPS, meniadakan persoalan clock drift tanpa memerlukan perawatan perangkat keras fisik.

🛡️ Jendela Serangan Sempit 30 Detik

Token HOTP tetap valid tanpa batas waktu sampai digunakan. Sebaliknya, token TOTP kedaluwarsa dalam 30 detik, menetralkan log yang bocor dan intersepsi paket pasif secara otomatis.

🧮 Engine RFC 6238 Murni Sisi Klien

Rasakan Perhitungan TOTP Real-Time di 2FA-Tool

Saksikan bagaimana string rahasia Base32 Anda bertransformasi menjadi kode 6 digit dinamis melalui dynamic truncation HMAC-SHA1. 100% offline di browser Anda.

Buka Generator Online