Pembuat Password Massal Gratis

Buat beberapa kata sandi yang kuat sekaligus. Sesuaikan jumlah, panjang, dan karakter, lalu unduh sebagai file teks.

Kata sandi dibuat secara lokal di perangkat Anda
Klik "Buat kata sandi" untuk memulai

    Pembuatan kata sandi massal

    Alat ini menghasilkan beberapa kata sandi yang kuat secara kriptografi dalam satu operasi. Sempurna untuk menyiapkan daftar untuk onboarding tim, pembuatan akun massal, atau mengelola inventaris kata sandi. Setiap kata sandi diproduksi melalui generator acak bawaan browser.

    Tingkat kekuatan

    Pertanyaan umum

    Apakah kata sandi ini benar-benar acak?

    Ya. Kata sandi dibuat dengan window.crypto.getRandomValues(), yang menyediakan nilai acak yang aman secara kriptografi, cocok untuk penggunaan keamanan.

    Bisakah saya menghasilkan lebih dari 100 kata sandi?

    Alat membatasi pembuatan hingga 100 sekaligus untuk menghindari memperlambat browser. Hasilkan beberapa batch secara terpisah jika perlu.

    Bagaimana cara menyimpan file yang diunduh?

    Simpan file .txt di lokasi yang aman, sebaiknya yang dienkripsi. Jangan pernah commit ke repositori kode atau membagikannya melalui saluran yang tidak aman. Hapus setelah didistribusikan ke pengguna.

    Dari mana bilangan acak yang baik berasal

    Komputer, secara desain, bersifat deterministik. Dengan input yang sama dan kode yang sama, ia menghasilkan output yang sama setiap kali. Itulah tepatnya sifat yang Anda inginkan dari CPU yang menjalankan spreadsheet, dan tepatnya sifat yang tidak Anda inginkan dari generator kata sandi. Jika penyerang dapat mereproduksi urutan nilai yang dikeluarkan generator, mereka dapat mereproduksi setiap kata sandi yang pernah dikeluarkannya.

    Jadi generator mengumpulkan «entropi» (sinyal fisik yang tidak dapat diprediksi dari luar program) dan menggunakannya untuk menyemai algoritma yang disebut CSPRNG (Cryptographically Secure Pseudo-Random Number Generator). Kata «pseudo» itu jujur: bit dihasilkan oleh algoritma, bukan fisika. «Aman secara kriptografis» berarti bahkan penyerang yang melihat serangkaian panjang output masa lalu tidak dapat memprediksi byte berikutnya lebih baik dari kebetulan. Theodore Ts'o mengimplementasikan /dev/random di kernel Linux pada tahun 1994, dan macOS, BSD, Solaris, serta Windows (dengan BCryptGenRandom) semuanya mengadopsi antarmuka yang setara. Di baliknya, semuanya mencampur setiap sumber gangguan fisik yang memungkinkan (waktu pencarian disk, kedatangan paket jaringan, input keyboard dan mouse, interupsi perangkat keras, RDRAND pada CPU Intel yang memilikinya) melalui hash kriptografis, lalu terus-menerus menyemai ulang.

    Di browser, W3C Web Cryptography API mengekspos ini melalui window.crypto.getRandomValues(typedArray): berikan array bertipe, browser mengisinya dengan byte acak yang kuat secara kriptografis. Maksimum per panggilan adalah 65.536 byte (alat ini jauh di bawahnya). API ini telah didukung secara dasar di Chrome, Firefox, Safari, dan Edge sejak Juli 2015: tidak ada kemungkinan realistis pengguna menggunakan alat ini dengan browser yang tidak memilikinya.

    Entropi kata sandi, matematikanya

    Kekuatan «kata sandi,» dalam pengertian kriptografis formal, diukur dalam bit entropi. Formula standar untuk kata sandi yang dihasilkan secara acak adalah:

    Entropi = L × log₂(R)

    di mana L adalah panjang dalam karakter dan R adalah ukuran pool karakter. Entropi per karakter berdasarkan set karakter:

    Angka 94 layak diperincikan: kode ASCII 32 hingga 126 adalah karakter yang dapat dicetak (95 total); mengecualikan spasi menyisakan 94 glyph terlihat bukan spasi (26 huruf kecil + 26 huruf besar + 10 angka + 32 tanda baca/simbol). Memasukkan angka konkret ke dalam formula:

    Komunitas kriptografis telah menyepakati tiga ambang: 80 bit sebagai minimum dasar (batas rekomendasi NIST hingga 2014), dicapai pada ~13 karakter dengan set 94-karakter penuh; 100 bit yang dipersyaratkan oleh ANSSI (setara NSA Prancis) untuk kata sandi yang melindungi sistem enkripsi, dicapai pada ~16 karakter; dan 128 bit yang cocok dengan kekuatan kunci simetris AES-128, direkomendasikan untuk kata sandi master vault, dicapai pada ~20 karakter.

    Peringatan besar: matematika ini hanya berlaku untuk kata sandi acak. Jika manusia memilih kata sandi tersebut, entropi efektifnya jauh, jauh lebih rendah. Penyerang tidak menghitung R^L string secara alfabetis; mereka menjalankan program tebakan yang diisi dengan daftar kata sandi yang bocor, kata-kata kamus, substitusi umum (a→@, o→0, s→$), pola keyboard, dan model statistik tentang bagaimana manusia membuat string yang mudah diingat. Studi Joseph Bonneau tahun 2012 terhadap korpus anonim 70 juta kata sandi Yahoo (IEEE Symposium on Security and Privacy) menemukan bahwa kata sandi yang dipilih pengguna memberikan «kurang dari 10 bit keamanan terhadap serangan trawling online, dan hanya sekitar 20 bit terhadap serangan kamus offline yang optimal.» Dua puluh bit adalah satu juta tebakan. GPU modern menyelesaikannya dalam waktu mikrodetik.

    NIST SP 800-63B, apa yang berubah pada 2017 dan lagi pada 2025

    Selama sekitar tiga puluh tahun, kebijakan keamanan Amerika Utara tentang kata sandi diturunkan dari publikasi NIST tahun 1985 yang merekomendasikan rotasi berkala yang dipaksakan, kelas karakter campuran, dan panjang minimum yang pendek. Bill Burr, penulis tindak lanjut tahun 2003 yang mengkodifikasikan aturan «huruf besar + huruf kecil + angka + simbol, ganti setiap 90 hari,» secara terbuka mencabut pernyataannya pada tahun 2017, memberi tahu Wall Street Journal bahwa «banyak dari apa yang saya lakukan, kini saya sesali.» NIST memformalkan pembalikan tersebut pada tahun yang sama.

    NIST SP 800-63B Rev 3 (Juni 2017) membuat dua perubahan generasional. Bagian 5.1.1.2 berbunyi: «Penguji TIDAK SEHARUSNYA mewajibkan rahasia yang dihafal untuk diubah secara sewenang-wenang (misalnya, secara berkala),» karena rotasi paksa menyebabkan pengguna memilih kata sandi yang lebih lemah dan lebih dapat diprediksi. Bagian yang sama: «Penguji TIDAK SEHARUSNYA memberlakukan aturan komposisi lain (misalnya, mewajibkan campuran jenis karakter berbeda) untuk rahasia yang dihafal,» karena memaksa angka dan simbol mendorong pengguna ke arah Password1! daripada passphrase yang lebih panjang. Rev 3 menetapkan panjang minimum 8 karakter untuk pilihan pelanggan, mewajibkan penguji menerima hingga 64, mengharuskan pemeriksaan kata sandi baru terhadap daftar blokir pelanggaran, dan secara eksplisit mewajibkan pengelola kata sandi dan tempel dari clipboard diizinkan.

    NIST SP 800-63B Rev 4 (finalisasi 31 Juli 2025) memperketat standar: kata sandi satu faktor kini memerlukan minimum 15 karakter («Penguji dan CSP HARUS mewajibkan kata sandi yang digunakan sebagai mekanisme autentikasi satu faktor memiliki panjang minimum 15 karakter»). Kata sandi multi-faktor tetap 8 karakter karena faktor kedua menanggung bobot keamanannya. Aturan komposisi masih dilarang, dan redaksi berubah dari «TIDAK SEHARUSNYA» pada Rev 3 menjadi «TIDAK BOLEH» pada Rev 4, menjadikannya persyaratan keras daripada rekomendasi. Rotasi masih tidak dianjurkan kecuali ada bukti kompromitasi.

    Alat Absolutool menggunakan default 16 karakter dengan semua empat kelas karakter, memberikan sekitar 104 bit entropi dan dengan nyaman melampaui persyaratan minimum 15-karakter Rev 4 dan ambang setara simetris 80-bit. Maksimum 128 karakter dari alat ini tepat dua kali lipat panjang maksimum yang diwajibkan NIST untuk diterima oleh penguji; tidak ada kasus realistis di mana kata sandi yang dihasilkan akan terlalu panjang untuk diterima oleh server.

    RockYou, bencana yang masih menghantui 2026

    Pada Desember 2009, perusahaan permainan sosial RockYou dibobol melalui SQL injection yang sudah umum diketahui. Pelanggaran tersebut mengekspos lebih dari 32 juta akun pengguna termasuk kata sandi untuk akun-akun tersebut dalam bentuk teks biasa: RockYou menyimpannya tanpa enkripsi. Kebijakan kata sandi perusahaan saat itu hanya memerlukan lima karakter dan tidak mengizinkan karakter khusus, yang memperparah kerentanan.

    File yang dibobol, segera dijuluki rockyou.txt, diterbitkan secara terbuka dan tetap menjadi daftar kata kunci kata sandi yang paling banyak dirujuk di dunia. File ini dikirimkan secara default dengan Kali Linux untuk penguji penetrasi; setiap alat serangan kamus di seluruh dunia memeriksanya; layanan credential-stuffing komersial memeliharanya sebagai baseline. Enam belas tahun kemudian, penyerang masih menangkap akun aktif menggunakan kata sandi yang pertama kali muncul dalam kebocoran 2009. Pelajaran yang disebarkan: server tidak boleh pernah melihat kata sandi teks biasa (alat ini menghasilkan di sisi klien, sehingga server tidak pernah melihatnya sama sekali); kata sandi yang tersimpan harus di-hash dengan fungsi lambat, bergaram, dan padat-memori seperti Argon2id atau bcrypt, bukan hash cepat seperti MD5 atau SHA-1 tanpa garam; kata sandi unik per situs adalah satu-satunya pertahanan terhadap serangan replay kredensial yang dicuri yang telah mendominasi satu dekade pelanggaran terakhir.

    Have I Been Pwned dan korpus pelanggaran

    Have I Been Pwned (HIBP), yang dijalankan oleh Microsoft Regional Director Troy Hunt, telah menjadi sumber otoritatif standar untuk pertanyaan «apakah kata sandi ini pernah muncul dalam pelanggaran?» Hunt meluncurkan HIBP pada tahun 2013 sebagai indeks alamat email yang dibobol yang dapat dicari; ia kemudian menambahkan korpus Pwned Passwords, daftar yang dapat diunduh dari setiap kata sandi yang terlihat dalam pelanggaran publik, diindeks berdasarkan hash SHA-1. Pwned Passwords V2 diluncurkan pada 22 Februari 2018 dan memperkenalkan API k-anonimitas dataset (dibangun dengan Cloudflare): klien hanya mengirimkan lima karakter pertama dari hash SHA-1; server mengembalikan setiap hash penuh yang dimulai dengan lima karakter tersebut beserta jumlah kemunculannya; klien membandingkan secara lokal. Kata sandi (dan bahkan hash penuhnya) tidak pernah meninggalkan perangkat pengguna.

    Untuk generator massal, relevansinya ada dua. Kata sandi yang sudah ada di HIBP, menurut definisi, bukan kata sandi baru yang berguna; itulah hal pertama yang akan dicoba oleh penyerang credential-stuffing. Dan karena alat ini menghasilkan dengan keacakan CSPRNG penuh dari alfabet 94-karakter, probabilitas bahwa kata sandi 16-karakter yang baru dihasilkan sudah ada di HIBP adalah, untuk tujuan praktis, nol. (Total jumlah kata sandi ASCII 16-karakter adalah 94^16 ≈ 3,7 × 10³¹; HIBP berisi sekitar 10⁹ kata sandi yang diketahui; probabilitas tabrakan ≈ 10⁻²².)

    Apa arti «X bit entropi» dalam waktu nyata untuk membobol

    Angka yang memberikan makna konkret pada bit entropi adalah «berapa lama penyerang modern membutuhkan?», dan jawabannya sepenuhnya bergantung pada algoritma hash. Tolok ukur yang diterbitkan komunitas untuk hashcat v6.2.6 pada satu Nvidia RTX 4090 mencatat sekitar 300 GH/s untuk hash NTLM (hash Windows lama Microsoft) dan 200 kH/s untuk bcrypt. Selisih empat orde besaran antara keduanya adalah fakta kunci: NTLM dirancang untuk kecepatan, bcrypt dirancang untuk lambat.

    Tabel kata sandi Hive Systems yang banyak dikutip mengubah tolok ukur tersebut menjadi angka waktu-untuk-membobol. Versi 2025 yang dihitung terhadap hash MD5 (hampir secepat NTLM) memberikan ~59 menit pada satu RTX 4090 untuk brute-force kata sandi 8-karakter dari set karakter penuh. Kata sandi 8-karakter yang sama terhadap hash bcrypt membutuhkan waktu ~99 tahun pada perangkat keras yang sama. Selisih empat orde besaran itulah perbedaan antara «bocor kemarin, dibobol sebelum makan siang» dan «bocor kemarin, akan bertahan lebih lama dari Anda».

    Pengguna akhir mengontrol panjang kata sandi dan set karakter. Mereka tidak mengontrol algoritma hash yang digunakan server untuk menyimpannya. Sebagian besar layanan modern yang dikelola dengan baik menggunakan bcrypt, scrypt, atau Argon2id, semuanya sengaja dibuat lambat. Layanan lama dan layanan yang pernah dibobol sering menggunakan MD5 atau SHA-1 tanpa garam, itulah mengapa korpus pelanggaran lama dapat dibobol dengan kecepatan yang disebutkan di atas. Untuk kata sandi yang dihasilkan oleh alat ini: kata sandi acak 16-karakter pada dasarnya aman terhadap bcrypt selamanya dan cukup aman terhadap MD5 untuk saat ini; kata sandi 20-karakter adalah berlebihan terhadap keduanya. Tidak ada model ancaman realistis di mana 20+ karakter keluaran CSPRNG menjadi mata rantai yang lemah.

    FIDO2, WebAuthn, dan transisi passkey

    Prediksi yang paling lama dalam industri keamanan adalah bahwa kata sandi akan hilang. Sejak 2019, akhirnya ada pengganti yang kredibel: passkey, nama pemasaran konsumen untuk kredensial yang diterbitkan di bawah standar FIDO2 / WebAuthn. WebAuthn Level 1 menjadi Rekomendasi W3C pada 4 Maret 2019; Level 2 menyusul pada 8 April 2021. Model kriptografisnya asimetris: ketika pengguna mendaftar, autentikator menghasilkan pasangan kunci publik/privat, mengirimkan kunci publik ke server, dan menyimpan kunci privat di perangkat keras lokal yang aman. Autentikasi menggunakan tantangan-respons yang ditandatangani dengan kunci privat. Server tidak pernah melihat rahasianya, yang berarti pelanggaran di sisi server tidak dapat mengekspos kredensial login.

    Peluncuran platform utama bergerak seiring pada 2022-2023: Apple mendemonstrasikan passkey di WWDC pada 6 Juni 2022 dan merilisnya secara publik dengan iOS 16, iPadOS 16, dan macOS Ventura pada September 2022, disinkronkan melalui iCloud Keychain yang dienkripsi ujung ke ujung. Google mengumumkan dukungan passkey untuk Android dan Chrome pada 12 Oktober 2022; dukungan Chrome stabil tiba di Chrome 108 pada Desember 2022, disinkronkan melalui Google Password Manager. Microsoft mengumumkan manajemen passkey untuk Windows 11 pada 21 September 2023, terintegrasi dengan Windows Hello.

    Passkey menyelesaikan kelas kegagalan kata sandi yang paling menyakitkan (phishing, credential stuffing, pelanggaran server), tetapi belum menghilangkan kata sandi karena: banyak situs dan sebagian besar sistem warisan masih membutuhkannya; passkey terikat pada perangkat atau ekosistem sinkronisasi (pengguna tanpa akun Apple, Google, atau Microsoft memerlukan alternatif); sistem headless (perangkat IoT, akun layanan sisi server, skenario onboarding massal) tidak dapat mengandalkan autentikator biometrik pada langkah pendaftaran; dan banyak kebijakan kata sandi perusahaan, sistem perbankan, dan portal pemerintah masih mewajibkan kata sandi. Pembuatan kata sandi massal berada tepat di kategori kedua dan ketiga: administrator sistem yang menyediakan 50 akun baru tidak dapat meminta setiap pengguna mendatang mendaftarkan passkey sebelum akun tersebut ada.

    Mengapa pembuatan di sisi klien secara khusus penting

    Bayangkan alat kompetitor yang mengirimkan permintaan pengguna ke server melalui POST; server menjalankan generator acak dan mengembalikan daftarnya sebagai JSON. Bahkan jika semuanya berjalan sesuai iklan, pihak-pihak berikut dapat melihat kata sandi yang dihasilkan dalam teks biasa: memori proses server saat permintaan sedang ditangani; log permintaan server (jika pencatatan dilakukan secara sembrono); layanan APM atau pelacak kesalahan yang terhubung ke server; proxy terbalik yang mengakhiri TLS (Cloudflare, load balancer AWS, nginx); alat debugging yang berjalan di server; penyerang masa depan yang mendapatkan akses ke salah satu log tersebut. Model RockYou, dengan semua konsekuensinya, berlaku.

    Ketika pembuatan terjadi melalui window.crypto.getRandomValues() di browser pengguna, tidak ada dari itu yang berlaku. Byte dihasilkan di dalam proses browser, di mesin pengguna, oleh kode yang dapat diaudit pengguna (halaman dapat dilihat sumbernya). Byte-byte tersebut tidak pernah melintasi jaringan. Server Absolutool tidak pernah melihatnya, tidak pernah mencatatnya, dan tidak dapat membocorkannya dalam pelanggaran masa depan karena tidak pernah memilikinya. Satu-satunya entitas yang melihat kata sandi yang dihasilkan adalah pengguna, siapa pun yang memiliki akses ke sesi browser pengguna (biasanya hanya pengguna itu sendiri), dan ekstensi browser yang berjalan di halaman tersebut. Ini adalah model keamanan yang sama dengan generator lokal pengelola kata sandi, dan lebih kuat dari model layanan web mana pun yang mengembalikan kata sandi yang dihasilkan dari server.

    Mirai 2016, contoh negatif untuk default IoT

    Contoh negatif klasik untuk «mari gunakan kata sandi default yang sama di setiap unit» adalah botnet Mirai. Mirai mengeksploitasi daftar hardcoded dari sekitar 62 kombinasi nama pengguna/kata sandi default pabrikan (admin/admin, root/root, root/xc3511, root/vizxv) untuk menginfeksi ratusan ribu kamera IP, DVR, dan router rumahan pada akhir 2016, lalu menggunakannya pada 21 Oktober 2016 untuk menonaktifkan penyedia DNS utama Dyn, yang sempat mematikan Twitter, Reddit, Netflix, dan GitHub. Generator kata sandi massal adalah primitif yang tepat untuk alternatifnya: hasilkan default unik yang kuat per unit di lini produksi, cetak pada stiker, kirimkan di dalam kotak.

    Pertanyaan lainnya

    Mengapa NIST merekomendasikan panjang daripada kompleksitas?

    Karena memaksakan kompleksitas (sebuah angka, simbol, huruf besar) mendorong pengguna ke pola yang dapat diprediksi yang telah dimodelkan oleh penyerang. Password1! secara matematis memiliki lebih banyak entropi daripada password, tetapi dalam praktiknya setiap daftar kata penyerang dimulai dari sana. String 20-karakter semua huruf kecil dari CSPRNG memiliki ~94 bit entropi dan tidak dapat ditebak oleh daftar kata mana pun karena tidak cocok dengan daftar kata. NIST SP 800-63B Rev 4 (Juli 2025) menjadikan larangan aturan komposisi sebagai persyaratan TIDAK BOLEH yang keras.

    Haruskah saya menggunakan passphrase?

    Untuk kata sandi yang harus Anda hafal, ya, itulah yang diperdebatkan oleh xkcd #936 (10 Agustus 2011). Metode Diceware (Arnold Reinhold, 1995) memberikan 12,9 bit per kata dari daftar 7.776 kata; enam kata ≈ 77,5 bit adalah rekomendasi modern. EFF merilis daftar kata yang kompatibel dengan diceware yang diperbarui pada Juli 2016. Tetapi untuk kasus penggunaan penyediaan massal yang dilayani alat ini (token sementara yang diubah saat login pertama), ASCII acak adalah primitif yang tepat karena pengguna tidak perlu pernah mengetiknya.

    Apakah mengecualikan karakter yang ambigu adalah pertukaran keamanan?

    Ya, secara teknis, menghapus i, l, 1, L, O, 0, o mengecilkan alfabet dari 94 menjadi 87, menurunkan entropi per karakter dari 6,55 bit menjadi 6,44 bit. Pada 16 karakter itu adalah 103,0 bit daripada 104,8 bit, sama sekali tidak relevan. Pertukaran tersebut terbayar ketika manusia harus membaca kata sandi dengan lantang atau menyalinnya dari lembar cetak, yang merupakan skenario distribusi massal yang dilayani alat ini.

    Apa cara paling aman untuk mendistribusikan daftar yang dihasilkan?

    Perlakukan daftar yang dihasilkan sebagai artefak sekali pakai. Distribusikan melalui saluran yang telah diatur sebelumnya (email terenkripsi dengan PGP/GPG, transfer file aman, impor pengelola kata sandi, sneakernet tatap muka untuk konteks berisiko tinggi). Konfigurasikan sistem untuk mewajibkan perubahan kata sandi saat login pertama. Hapus file setelah distribusi. Jangan pernah mengirim daftar teks biasa melalui email, jangan pernah meng-commit-nya ke kontrol versi, jangan pernah menempelkannya ke obrolan. Kata sandi yang dihasilkan dimaksudkan sebagai token sekali pakai; nilainya ada pada keacakan kriptografis untuk serah terima awal, bukan pada penyimpanan jangka panjang.

    Alat terkait

    Generator kata sandi

    Buat kata sandi acak yang kuat.

    Encoder Base64

    Enkode dan dekode Base64 secara seketika.

    Generator string acak

    Buat string acak dengan pola kustom.