Perkara yang sebenarnya dilindungi oleh hash kata laluan

Versi ringkas

Hashing kata laluan melindungi pengguna apabila pangkalan data kata laluan anda dicuri.

Itulah tugas utamanya. Bukan satu-satunya perincian, bukan keseluruhan model keselamatan, tetapi sebab utama kita meng-hash kata laluan dan bukannya menyimpannya secara terus.

Kata laluan yang di-hash dengan betul sukar untuk diterbalikkan. Jika penyerang mendapat salinan jadual pengguna anda, mereka tidak sepatutnya terus mengetahui bahawa kata laluan Alice ialah Spring2026!. Sebaliknya, mereka mendapat hash tersimpan yang memerlukan masa, wang, dan perkakasan untuk diuji terhadap tekaan.

Perbezaan itu penting. Hashing kata laluan tidak bertujuan menjadikan log masuk selamat dengan sendirinya. Ia tidak menghentikan phishing. Ia tidak menghentikan seseorang daripada mencuba kata laluan bocor pada borang log masuk anda. Ia tidak melindungi kuki sesi selepas log masuk. Ia membeli masa dan mengurangkan mudarat selepas kegagalan yang sangat khusus: storan pengesah kata laluan anda terdedah.

Jika anda memahami sempadan itu, anda akan membuat keputusan yang lebih baik tentang algoritma, faktor kerja, tetapan semula, pengelogan, dan tindak balas insiden.

Apakah itu hash kata laluan

Hash kata laluan ialah output fungsi sehala yang digunakan pada kata laluan, biasanya dengan salt unik dan algoritma hashing kata laluan yang sengaja diperlahankan.

Apabila pengguna mencipta akaun, sistem sepatutnya melakukan kira-kira begini:

1. Menerima kata laluan melalui HTTPS.
2. Menjana salt rawak yang unik.
3. Menjalankan kata laluan dan salt melalui fungsi hashing kata laluan seperti Argon2id, bcrypt, scrypt, atau PBKDF2.
4. Menyimpan nama algoritma, parameter, salt, dan hash yang terhasil.
5. Membuang kata laluan asal.

Apabila pengguna log masuk kemudian, sistem mengulangi proses hashing yang sama dengan kata laluan yang dihantar dan parameter yang disimpan. Jika hash yang terhasil sepadan dengan hash tersimpan, log masuk berjaya.

Bahagian pentingnya: aplikasi tidak perlu mengetahui kata laluan asal. Ia hanya perlu mengesahkan bahawa kata laluan yang dihantar menghasilkan keputusan yang dijangka.

Inilah sebabnya menyimpan kata laluan dengan penyulitan boleh balik biasanya model yang salah. Jika aplikasi anda boleh menyahsulit setiap kata laluan, maka sesiapa yang mencuri kunci penyahsulitan boleh melakukan perkara yang sama. Kata laluan biasanya patut tidak boleh disahkan secara terbalik, bukan sekadar disembunyikan.

Perkara yang dilindungi oleh hashing

1. Pendedahan kata laluan serta-merta selepas pelanggaran pangkalan data

Jika penyerang mencuri pangkalan data yang mengandungi kata laluan teks biasa, kerosakannya serta-merta. Setiap kata laluan terdedah. Pengguna berisiko bukan sahaja di laman anda, tetapi di mana-mana tempat mereka menggunakan semula kata laluan itu.

Jika pangkalan data mengandungi kata laluan yang di-hash dengan baik, penyerang mempunyai lebih banyak kerja untuk dilakukan. Mereka mesti meneka kata laluan calon, meng-hash setiap tekaan dengan salt dan parameter yang betul, lalu membandingkan hasilnya.

Untuk kata laluan yang lemah, ini masih mungkin pantas. Untuk kata laluan unik yang kuat, ia boleh menjadi tidak praktikal.

Hashing menukar pendedahan yang dahsyat menjadi perlumbaan: bolehkah pengguna menetapkan semula kata laluan dan bolehkah anda membendung insiden sebelum penyerang memecahkan banyak daripadanya?

Itu tidak sempurna. Ia masih satu pelanggaran. Tetapi ia mod kegagalan yang jauh lebih baik.

2. Serangan pukal terhadap seluruh pangkalan pengguna anda

Salt ialah bahagian penting dalam storan kata laluan kerana ia menghalang penyerang daripada menyerang ramai pengguna sekali gus secara cekap menggunakan jadual pra-kiraan.

Salt bukan rahsia. Ia disimpan bersama hash. Tugasnya ialah keunikan.

Jika dua pengguna memilih kata laluan yang sama, salt unik memastikan hash tersimpan mereka berbeza. Itu menghalang penyerang daripada melihat sepintas lalu bahawa ramai pengguna berkongsi kata laluan yang sama. Ia juga menghalang serangan jadual pelangi klasik, di mana penyerang menggunakan senarai pra-kiraan yang sangat besar bagi pemetaan kata laluan kepada hash.

Tanpa salt, satu hash yang dipecahkan mungkin mendedahkan setiap pengguna dengan kata laluan yang sama. Dengan salt, setiap tekaan kata laluan mesti diuji secara berasingan untuk setiap pengguna.

3. Tekaan luar talian yang pantas

Sebaik sahaja penyerang mempunyai pangkalan data kata laluan, mereka boleh meneka secara luar talian. Ini bermaksud had kadar log masuk, CAPTCHA, sekatan IP, dan pemantauan anda tidak lagi penting. Penyerang boleh menguji tekaan pada perkakasan mereka sendiri.

Di sinilah pilihan algoritma penting.

Hash tujuan umum seperti SHA-256 dan SHA-512 direka untuk pantas. Itu baik untuk integriti fail dan tandatangan digital. Ia buruk untuk storan kata laluan.

Algoritma hashing kata laluan direka untuk perlahan, boleh dilaras, dan kadangkala memerlukan memori yang tinggi. Argon2id, bcrypt, scrypt, dan PBKDF2 semuanya membolehkan anda melaras parameter kos supaya setiap tekaan mengambil masa yang bermakna.

Argon2id disyorkan secara meluas untuk sistem baharu kerana ia boleh dikonfigurasikan untuk memerlukan masa CPU dan memori, yang menjadikan pemecahan berskala besar menggunakan GPU lebih mahal. bcrypt masih lazim dan boleh diterima apabila dikonfigurasikan dengan baik, walaupun ia mempunyai batasan seperti pengendalian panjang kata laluan. PBKDF2 masih digunakan dalam sesetengah persekitaran yang dipacu pematuhan, khususnya apabila komponen yang disahkan FIPS diperlukan.

Prinsipnya mudah: jadikan log masuk yang sah cukup pantas untuk diterima, sambil menjadikan berbilion-bilion tekaan mahal.

Perkara yang tidak dilindungi oleh hashing

1. Phishing

Jika pengguna menaip kata laluan mereka ke dalam halaman log masuk palsu, hashing pada pelayan anda tidak membantu. Penyerang menerima kata laluan itu sebelum sistem anda sempat melihatnya.

Pertahanan di sini berbeza: pengesahan berbilang faktor, passkeys, pendidikan pengguna, kebersihan domain, pengesahan tahan phishing, dan aliran tetapan semula kata laluan yang teliti.

Hashing kata laluan ialah sandaran untuk rahsia tersimpan. Ia bukan pertahanan terhadap pengguna yang diperdaya supaya menyerahkan rahsia tersebut.

2. Credential stuffing

Credential stuffing berlaku apabila penyerang mengambil pasangan nama pengguna dan kata laluan yang bocor daripada satu perkhidmatan lalu mencubanya pada perkhidmatan lain.

Hash kata laluan anda mungkin sangat baik, dan credential stuffing masih boleh berjaya jika pengguna menggunakan semula kata laluan.

Ini ialah serangan dalam talian terhadap borang log masuk anda, bukan serangan luar talian terhadap pangkalan data anda. Anda memerlukan had kadar, pengesanan anomali, semakan kata laluan bocor, MFA, dan dasar kunci akaun yang munasabah yang tidak mencipta peluang penafian perkhidmatan dengan mudah.

Pemikiran praktikal yang sama terpakai pada mana-mana borang terdedah. Jika anda sedang menilai permukaan pengesahan anda, wajar membaca tentang mengapa borang hubungan anda ialah liabiliti spam terbesar anda; mekaniknya berbeza, tetapi pengajarannya serupa: input awam memerlukan kawalan penyalahgunaan, bukan sekadar kod backend yang bersih.

3. Kata laluan yang ditangkap dalam log atau analitik

Hashing hanya membantu jika kata laluan teks biasa dibuang dengan cepat dan tidak pernah disalin ke tempat lain.

Kegagalan lazim termasuk:

• Mengelog badan permintaan penuh pada percubaan log masuk yang gagal.
• Menghantar kata laluan ke alat pemantauan ralat.
• Menangkap medan kata laluan dalam produk ulang tayang sesi.
• Memasukkan kelayakan dalam URL semasa aliran tetapan semula atau migrasi yang direka dengan buruk.
• Menyimpan kata laluan teks biasa sementara semasa import.

Kesilapan ini memintas hashing kata laluan sepenuhnya. Jika teks biasa masuk ke dalam log, sandaran, gudang data, atau alat pihak ketiga, fungsi hash anda tidak relevan.

Anggap medan kata laluan sebagai data toksik. Redaksikannya sebelum pengelogan. Kecualikannya daripada analitik. Jauhkan daripadanya daripada URL. Hadkan siapa yang boleh mengakses jejak produksi.

4. Keselamatan sesi yang lemah

Selepas log masuk, pelayar pengguna biasanya menerima kuki sesi atau token. Jika token itu dicuri, penyerang mungkin langsung tidak memerlukan kata laluan.

Hashing kata laluan tidak melindungi daripada cross-site scripting, kuki tidak selamat, session fixation, penjanaan token yang lemah, atau hayat sesi yang terlalu panjang.

Kuki sesi wajar disemak secara khusus: HttpOnly, Secure, SameSite yang sesuai, sesi berisiko tinggi yang berjangka pendek, dan pembatalan sisi pelayan apabila kata laluan berubah. Landskap privasi dan pelayar yang lebih luas juga terus berubah, seperti yang dihuraikan dalam perkara yang berubah untuk kuki pada 2026.

5. Tetapan semula kata laluan dan pemulihan akaun yang lemah

Banyak pengambilalihan akaun tidak bermula dengan kata laluan. Ia bermula dengan aliran tetapan semula.

Jika token tetapan semula boleh diramal, berjangka panjang, bocor melalui pengepala perujuk, atau dihantar ke akaun e-mel yang dikompromi, hashing kata laluan tidak akan menyelamatkan anda.

Gunakan token tetapan semula berentropi tinggi, tetingkap luput yang pendek, penggunaan sekali sahaja, dan pemberitahuan pengguna yang jelas. Memandangkan e-mel sering menjadi saluran pemulihan, pengesahan domain asas juga penting. Jika pasukan anda menganggap rekod DNS sebagai upacara yang misteri, mulakan dengan lawatan mesra pembangun tentang MX, SPF, DKIM dan DMARC.

Pilihan algoritma: apa yang patut digunakan sekarang

Untuk aplikasi baharu, gunakan Argon2id jika platform anda menyokongnya dengan baik. Ia ialah pemenang Password Hashing Competition dan direka untuk storan kata laluan, termasuk ketahanan terhadap pemecahan berat GPU.

Hierarki moden yang munasabah kelihatan seperti ini:

1. Argon2id untuk sistem baharu apabila tersedia.
2. bcrypt apabila Argon2id tidak praktikal dan sokongan bcrypt matang.
3. scrypt apabila konfigurasi yang memerlukan memori tinggi disokong dengan baik.
4. PBKDF2 apabila diperlukan oleh kekangan platform atau pematuhan.

Elakkan SHA-256, SHA-512, MD5 biasa, atau gabungan buatan sendiri seperti sha256(password + salt). Hash pantas bukan fungsi storan kata laluan. Binaan tersuai yang kelihatan bijak cenderung lebih buruk daripada piawaian biasa yang membosankan.

Juga elakkan mencipta dasar kata laluan anda sendiri berdasarkan perincian algoritma yang remeh. Pengguna tidak mendapat manfaat daripada senarai semak komposisi kata laluan 12 peraturan jika ia mendorong mereka kepada corak yang boleh diramal. Kata laluan unik yang lebih panjang, pengurus kata laluan, saringan kata laluan bocor, dan MFA biasanya lebih penting.

Faktor kos bukan sesuatu yang ditetapkan sekali lalu dilupakan

Hashing kata laluan mempunyai parameter. Argon2id mempunyai memori, lelaran, dan keselarian. bcrypt mempunyai faktor kos. PBKDF2 mempunyai kiraan lelaran.

Nilai ini patut dipilih berdasarkan persekitaran produksi anda. Terlalu rendah, dan penyerang boleh meneka dengan murah. Terlalu tinggi, dan sistem log masuk anda menjadi perlahan atau terdedah kepada penafian perkhidmatan.

Sasaran praktikal selalunya berada dalam julat puluhan hingga beberapa ratus milisaat bagi setiap pengesahan kata laluan pada pelayan sebenar anda, bergantung pada trafik dan risiko. Sistem keselamatan tinggi mungkin memilih lebih. Sistem berskala pengguna mungkin memerlukan perancangan kapasiti yang teliti.

Jangan salin faktor kos daripada catatan blog lima tahun lalu. Perkakasan berubah. Pustaka berubah. Trafik anda berubah.

Semak parameter secara berkala dan rancang untuk hashing semula. Corak lazim ialah menyimpan algoritma dan parameter bersama setiap hash. Pada log masuk yang berjaya, jika parameter tersimpan sudah lapuk, hash semula kata laluan yang dihantar dengan konfigurasi lebih baharu dan kemas kini rekod.

Pepper: berguna, tetapi bukan pengganti

Pepper ialah nilai rahsia yang ditambahkan pada proses hashing kata laluan dan disimpan berasingan daripada pangkalan data, sering kali dalam pengurus rahsia atau modul keselamatan perkakasan.

Tidak seperti salt, pepper mesti kekal rahsia.

Pepper boleh mengurangkan kerosakan jika pangkalan data bocor tetapi rahsia aplikasi tidak bocor. Ia paling berguna dalam persekitaran matang dengan pengurusan kunci yang baik. Ia kurang berguna jika penyerang yang sama boleh mencuri kedua-dua pangkalan data dan konfigurasi aplikasi.

Jika anda menggunakan pepper, rancang putaran dengan teliti. Memutarkannya mungkin memerlukan pengguna log masuk semula atau menetapkan semula kata laluan, bergantung pada reka bentuk. Pepper ialah lapisan tambahan, bukan alasan untuk melemahkan tetapan hash asas.

Senarai semak operasi

Jika anda bertanggungjawab terhadap sistem sebenar, senarai semak praktikalnya ringkas:

• Simpan kata laluan hanya dengan algoritma hashing kata laluan standard.
• Gunakan salt rawak yang unik bagi setiap kata laluan.
• Utamakan Argon2id untuk binaan baharu.
• Laras parameter kos pada perkakasan yang menyerupai produksi.
• Simpan algoritma dan parameter bersama setiap hash.
• Hash semula semasa log masuk apabila parameter menjadi lapuk.
• Jangan sekali-kali mengelog kata laluan atau menghantarnya ke alat analitik.
• Gunakan TLS di semua tempat kelayakan dihantar.
• Tambahkan MFA atau passkeys apabila risiko mewajarkannya.
• Lindungi aliran tetapan semula sama serius seperti aliran log masuk.
• Sediakan pelan insiden untuk tetapan semula paksa dan pemberitahuan pengguna.

Hashing kata laluan tidak glamor. Ia seperti paip. Tetapi ia jenis paip yang menentukan sama ada pelanggaran menjadi insiden yang menyakitkan atau bencana seluruh pengguna.

<!-- tool-cta:start -->

💡 Cuba ini: Lihat bagaimana input yang sama dipetakan kepada algoritma yang berbeza dengan Hash Generator, yang menjadikan perbezaan antara hash pantas dan hash gred kata laluan lebih jelas.

<!-- tool-cta:end -->

Model mental yang jujur

Cara terbaik untuk memikirkan hashing kata laluan ialah begini:

Hashing tidak melindungi kata laluan semasa pengguna menaipnya. Ia tidak melindungi akaun selepas pengguna log masuk. Ia tidak melindungi pengguna yang menggunakan semula kata laluan merentas web.

Ia melindungi pengesah yang disimpan.

Itu kedengaran sempit, tetapi ia amat penting. Pangkalan data bocor. Sandaran bocor. Sistem staging disalin. Vendor mendapat akses yang tidak sepatutnya mereka miliki. Eksport lama berada dalam storan objek lebih lama daripada yang diingati sesiapa.

Apabila itu berlaku, reka bentuk storan kata laluan anda menjadi perbezaan antara penyerang menerima kata laluan dan penyerang menerima masalah tekaan yang mahal.

Itulah perkara yang sebenarnya dilindungi oleh hash kata laluan.