Encoding, hashing, dan enkripsi adalah tiga hal berbeda
Hampir setiap salah paham di halaman ini berasal dari anggapan bahwa ketiganya bisa saling menggantikan, jadi ketiganya perlu dipisahkan dengan benar.
Encoding bisa dibalik dan tidak mengandung rahasia. Base64 ada untuk membawa data biner melalui saluran yang hanya menerima teks — lampiran email, data URI, string JSON — dengan menyatakan setiap tiga byte sebagai empat karakter, itulah sebabnya hasilnya selalu sekitar sepertiga lebih besar. Tidak ada kunci. Siapa pun yang melihat string-nya bisa men-decode-nya dalam satu langkah, termasuk di situs ini. Base64 bukan keamanan, bukan penyamaran yang layak disebut begitu, dan bukan cara menyembunyikan apa pun dari orang yang mau melihat. Percent-encoding adalah hal serupa untuk URL, dan di situlah bug umum lainnya berada: meng-encode satu nilai yang masuk ke query string adalah operasi yang berbeda dari merapikan seluruh URL yang sudah tersusun, karena hanya yang pertama yang meng-escape &, =, ? dan / yang membentuk struktur URL. Jika salah, “Smith & Sons” tiba di server sebagai dua parameter, bukan satu nilai.
Hashing bersifat satu arah dan juga tidak punya kunci. Hash mengambil input apa pun dan menghasilkan sidik jari dengan panjang tetap, dan tidak bisa dibatalkan — bukan karena dienkripsi, tetapi karena informasinya sudah hilang. Yang bisa dilakukan adalah menebak input lalu membandingkan, dan justru itulah yang membuat MD5, SHA-1, dan SHA-256 tidak tepat untuk menyimpan kata sandi: semuanya cepat, kartu grafis bisa menghitung miliaran per detik, dan tabel hash yang dicuri dibobol dengan kecepatan itu. Kata sandi butuh fungsi bersalt yang sengaja dibuat lambat — bcrypt, scrypt, atau Argon2. Terpisah dari itu, MD5 dan SHA-1 jebol karena alasan lain: dua file berbeda dengan hash yang sama kini bisa dibuat dengan sengaja, jadi keduanya tidak bisa membuktikan bahwa sebuah file adalah file yang Anda harapkan, meski keduanya tetap cocok untuk mendeteksi unduhan yang rusak secara tidak sengaja.
Enkripsi adalah satu-satunya yang punya kunci, dan tidak ada alat di sini yang melakukannya. Itu bukan kelalaian. Enkripsi yang benar membutuhkan manajemen kunci, dan halaman web adalah tempat yang salah untuk sebuah kunci.
JWT ditandatangani, bukan dienkripsi, dan ini terus-menerus menjebak orang. Header dan payload token adalah Base64URL — bisa dibaca siapa pun yang memegang token, tanpa perlu kunci. Tanda tangan mencegah orang mengubah token; tanda tangan tidak mencegah orang membacanya, jadi tidak ada informasi rahasia yang boleh ada di payload. Artinya, men-decode token sama sekali tidak membuktikan apa pun tentang token itu: siapa pun bisa menulis klaim apa saja lalu meng-encode-nya ke Base64. Verifikasi berarti menghitung ulang tanda tangan dengan kunci penerbit, sesuatu yang dilakukan server Anda dan tidak boleh diminta oleh situs web mana pun. Karena itu decoder kami menolak memberi kesan bahwa token sudah diverifikasi, dan menandai pola yang menunjukkan masalah — token kedaluwarsa, token tanpa masa berlaku sama sekali, dan algoritma “none”, yang merupakan celah bypass autentikasi yang terdokumentasi, bukan sekadar keanehan.
JSON punya batas presisi angka yang diam-diam dilanggar sebagian besar formatter. JSON sendiri tidak membatasi ukuran angka, tetapi angka JavaScript adalah float 64-bit, jadi bilangan bulat hanya tetap persis sampai 9.007.199.254.740.991. ID postingan Twitter, snowflake Discord, kunci database 64-bit, atau nomor rekening bank lebih besar dari itu, dan memprosesnya lewat formatter satu baris yang biasa — parse, lalu stringify — mengubah digit terakhirnya. Hasilnya tetap terlihat seperti angka yang masuk akal, dan itulah yang membuatnya berbahaya: 7205759403792793600 diam-diam berubah menjadi 7205759403792793000. Alat JSON kami menulis ulang digit persis yang Anda tempel dan memberi tahu berapa banyak angka yang harus dilindungi.
Versi UUID menjelaskan cara pembuatannya, bukan apa yang dijaminnya. Tidak ada yang mendaftarkan UUID atau memaksakan keunikannya; keunikannya bersifat probabilistik, dan versinya memberi tahu dari mana bit-bitnya berasal. Versi 4 berisi 122 bit acak dari generator kriptografis browser, sehingga tidak bisa ditebak dan karenanya tepat untuk link reset, kode undangan, dan apa pun yang rahasia — tetapi tidak tepat sebagai kunci database, karena kunci acak tersebar di indeks yang terurut dan memecah-mecahnya. Versi 7 menaruh timestamp milidetik 48-bit di depan, sehingga kunci ditambahkan di akhir indeks seperti integer auto-increment sambil tetap unik secara global. Konsekuensinya, UUID v7 terang-terangan menunjukkan kapan dibuat, sampai milidetiknya, kepada siapa pun yang memegangnya.
Kapan browser memang bukan alat yang tepat
Tidak satu pun dari tiga belas alat ini mengirim apa pun ke mana pun. Tidak ada permintaan yang dikirim, tidak ada yang dicatat, dan halaman tetap berfungsi saat jaringan diputus — itulah sebabnya alat-alat ini bisa dipakai untuk respons API penuh data pelanggan atau token yang tidak akan Anda kirim lewat email ke siapa pun. Itu alasan jujur untuk memakainya. Berikut alasan jujur untuk tidak memakainya.
Menempel rahasia production yang masih aktif ke halaman web adalah kebiasaan yang sebaiknya dihindari — termasuk halaman ini. Klaim privasi kami benar, tetapi yang melindungi Anda bukan klaim, melainkan perilaku kodenya, dan satu-satunya sikap yang masuk akal terhadap halaman web mana pun adalah memeriksa, bukan percaya. Pemeriksaannya tidak memakan biaya: putus koneksi internet setelah halaman dimuat dan lihat alat-alat ini tetap bekerja. Alat yang butuh server akan berhenti. Dan jika kredensial masih berlaku dan sudah Anda tempel di tempat yang tidak bisa Anda audit, langkah yang tepat adalah menggantinya, bukan menimbang-nimbang risikonya. Untuk token yang sedang aktif, men-decode-nya secara lokal — dengan fungsi Base64 bawaan bahasa pemrograman Anda, atau dua baris di shell — adalah praktik yang lebih baik daripada situs web mana pun, termasuk situs kami.
Validasi skema. Alat JSON dan XML kami memeriksa apakah dokumen well-formed, dan itu pertanyaan yang berbeda dari apakah dokumen sesuai dengan skema. Validasi terhadap JSON Schema atau XSD berarti mengambil dan menerapkan file skema, yaitu request jaringan yang sengaja tidak pernah dibuat halaman-halaman ini. Gunakan ajv untuk JSON Schema dan xmllint untuk XSD dan DTD; keduanya gratis dan keduanya lebih baik untuk itu daripada halaman web mana pun.
Apa pun yang benar-benar besar, atau yang di-stream. Dokumen disimpan utuh di memori, kadang dua kali selama pemformatan, jadi batasnya adalah tab. Beberapa megabyte langsung selesai, beberapa ratus tidak. jq bisa men-stream file JSON berukuran beberapa gigabyte yang tidak akan bisa dibuka browser mana pun, dan ripgrep mencari di seluruh repositori lebih cepat daripada Anda menempel satu file. Hashing punya versi yang lebih ketat dari batasan yang sama: kriptografi browser tidak punya digest bertahap, jadi seluruh file harus muat di memori sekaligus — image DVD akan gagal, sementara sha256sum, shasum, atau certutil men-stream-nya tanpa kendala.
Otomatisasi dan CI. Alat-alat ini berjalan saat seseorang mengeklik. Memformat setiap file di repositori, membuat sepuluh ribu UUID untuk fixture, atau memeriksa JSON di pipeline adalah tugas skrip: jq, xmllint, uuidgen, openssl, dan perintah base64 sudah terpasang di sebagian besar komputer.
Memverifikasi apa pun yang ditandatangani. Verifikasi tanda tangan, rantai sertifikat, dan apa pun yang membutuhkan private key sebaiknya dilakukan di server Anda dengan library yang terawat. Halaman ini akan memberi tahu apa yang diklaim sebuah token; halaman ini tidak akan pernah menyatakan bahwa token itu asli, dan Anda sebaiknya tidak memercayai situs mana pun yang mengaku bisa melakukannya tanpa kunci Anda.
Memilih di antara alat yang namanya mirip
Formatter JSON vs Validator JSON. Parser yang sama, pertanyaan berbeda. Formatter untuk membaca dan membentuk ulang dokumen yang sudah bisa diurai — beri indentasi, minify, jaga angka besar tetap utuh. Validator untuk dokumen yang tidak bisa diurai, dan hasilnya adalah baris, kolom, karakter bermasalah dengan tanda caret di bawahnya, serta penyebabnya dari empat penyebab umum. Jika Anda sedang menatap “Unexpected token”, yang Anda butuhkan adalah validator. Pembagian yang sama berlaku untuk Formatter XML dan Validator XML.
Decode Base64 vs Decoder JWT. JWT terdiri dari tiga bagian Base64URL, jadi decoder umum akan menampilkan potongan-potongannya. Halaman JWT memisahkannya untuk Anda, memformat JSON-nya, mengubah klaim expiry, issued-at, dan not-before dari timestamp Unix menjadi tanggal sungguhan di zona waktu Anda, memberi label pada klaim terdaftar, dan memperingatkan soal masa berlaku serta algoritma “none”. Gunakan decoder umum untuk blob Base64 dan halaman JWT untuk token.
Encode Base64 vs Encode URL. Pekerjaan berbeda yang sama-sama menghasilkan teks “aman”. Base64 mengubah byte apa pun menjadi teks dengan biaya ukuran 33 persen, dan Base64 standar sama sekali tidak aman di URL — tanda +, / dan = semuanya punya arti di sana, itulah sebabnya Base64URL ada. Percent-encoding membiarkan teks yang terbaca tetap terbaca dan hanya meng-escape yang akan merusak URL, dan itulah yang Anda perlukan untuk kata kunci pencarian, alamat email, atau target redirect. Meng-encode seluruh file untuk query string biasanya pertanda bahwa file itu seharusnya dikirim sebagai request body.
Generator Hash vs Generator UUID. Hash diturunkan dari inputnya, jadi input yang sama selalu menghasilkan nilai yang sama — itulah yang membuatnya menjadi sidik jari, cocok untuk memverifikasi unduhan atau menghapus duplikat konten yang identik. UUID adalah keacakan baru yang tidak berhubungan dengan apa pun, jadi tidak pernah berulang. Jika Anda ingin identifier yang sama untuk konten yang sama, buat hash-nya. Jika Anda ingin identifier baru, buat UUID.
Buat QR Code vs Buat Barcode. QR adalah kisi dua dimensi yang menampung teks apa pun — URL, kredensial Wi-Fi, nomor telepon — dan dibaca oleh kamera ponsel. Halaman barcode membuat kode satu dimensi untuk ritel dan logistik: EAN-13, EAN-8, UPC-A, ITF-14, Code 128, dan Code 39, dengan check digit ritel yang dihitung otomatis, serta nomor yang salah atau terlalu pendek ditolak alih-alih diam-diam ditambal menjadi barcode valid untuk produk lain.