Karakter Alfanumerik: Definisi, Penggunaan Kriptografi, Keamanan

Enam puluh dua. Itulah jumlah total simbol berbeda yang tersedia ketika seseorang mengatakan "gunakan hanya karakter alfanumerik." Dua puluh enam huruf besar, dua puluh enam huruf kecil, sepuluh angka. Hilangkan sensitivitas huruf besar/kecil dan jumlahnya turun menjadi tiga puluh enam. Kedua angka tersebut penting, karena hampir setiap pengenal digital yang pernah Anda ketik — alamat dompet, kata sandi Wi-Fi, hash transaksi, token GitHub — dibangun dari subset terpilih dari enam puluh dua simbol tersebut.

Pemilihan subset mana yang akan digunakan, dan alasannya, adalah bagian yang paling sering dilewati oleh para penjelas. Bagian ini juga yang menghubungkan definisi ensiklopedia dari karakter alfanumerik dengan keamanan praktis dompet kripto Anda. Artikel ini membahas penghitungan tersebut, standar di baliknya, cara kriptografi modern memilih subsetnya, dan apa yang dikatakan otoritas nasional AS tentang kata sandi saat ini. Beberapa panduan tersebut telah berubah dengan cara yang belum diikuti oleh sebagian besar saran keamanan.

Apa Itu Karakter Alfanumerik? Definisi dan Jumlahnya

Mari kita mulai dengan definisinya. Karakter alfanumerik adalah huruf apa pun dari A–Z (huruf besar maupun kecil) atau angka desimal apa pun dari 0–9. Hanya itu saja. Dari situ, perhitungannya jelas — dua puluh enam huruf per huruf besar ditambah sepuluh angka menghasilkan enam puluh dua karakter berbeda dengan sensitivitas huruf besar/kecil, dan tiga puluh enam tanpa sensitivitas huruf besar/kecil. Apa pun selain itu adalah "khusus". Tanda baca, spasi, simbol matematika, huruf beraksen, emoji — tidak satu pun dari itu termasuk alfanumerik.

Para insinyur biasanya memenuhi definisi tersebut melalui salah satu dari dua cara singkat. Alat POSIX seperti grep, sed, dan awk mengenali `[:alnum:]`, yang sesuai dengan enam puluh dua karakter di atas. Sebagian besar varian regex modern — Python, JavaScript, Java, PCRE — menggunakan `\w` sebagai gantinya. Masalahnya dengan `\w` adalah ia menyisipkan garis bawah. Garis bawah secara formal bukanlah alfanumerik. Sebagian besar sintaks pemrograman memperlakukannya sebagai simbol kehormatan, itulah sebabnya awalan kunci Stripe `sk_live_` dan awalan kunci AWS `AKIA` mencampur garis bawah dan huruf besar dengan angka tanpa ada yang mempermasalahkannya.

Dari mana istilah itu berasal? Dari kartu berlubang, sungguh tak terduga. Peralatan tabulasi IBM pada tahun 1930-an membutuhkan satu kata untuk kode yang mencampur huruf dengan angka, dan "alfanumerik" pun melekat. Pada IBM 1401 di awal tahun 1960-an, kata tersebut menjadi kosakata standar dalam komputasi bisnis. Perbedaan ini memiliki kekuatan dalam praktiknya — sebuah kolom yang dinyatakan "alfanumerik" menerima huruf atau angka apa pun; kolom khusus angka menolak alfabet sepenuhnya. Dari sana, kata tersebut menyebar ke plat nomor kendaraan, kode bank IBAN, mnemonik keypad telepon, SKU produk, dan ratusan tempat lainnya.

Perbedaan antara peka huruf besar dan kecil serta tidak peka huruf besar dan kecil lebih penting daripada yang terlihat. Entropi kata sandi berlipat ganda ketika huruf besar diperbolehkan. Alamat Base58 Bitcoin sengaja mempertahankan kedua huruf besar dan kecil. Bech32 sengaja mengabaikan huruf besar dan kecil. Setiap pilihan tersebut merupakan pertimbangan antara ekspresivitas dan kesalahan manusia. Jika salah pilih, orang akan kehilangan uang karena kesalahan pengetikan.

Dari ASCII ke Unicode: Sejarah Teknis Singkat

Istilah "alfanumerik" saat ini adalah hasil dari perang standar yang berlangsung selama enam puluh tahun. Sebagian besar pengguna terjebak di tengah-tengah dan tidak pernah menyadarinya.

ASCII muncul lebih dulu. ASCII dirilis pada tahun 1963, atas prakarsa American Standards Association, dan diformalkan lima tahun kemudian sebagai ANSI X3.4-1968. Dua revisi menyusul — satu pada tahun 1977, dan yang lainnya pada tahun 1986. Versi 1968 menetapkan huruf kapital A pada angka 65, huruf kecil a pada angka 97, dan angka 0–9 pada angka 48 hingga 57. Buka editor Anda sekarang: byte 'A' masih 65. Tidak ada yang berubah selama enam puluh tahun.

Selama kurang lebih empat dekade, set alfanumerik ASCII adalah set alfanumerik yang ada. Kemudian muncullah web global. Tujuh bit tidak lagi cukup. Mode kegagalannya sangat buruk. Email yang kacau. Basis data yang rusak. Situs web Jepang yang berfungsi sempurna di Tokyo dan tampak seperti dinding tanda tanya di laptop AS. Unicode hadir pada tahun 1991 dengan ambisi yang luar biasa: menetapkan nomor unik untuk setiap karakter dalam setiap aksara yang pernah ditulis siapa pun. UTF-8 menyusul pada tahun 1992 sebagai pengkodean yang benar-benar membawa Unicode melalui jaringan biasa. Triknya adalah kompatibilitas mundur — 128 titik kode pertama UTF-8 adalah 1968 byte ASCII asli, tepatnya. Teks bahasa Inggris yang dikirim sebelum tahun 1991 terus berfungsi selamanya.

Perubahan tersebut terjadi pada Desember 2007. Pada bulan itu, statistik penelusuran web publik akhirnya menunjukkan UTF-8 mengungguli ASCII sebagai pengkodean yang paling umum digunakan secara online. Sejak saat itu, istilah "alfanumerik" tidak lagi secara ketat berarti enam puluh dua simbol ASCII. Unicode sekarang mengkatalogkan blok alfanumerik untuk aksara Kiril, Yunani, Arab, Ibrani, dan CJK. Setiap aksara memiliki huruf dan angka tersendiri.

Namun, dalam praktiknya, perangkat lunak yang harus melintasi batas negara masih menggunakan subset ASCII asli secara default. Huruf Latin A–Z. Angka Arab 0–9. Tidak ada yang lain. Alasannya sederhana. Setiap keyboard menghasilkan ASCII. Setiap basis data menerimanya. Setiap mesin regex mengetahuinya. Melangkah keluar dari rentang tersebut, Anda akan menghadapi serangkaian bug pengkodean yang salah, karakter yang mirip, dan serangan phishing yang akan saya bahas di bawah ini.

Karakter Alfanumerik dalam Kriptografi: Alamat, Hash, dan Seed

Inilah bagian yang paling sering dilewati oleh penjelasan umum. Sistem mata uang kripto tidak pernah menggunakan seluruh rangkaian alfanumerik 62 karakter. Mereka memilih subset yang dipilih dengan cermat. Masing-masing merupakan kompromi rekayasa yang terdokumentasi, bukan estetika yang sembarangan.

Mari kita mulai dengan Bitcoin. Alamat Bitcoin lama (yang dimulai dengan 1 atau 3) dikodekan dalam Base58. Alfabet tersebut dirancang oleh Satoshi Nakamoto secara manual. Resepnya: ambil enam puluh dua karakter alfanumerik, hapus empat anggotanya. Hilangkan angka nol, huruf O kapital, huruf I kapital, dan huruf l kecil. Mengapa keempat karakter itu? Tuliskan di Post-it dengan tulisan tangan yang buruk. Pergi. Kembali lagi dalam lima menit. Cobalah untuk membedakannya. Anda tidak bisa. Itulah seluruh masalah yang ingin dipecahkan oleh Base58. Lima puluh delapan karakter tersisa. Alamat lama yang khas akhirnya memiliki panjang dua puluh enam hingga tiga puluh lima simbol — cukup pendek untuk disalin secara manual jika memang perlu.

SegWit diaktifkan pada Agustus 2017. Bersamanya muncul format alamat Bitcoin kedua: Bech32, yang didefinisikan dalam BIP-173. Bech32 menawarkan pendekatan yang berbeda. Sensitivitas huruf besar/kecil dihilangkan sepenuhnya — setiap alamat menggunakan huruf kecil. Empat karakter berbeda dihilangkan: angka 1, ditambah b, i, o. Tiga puluh dua huruf dan angka yang tersisa membawa checksum bawaan. Checksum tersebut secara otomatis mendeteksi hampir semua kesalahan ketik karakter tunggal. Taproot, yang aktif sejak November 2021, menyempurnakan format tersebut menjadi Bech32m (BIP-350) setelah para peneliti menemukan kelemahan khusus dalam perhitungan aslinya.

Ethereum memilih jalur ketiga. Cukup gunakan heksadesimal. Alamat Ethereum adalah `0x` diikuti oleh tepat empat puluh karakter heksadesimal; total empat puluh dua karakter. Heksadesimal mempersempit alfanumerik hingga enam belas anggota. Angka 0–9, huruf a–f, tidak ada yang lain. Pilihan ini terasa bersih pada tahun 2015. Namun, pada tahun 2026, setelah bertahun-tahun pengguna harus memicingkan mata pada gumpalan heksadesimal mentah di MetaMask, tampilannya menjadi buruk. EIP-55 adalah solusinya. Secara selektif mengubah huruf-huruf tertentu menjadi huruf besar dalam pola yang berasal dari hash Keccak-256 dari alamat huruf kecil. Hasilnya adalah deteksi kesalahan ketik yang gratis. EIP-55 mendeteksi kesalahan ketik dengan keandalan sekitar 99,975 persen. Tingkat kesalahannya sekitar 0,0247 persen. Kecil. Bukan nol.

Hash adalah contoh paling sederhana. Output hash SHA-256 adalah 256 bit, ditampilkan sebagai 64 karakter heksadesimal. Keccak-256 Ethereum menghasilkan output dengan panjang yang identik. ID transaksi Bitcoin — txid — adalah hash SHA-256 dari transaksi itu sendiri, jadi txid juga terdiri dari 64 karakter heksadesimal alfanumerik. Meskipun terlihat rumit di penjelajah blok, txid murni alfanumerik.

Frasa kunci (seed phrase) memecah pola tersebut. Pemulihan dompet BIP-39 adalah satu-satunya tempat di mana kripto melangkah keluar dari wilayah alfanumerik dan kembali ke wilayah alfabet murni. Standar ini mengkodekan 128 atau 256 bit entropi sebagai dua belas atau dua puluh empat kata bahasa Inggris yang diambil dari daftar tetap berisi 2.048 kata. Setiap kata hanya terdiri dari huruf kecil — tanpa angka, tanpa huruf campuran. Mengapa? Karena target desainnya adalah seseorang yang menulis kata-kata di atas kertas pada pukul 3 pagi setelah ponsel mereka mati, dan angka menimbulkan ambiguitas yang tidak ditimbulkan oleh huruf.

Setiap subset adalah bagian dari desain yang berpusat pada manusia yang tersembunyi di dalam sistem yang sangat teknis.

Kata Sandi Alfanumerik: Apa yang Sebenarnya Dikatakan NIST pada Tahun 2024

Sebagian besar saran kata sandi di web publik sudah ketinggalan zaman selama beberapa tahun. Gunakan huruf besar dan kecil, tambahkan angka, sertakan setidaknya satu karakter khusus, ubah setiap sembilan puluh hari — aturan-aturan itu menjadi patokan selama dua dekade. Institut Standar dan Teknologi Nasional Amerika Serikat secara resmi meninggalkan aturan-aturan tersebut.

Publikasi Khusus NIST 800-63B, otoritas federal tentang panduan identitas digital, menyelesaikan Revisi 4 pada September 2024. Panduan baru ini sangat mencolok karena banyak hal yang dihilangkan. Rekomendasi panjang minimum dinaikkan menjadi lima belas karakter untuk otentikasi satu faktor. Instruksi tentang aturan komposisi karakter dirumuskan sebagai "tidak boleh": layanan tidak boleh mensyaratkan kelas karakter tertentu. Masa berlaku kata sandi berkala, rotasi sembilan puluh hari yang dibenci semua orang, juga dihapus. Sebagai gantinya, NIST sekarang mewajibkan layanan untuk memeriksa kata sandi yang dikirimkan terhadap daftar blokir kredensial yang diketahui telah disusupi.

Pergeseran ini dibenarkan oleh perhitungan entropi. Kumpulan alfanumerik 62 karakter menghasilkan sekitar 5,95 bit per karakter. Kumpulan ASCII yang dapat dicetak sebanyak 95 karakter — alfanumerik ditambah karakter khusus — menghasilkan 6,57 bit. Menambahkan seluruh rangkaian karakter khusus menghasilkan 0,62 bit per karakter. Menambahkan satu karakter lagi dengan panjang tertentu menghasilkan total 5,95 bit. Panjang karakter jauh lebih dominan daripada kompleksitasnya.

Laporan Investigasi Pelanggaran Data Verizon tahun 2025 menemukan bahwa kredensial merupakan 22 persen dari semua titik masuk pelanggaran yang terkonfirmasi. Pencurian kredensial (credential stuffing) — penggunaan kembali daftar kata sandi yang bocor secara otomatis — terjadi pada 19 persen dari upaya otentikasi rata-rata, dan mencapai puncaknya pada 44 persen. Empat puluh sembilan persen pengguna menggunakan kembali kata sandi di berbagai layanan. Tak satu pun dari masalah tersebut terselesaikan dengan mewajibkan penggunaan huruf kapital.

Kata sandi alfanumerik yang lebih panjang tanpa karakter khusus lebih sulit diretas daripada kata sandi pendek yang disusun untuk memenuhi daftar periksa kompleksitas. Jika bank Anda masih memaksa Anda untuk membuat kata sandi dua belas karakter dengan satu huruf besar, satu angka, dan satu karakter khusus, kebijakan tersebut sekarang secara resmi tidak sesuai dengan standar federal AS.

Di Mana Lagi Karakter Alfanumerik Muncul

Di luar ranah kriptografi, kata sandi dan rangkaian alfanumerik tetap muncul di mana pun suatu sistem membutuhkan pengidentifikasi yang dapat diketik manusia dan diuraikan komputer tanpa ambiguitas.

Kode bank adalah contoh yang mudah. IBAN dapat terdiri hingga tiga puluh empat karakter alfanumerik dan selalu diawali dengan kode negara ISO dua huruf. Kode SWIFT/BIC terdiri dari delapan atau sebelas karakter. Plat nomor bervariasi menurut negara — plat nomor Inggris sangat berbeda dengan plat nomor Jerman — tetapi keduanya merupakan subset alfanumerik dari kumpulan enam puluh dua simbol yang sama. Nomor Identifikasi Kendaraan (VIN) terdiri tepat tujuh belas karakter di seluruh dunia, dan VIN sengaja melarang huruf I, O, dan Q agar tetap berbeda secara visual dari angka.

Kunci API adalah contoh sehari-hari yang jarang diperhatikan oleh sebagian besar pengguna. Kunci Stripe live key dimulai dengan `sk_live_` ditambah token alfanumerik. Kunci akses AWS dimulai dengan `AKIA` ditambah enam belas karakter alfanumerik. Token akses pribadi GitHub yang diterbitkan setelah tahun 2021 dimulai dengan `ghp_`. Awalan tersebut sendiri merupakan alfanumerik, dipilih agar penyedia dapat memindai repositori publik dan log untuk mencari kunci yang bocor. Dalam banyak kasus, pemindaian tersebut mendeteksi kebocoran sebelum penyerang melakukannya.

Kode QR layak disebutkan secara singkat. Standar ISO/IEC 18004 mendefinisikan "mode alfanumerik" khusus yang mengkodekan 45 karakter tertentu — huruf besar, angka, spasi, dan beberapa tanda baca — lebih efisien daripada mode byte umum. Kode QR yang hanya berisi konten alfanumerik huruf besar menyimpan sekitar 1,6 kali lebih banyak data per kotak daripada konten yang sama yang dikodekan sebagai byte mentah.

Basis32, Basis58, Basis64: Kapan Kriptografi Memilih Subset

Terdapat sejumlah standar pengkodean yang secara khusus memetakan biner ke dalam subset alfanumerik. Referensinya adalah RFC 4648, yang diterbitkan oleh IETF pada tahun 2006. RFC ini mendefinisikan tiga pengkodean.

Hex adalah yang paling sederhana di antara semuanya. Secara resmi disebut Base16. Terdiri dari enam belas karakter: 0–9, a–f. Digunakan untuk alamat Ethereum, hash kriptografi, dan hampir semua debugging tingkat rendah di mana Anda perlu membaca byte mentah. Base32 adalah yang lebih menarik. Alfabet 32 karakter dipilih agar tidak peka terhadap huruf besar/kecil dan, dalam beberapa varian, untuk menghilangkan angka 0, 1, 8, dan 9 yang secara visual membingungkan. Siapa pun yang telah mengatur otentikasi dua faktor dan mengetikkan rahasia ke Google Authenticator telah mengetikkan Base32 — sebagian besar waktu tanpa menyadarinya.

Base64 adalah tulang punggung dari semua ini. Terdiri dari enam puluh dua karakter alfanumerik ditambah dua simbol `+` dan `/`. Varian yang aman untuk URL mengganti simbol-simbol tersebut dengan `-` dan `_`. Base64 digunakan untuk membawa lampiran email Anda, mengkodekan URL data di dalam HTML, dan mengemas JSON Web Token untuk OAuth.

Base58 Bitcoin berada di luar RFC 4648. Satoshi Nakamoto membangunnya secara independen. Targetnya berbeda — manusia mengetik ulang alamat, bukan efisiensi byte per karakter — dan hasilnya adalah alfabet khusus yang tidak digunakan orang lain. Base85, terkadang disebut Ascii85, berjalan ke arah yang berlawanan. Ia mengemas empat byte menjadi lima karakter dan muncul dalam file PDF dan PostScript, di mana kepadatan ekstra tersebut membenarkan hilangnya keterbacaan.

Kesalahan Umum: Kebingungan Visual dan Kemiripan

Alasan yang sama mengapa kriptografi memilih subset alfanumerik adalah alasan mengapa semua orang melakukan kesalahan. Sebagian besar masalah disebabkan oleh segelintir pasangan karakter.

Contoh klasik yang sering membingungkan: nol dan huruf O kapital. Angka satu, huruf l kecil, huruf I kapital. Huruf l kecil dan huruf I kapital. Bitcoin Base58 menghilangkan keempatnya karena alasan ini. Sistem lain menggunakan mitigasi yang berbeda — VIN menghilangkan I, O, dan Q, beberapa kode keuangan menghilangkan O sepenuhnya, dan Anda dapat menemukan aturan plat nomor nasional yang melarang huruf mana pun yang paling mirip dengan angka 0 dalam font negara tersebut.

Masalah yang lebih rumit dan lebih baru adalah serangan homograf Unicode. Ide ini didokumentasikan dalam makalah tahun 2001 oleh Evgeniy Gabrilovich dan Alex Gontmakher. Homograf menukar karakter yang secara visual identik dari aksara yang berbeda — misalnya, huruf Kiril 'а' (U+0430) dengan huruf Latin 'a' (U+0061). Daftarkan nama domain dengan substitusi tersebut dan Anda dapat menghosting halaman phishing yang tampak tidak dapat dibedakan dari bank yang sebenarnya. Browser modern menampilkan representasi Punycode mentah — sesuatu seperti `xn--80akhbyknj4f` — setiap kali domain mencampur aksara. Pertahanan itu menangkap sebagian besar serangan. Namun tidak semuanya.

Cara Membuat Kata Sandi Alfanumerik yang Kuat di 2026

Tiga aturan. Semuanya berasal langsung dari perhitungan matematika NIST.

Pertama: panjang lebih penting daripada kelas karakter. Usahakan agar panjangnya enam belas karakter atau lebih. Aturan ini berlaku terlepas dari apakah sistem hanya menerima huruf dan angka atau seluruh set ASCII yang dapat dicetak.

Kedua: jika Anda harus menghafalnya, gunakan frasa sandi. Empat kata acak dari daftar yang panjang — daftar Diceware adalah pilihan standar — jauh lebih aman daripada hampir semua kata sandi pendek yang dibuat manusia.

Ketiga: untuk hal lainnya, gunakan pengelola kata sandi. Biarkan pengelola menghasilkan rangkaian alfanumerik panjang yang tidak perlu Anda baca atau ketik secara manual. Setelah pengelola menangani output, keterbacaan output menjadi tidak penting lagi.

Referensi Cepat: Jumlah Alfanumerik dan Contohnya

Enam puluh dua dengan sensitivitas huruf besar/kecil. Tiga puluh enam tanpa sensitivitas huruf besar/kecil. Kode ASCII 48–57 untuk angka. 65–90 untuk huruf besar. 97–122 untuk huruf kecil. Cocokkan seluruh set dengan regex `[A-Za-z0-9]` atau kelas POSIX `[:alnum:]`. Kumpulan enam puluh dua simbol itulah yang mendasari hampir setiap pengenal digital yang akan Anda gunakan minggu ini. Kata sandi. Kunci API. IBAN. Plat nomor kendaraan. ID transaksi. Setiap alamat dompet yang Anda buat.

Mathis Curcio

Mathis Curcio is a senior content strategist and NFT specialist at Plisio. With over 5 years of experience in the Web3 space, Mathis focuses on the evolution of NFT ecosystems, digital collectibles, and decentralized ownership models. He creates accessible, insight-driven content that bridges the gap between blockchain innovation and mainstream adoption. His expertise spans NFT market trends, use cases across art and gaming, and the infrastructure powering next-generation tokenized assets.