Ano talaga ang ipinagtatanggol sa iyo ng pagha-hash ng password

Ang maikling bersyon

Pinoprotektahan ng pagha-hash ng password ang mga user kapag nanakaw ang iyong password database.

Iyon ang pangunahing trabaho nito. Hindi iyon ang tanging detalye, hindi ang buong security model, ngunit iyon ang sentral na dahilan kung bakit hina-hash natin ang mga password sa halip na itago ang mga ito nang direkta.

Mahirap baligtarin ang isang maayos na na-hash na password. Kung makakuha ang isang attacker ng kopya ng iyong user table, hindi dapat agad niyang malaman na ang password ni Alice ay Spring2026!. Sa halip, makakakuha siya ng nakaimbak na hash na nangangailangan ng oras, pera, at hardware para subukan laban sa mga hula.

Mahalaga ang pagkakaibang iyon. Hindi nilalayong gawing secure ng password hashing ang login nang mag-isa. Hindi nito pinipigil ang phishing. Hindi nito pinipigilan ang isang tao na subukan ang mga leaked password laban sa iyong login form. Hindi nito pinoprotektahan ang session cookie pagkatapos ng login. Bumibili ito ng oras at binabawasan ang pinsala matapos ang isang napaka-espesipikong kabiguan: nalantad ang iyong password verifier storage.

Kung nauunawaan mo ang hangganang iyon, makakagawa ka ng mas mabubuting desisyon tungkol sa mga algorithm, work factor, reset, logging, at incident response.

Ano ang password hash

Ang password hash ay ang output ng isang one-way function na inilapat sa isang password, karaniwang may natatanging salt at sinadyang mabagal na password-hashing algorithm.

Kapag gumagawa ng account ang isang user, dapat gawin ng system ang humigit-kumulang ganito:

1. Tanggapin ang password sa pamamagitan ng HTTPS.
2. Gumawa ng random at natatanging salt.
3. Patakbuhin ang password at salt sa isang password-hashing function tulad ng Argon2id, bcrypt, scrypt, o PBKDF2.
4. Itago ang pangalan ng algorithm, mga parameter, salt, at nagresultang hash.
5. Itapon ang orihinal na password.

Kapag nag-log in ang user sa ibang pagkakataon, inuulit ng system ang parehong proseso ng hashing gamit ang isinumiteng password at mga nakaimbak na parameter. Kung tumugma ang nagresultang hash sa nakaimbak na hash, magtatagumpay ang login.

Ang mahalagang bahagi: hindi kailangang malaman ng application ang orihinal na password. Kailangan lang nitong beripikahin na ang isinumiteng password ay lumilikha ng inaasahang resulta.

Ito ang dahilan kung bakit karaniwang maling modelo ang pag-iimbak ng mga password gamit ang reversible encryption. Kung kayang i-decrypt ng iyong application ang bawat password, magagawa rin iyon ng sinumang magnakaw ng decryption key. Dapat ay karaniwang hindi mabe-verify pabalik ang mga password, hindi lamang nakatago.

Ano ang pinoprotektahan ng hashing laban sa iyo

1. Agarang pagbubunyag ng password matapos ang database breach

Kung magnakaw ang isang attacker ng database na naglalaman ng plaintext passwords, agarang nangyayari ang pinsala. Nalalantad ang bawat password. Nasa panganib ang mga user hindi lamang sa iyong site, kundi kahit saan nila muling ginamit ang password na iyon.

Kung ang database ay naglalaman ng maayos na na-hash na mga password, mas marami pang kailangang gawin ang attacker. Kailangan niyang hulaan ang mga candidate password, i-hash ang bawat hula gamit ang tamang salt at mga parameter, at ikumpara ang resulta.

Para sa mahihinang password, maaari pa rin itong maging mabilis. Para sa malalakas at natatanging password, maaari itong maging hindi praktikal.

Ginagawang karera ng hashing ang isang mapaminsalang pagbubunyag: mare-reset ba ng mga user ang mga password at makokontrol mo ba ang insidente bago ma-crack ng mga attacker ang marami sa mga ito?

Hindi iyon perpekto. Breach pa rin iyon. Ngunit mas mabuting failure mode ito nang malaki.

2. Bulk attacks laban sa buong user base mo

Mahalagang bahagi ng password storage ang mga salt dahil pinipigilan ng mga ito ang mga attacker na mahusay na umatake sa maraming user nang sabay-sabay gamit ang precomputed tables.

Hindi lihim ang salt. Iniimbak ito kasama ng hash. Ang trabaho nito ay uniqueness.

Kung pumili ang dalawang user ng parehong password, tinitiyak ng natatanging mga salt na magkaiba ang kanilang nakaimbak na mga hash. Pinipigilan nito ang mga attacker na makita agad na maraming user ang may parehong password. Pinipigilan din nito ang mga klasikong rainbow table attack, kung saan gumagamit ang mga attacker ng napakalalaking precomputed list ng password-to-hash mappings.

Kung walang mga salt, maaaring ibunyag ng isang na-crack na hash ang bawat user na may parehong password. Sa mga salt, kailangang subukan nang hiwalay ang bawat password guess para sa bawat user.

3. Mabilis na offline guessing

Kapag mayroon nang password database ang mga attacker, maaari silang manghula offline. Ibig sabihin nito, hindi na mahalaga ang iyong login rate limits, CAPTCHA, IP blocking, at monitoring. Maaaring subukan ng attacker ang mga hula sa sarili nilang hardware.

Dito nagiging mahalaga ang pagpili ng algorithm.

Ang mga general-purpose hash tulad ng SHA-256 at SHA-512 ay dinisenyong maging mabilis. Mabuti iyon para sa file integrity at digital signatures. Masama iyon para sa password storage.

Ang mga password-hashing algorithm ay dinisenyong maging mabagal, natutune, at kung minsan ay memory-hard. Pinapayagan ka ng Argon2id, bcrypt, scrypt, at PBKDF2 na i-adjust ang mga cost parameter upang ang bawat hula ay mangailangan ng makabuluhang oras.

Malawak na inirerekomenda ang Argon2id para sa mga bagong system dahil maaari itong i-configure upang mangailangan ng parehong CPU time at memory, na nagpapamahal sa malakihang GPU cracking. Nananatiling karaniwan at katanggap-tanggap ang bcrypt kapag maayos ang configuration, bagama't may mga limitasyon ito tulad ng paghawak sa haba ng password. Ginagamit pa rin ang PBKDF2 sa ilang environment na hinihimok ng compliance, lalo na kung kinakailangan ang FIPS-validated components.

Simple ang prinsipyo: gawing katanggap-tanggap ang bilis ng lehitimong login, habang ginagawang mahal ang bilyun-bilyong hula.

Ano ang hindi ka pinoprotektahan ng hashing laban dito

1. Phishing

Kung ita-type ng user ang kanyang password sa isang pekeng login page, hindi makakatulong ang hashing sa iyong server. Natatanggap ng attacker ang password bago pa ito makita ng iyong system.

Iba ang mga depensa rito: multi-factor authentication, passkeys, edukasyon ng user, domain hygiene, phishing-resistant authentication, at maingat na password reset flows.

Ang password hashing ay backstop para sa mga nakaimbak na secret. Hindi ito depensa laban sa mga user na nalilinlang na ibigay ang mga secret na iyon.

2. Credential stuffing

Nangyayari ang credential stuffing kapag kumukuha ang mga attacker ng mga pares ng username at password na nag-leak mula sa isang serbisyo at sinusubukan ang mga ito sa iba.

Maaaring mahusay ang iyong mga password hash, at maaari pa ring gumana ang credential stuffing kung muling ginagamit ng mga user ang mga password.

Online attack ito laban sa iyong login form, hindi offline attack laban sa iyong database. Kailangan mo ng rate limiting, anomaly detection, breached-password checks, MFA, at makatuwirang lockout policies na hindi lumilikha ng madaling denial-of-service opportunities.

Nalalapat ang parehong praktikal na pag-iisip sa anumang exposed form. Kung sinusuri mo ang iyong authentication surface, sulit basahin kung bakit ang iyong contact form ang pinakamalaking pananagutan mo sa spam; magkaiba ang mekanika, ngunit magkatulad ang aral: kailangan ng public inputs ang abuse controls, hindi lang malinis na backend code.

3. Mga password na nakukuha sa logs o analytics

Nakakatulong lang ang hashing kung mabilis na itinatapon ang plaintext password at hindi kailanman kinokopya sa ibang lugar.

Kabilang sa mga karaniwang kabiguan ang:

• Pag-log ng buong request bodies sa failed login attempts.
• Pagpapadala ng mga password sa error monitoring tools.
• Pag-capture ng password fields sa session replay products.
• Pagsasama ng credentials sa URLs sa mga hindi maayos na reset o migration flows.
• Pag-iimbak ng pansamantalang plaintext passwords sa panahon ng imports.

Ganap na nalalampasan ng mga pagkakamaling ito ang password hashing. Kung mapunta ang plaintext sa logs, backups, data warehouses, o third-party tools, walang kabuluhan ang iyong hash function.

Tratuhin ang password fields bilang toxic data. I-redact ang mga ito bago mag-log. Ibukod ang mga ito sa analytics. Ilayo ang mga ito sa URLs. Limitahan kung sino ang may access sa production traces.

4. Mahinang session security

Pagkatapos ng login, karaniwang nakakatanggap ang browser ng user ng session cookie o token. Kung manakaw ang token na iyon, maaaring hindi na kailanganin ng attacker ang password.

Hindi nagpoprotekta ang password hashing laban sa cross-site scripting, insecure cookies, session fixation, mahinang token generation, o sobrang hahabang session lifetime.

Nararapat sa session cookies ang sarili nilang review: HttpOnly, Secure, angkop na SameSite, short-lived high-risk sessions, at server-side invalidation kapag nagbago ang password. Patuloy ding nagbabago ang mas malawak na privacy at browser landscape, gaya ng tinalakay sa ano ang nagbago para sa cookies noong 2026.

5. Mahinang password reset at account recovery

Maraming account takeover ang hindi nagsisimula sa password. Nagsisimula ang mga ito sa reset flow.

Kung predictable, long-lived, nag-leak sa referrer headers, o ipinadala sa compromised email accounts ang reset tokens, hindi ka maililigtas ng password hashing.

Gumamit ng high-entropy reset tokens, maiikling expiry window, one-time use, at malinaw na user notifications. Dahil madalas na recovery channel ang email, mahalaga rin ang basic domain authentication. Kung itinuturing ng team mo ang DNS records bilang misteryosong seremonya, magsimula sa isang developer-friendly na paglibot sa MX, SPF, DKIM at DMARC.

Ang pagpili ng algorithm: ano ang gagamitin ngayon

Para sa mga bagong application, gamitin ang Argon2id kung mahusay itong sinusuportahan ng iyong platform. Ito ang nagwagi sa Password Hashing Competition at dinisenyo para sa password storage, kabilang ang resistance sa GPU-heavy cracking.

Ganito ang isang makatuwirang modernong hierarchy:

1. Argon2id para sa mga bagong system kung available.
2. bcrypt kapag hindi praktikal ang Argon2id at mature ang suporta para sa bcrypt.
3. scrypt kapag mahusay ang suporta sa memory-hard configuration.
4. PBKDF2 kung kinakailangan dahil sa platform o compliance constraints.

Iwasan ang plain SHA-256, SHA-512, MD5, o homegrown combination tulad ng sha256(password + salt). Ang mabilis na mga hash ay hindi password storage functions. Ang matatalinong custom construction ay kadalasang mas masama kaysa sa boring na standard ones.

Iwasan din ang pag-imbento ng sarili mong password policy batay sa algorithm trivia. Hindi nakikinabang ang mga user sa 12-rule password composition checklist kung itinutulak sila nito sa predictable patterns. Karaniwang mas mahalaga ang mas mahahabang natatanging password, password managers, breached-password screening, at MFA.

Hindi set-and-forget ang cost factors

May mga parameter ang password hashing. May memory, iterations, at parallelism ang Argon2id. May cost factor ang bcrypt. May iteration count ang PBKDF2.

Dapat piliin ang mga value na ito batay sa iyong production environment. Kapag masyadong mababa, mura para sa mga attacker ang manghula. Kapag masyadong mataas, nagiging mabagal ang iyong login system o vulnerable sa denial-of-service.

Ang praktikal na target ay madalas nasa saklaw ng sampu-sampu hanggang ilang daang millisecond kada password verification sa iyong aktwal na servers, depende sa traffic at risk. Maaaring pumili ng mas mataas ang high-security systems. Maaaring kailanganin ng consumer-scale systems ang maingat na capacity planning.

Huwag kumopya ng cost factor mula sa limang taong gulang na blog post. Nagbabago ang hardware. Nagbabago ang libraries. Nagbabago ang traffic mo.

Regular na suriin ang mga parameter at magplano para sa rehashing. Karaniwang pattern ang pag-imbak ng algorithm at mga parameter kasama ng bawat hash. Sa matagumpay na login, kung luma na ang nakaimbak na mga parameter, i-rehash ang isinumiteng password gamit ang mas bagong configuration at i-update ang record.

Peppers: kapaki-pakinabang, ngunit hindi kapalit

Ang pepper ay isang secret value na idinadagdag sa proseso ng password-hashing at iniimbak nang hiwalay sa database, madalas sa isang secrets manager o hardware security module.

Hindi tulad ng salt, dapat manatiling lihim ang pepper.

Maaaring bawasan ng peppers ang pinsala kung mag-leak ang database ngunit hindi ang application secrets. Pinakakapaki-pakinabang ang mga ito sa mature environments na may mahusay na key management. Hindi gaanong kapaki-pakinabang ang mga ito kung kayang nakawin ng parehong attacker ang database at ang application configuration.

Kung gumagamit ka ng pepper, planuhin nang maingat ang rotation. Maaaring kailanganin nitong mag-log in muli ang mga user o mag-reset ng passwords, depende sa design. Ang pepper ay karagdagang layer, hindi dahilan para pahinain ang underlying hash settings.

Ang operational checklist

Kung responsable ka sa isang tunay na system, maikli ang praktikal na checklist:

• Mag-imbak ng mga password gamit lamang ang standard password-hashing algorithm.
• Gumamit ng natatanging random salt para sa bawat password.
• Mas piliin ang Argon2id para sa mga bagong build.
• I-tune ang cost parameters sa hardware na kahawig ng production.
• Itago ang algorithm at mga parameter kasama ng bawat hash.
• Mag-rehash sa login kapag luma na ang mga parameter.
• Huwag kailanman mag-log ng passwords o ipadala ang mga ito sa analytics tools.
• Gumamit ng TLS saanman isinusumite ang credentials.
• Magdagdag ng MFA o passkeys kung makatuwiran ito ayon sa risk.
• Protektahan ang reset flows nang kasingseryoso ng login flows.
• Magkaroon ng incident plan para sa forced resets at user notification.

Hindi glamorous ang password hashing. Plumbing ito. Ngunit ito ang uri ng plumbing na tumutukoy kung ang isang breach ay magiging masakit na insidente o sakunang sakop ang buong user base.

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

💡 Subukan ito: Tingnan kung paano naima-map ang parehong input sa iba't ibang algorithm gamit ang Hash Generator, na ginagawang malinaw ang pagkakaiba sa pagitan ng mabibilis na hash at mga hash na pang-password ang kalidad.

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

Ang tapat na mental model

Ang pinakamahusay na paraan para isipin ang password hashing ay ito:

Hindi pinoprotektahan ng hashing ang password habang tina-type ito ng user. Hindi nito pinoprotektahan ang account pagkatapos mag-log in ang user. Hindi nito pinoprotektahan ang mga user na muling gumagamit ng mga password sa buong web.

Pinoprotektahan nito ang nakaimbak na verifier.

Mukhang makitid iyon, ngunit napakahalaga nito. Nagle-leak ang databases. Nagle-leak ang backups. Nakokopya ang staging systems. Nakakakuha ang vendors ng access na hindi dapat sa kanila. Nananatili ang lumang exports sa object storage nang mas matagal kaysa sa naaalala ng sinuman.

Kapag nangyari iyon, ang disenyo ng iyong password storage ang nagiging pagkakaiba sa pagitan ng pagtanggap ng mga attacker ng mga password at pagtanggap nila ng isang mamahaling guessing problem.

Iyon ang talagang pinoprotektahan sa iyo ng pagha-hash ng password.