Hashing de contrasenya
Emmagatzemar les contrasenyes dels usuaris és una de les pitjors coses possibles que podeu fer en text pla i un dels errors de seguretat més comuns. La solució ha existit des de fa dècades: hash de contrasenyes amb algorismes lents i durs de memòria, però la diferència entre les implementacions bones i dolentes és enorme, i la majoria de les infraccions de dades revelen opcions deficients.
El cos complet de l'article es proporciona en anglès a continuació.
Password hashing és la pràctica d'emmagatzemar una transformació unidireccional de la contrasenya d'un usuari en lloc de la pròpia contrasenya. Quan l'usuari inicia sessió, s'aplica la mateixa transformació a la seva entrada i es compara amb el valor emmagatzemat. Si es viola la base de dades emmagatzemada, l'atacant té hashes, no contrasenyes, i la recuperació dels originals hauria de ser computacionalment inviable.
Aquesta és la teoria. La pràctica va des de "funciona tal com s'anunciava" fins a "pot haver estat també text sense format", depenent de quin algorisme i paràmetres s'hagin escollit.
El que necessita un bon hash de contrasenya
- One-way. Conèixer el hash no hauria de revelar res útil sobre el hash. password.
- Salted. Cada usuari té una sal aleatòria única barrejada al hash. Evita que les taules de l'arc de Sant Martí precalculades i garanteix que les contrasenyes idèntiques produeixin hash diferents.
- Slow. Un únic càlcul de hash hauria de trigar una fracció de segon significativa al maquinari atacant. La força bruta de milers de milions per segon és el que derrota els hash ràpids.
- Memory-hard. Cada hash hauria de requerir una memòria RAM important, derrotant la paral·lelització GPU i ASIC que prospera amb una petita memòria per instància. ajustable cap amunt a mesura que el maquinari es fa més ràpid.
Les eleccions equivocades
Algorismes que no heu d'utilitzar mai per a l'emmagatzematge de contrasenyes:
- MD5. Criptogràficament s'ha trencat a deu milers de milions de segons. al maquinari de consum.
- SHA-1, SHA-256. Hash criptogràfics ràpids dissenyats per comprovar la integritat, no per emmagatzemar contrasenyes. Força bruta a milers de milions per segon a les GPU.
- Econtrasenyes xifrades. Si podeu desxifrar-les a text sense format, un atacant que roba la clau també ho pot fer. El hashing és la resposta; l'encriptació no és.
- Plaintext. Encara passa el 2026. Tota infracció de la contrasenya de text sense format es pot prevenir. algorismes:
- bcrypt (1999). Factor de cost ajustable (rondes de càlcul). Limitat a contrasenyes de 72 bytes. No dura la memòria, de manera que les GPU poden atacar-la de manera eficient, però un factor de cost raonable encara fa que els atacs siguin cars. Ampli desplegament, fàcil d'utilitzar correctament.
- scrypt (2009). Dur la memòria. Cost de memòria configurable, paral·lelisme i cost de CPU. Més complex que bcrypt; de vegades mal configurat.
- Argon2 (Guanyador del Concurs d'hashing contrasenya 2015). Tres variants: Argon2d (depenent de les dades, resistent als atacs de la GPU però vulnerable als canals laterals), Argon2i (independent de les dades, resistent al canal lateral), Argon2id (híbrid: el valor predeterminat recomanat). Modern, ben estudiat, l'elecció adequada per a sistemes nous. Actualment,
OWASP recomana Argon2id amb almenys 19 MB de memòria, un nombre d'iteracions de 2 i un paral·lelisme d'1. Per als sistemes on Argon2 no està disponible, bcrypt amb un cost ≥ 10 o scrypt amb paràmetres de caiguda adequats són acceptables. "lent" significa a la pràctica
El factor de cost de 10 en bcrypt significa aproximadament 100 ms per hash al maquinari modern. Per a un usuari legítim que inicie sessió, això és imperceptible. Per a un atacant que intenta forçar 100 milions de contrasenyes d'una base de dades filtrada, són 100 milions × 100 ms = 116 dies de temps de GPU per passada a través d'una llista de paraules raonable. Combinades amb una sal única per usuari, les taules grans de l'arc de Sant Martí són inútils.
Per a un hash ràpid com SHA-256 sense sal, la mateixa operació triga uns quants minuts al mateix maquinari.
Maneig de sal
- PRNG és generat per l'usuari. Creation
- 16 bytes és suficient (128 bits d'aleatorietat)
- Salt s'emmagatzema al costat del hash, no secret: la seva feina és ser única, no oculta. una única cadena
Pepper: extra
A opcional pepper és un valor secret de tot el lloc afegit a l'entrada hash, emmagatzemat per separat de la base de dades (en un HSM, una caixa de claus o una configuració d'aplicació). Si s'aboca la base de dades, però el pebre no ho és, els hash són irrecuperables fins i tot amb la sal de l'usuari, perquè l'atacant no té el pebre. Pepper és una addició útil de cinturó i tirants per a sistemes d'alt valor.
Actualitzar els hash de manera segura
Quan canvieu els paràmetres o migreu algorismes, no podeu tornar a utilitzar el hash sense la contrasenya original. L'enfocament estàndard:
- Ecada registre d'usuari emmagatzema el seu algorisme de hash actual, els paràmetres, la sal i el hash.
- En iniciar la sessió, verifiqueu amb el hash emmagatzemat amb els seus paràmetres originals.
- I Si la verificació té èxit i els paràmetres no estan actualitzats, torneu-los a actualitzar i actualitzar-los. record.
En uns quants mesos d'usuaris actius, la base de dades passa a nous paràmetres sense forçar el restabliment de la contrasenya.
Què significa això per als usuaris
Per als usuaris finals, l'efecte pràctic: fins i tot quan s'incompleix una base de dades, una contrasenya única forta (administrada) hashing al servidor significa que la contrasenya roman efectivament secreta. Les contrasenyes febles s'esquerden fins i tot a partir de bases de dades ben hash; l'usuari és la variable que un desenvolupador no pot controlar.
Preguntes freqüents
- Per què bcrypt està limitat a 72 caràcters?
- Detall històric de la implementació del xifratge Blowfish subjacent. Les entrades més llargues es trunquen. La majoria dels usuaris no s'adonen; una frase de contrasenya aleatòria de 16 caràcters està molt per sota del límit. Per als sistemes que volen una longitud de contrasenya il·limitada, Argon2 no té aquesta restricció.
- He de salpebrar les meves contrasenyes?
- La sal és necessària (i qualsevol biblioteca de bona reputació ho fa automàticament). Pepper és opcional però valuós per a sistemes d'alta seguretat. El compromís: gestionar el pebrot com a secret a llarg termini fora de la base de dades afegeix complexitat operativa. La majoria d'aplicacions emmagatzemen sal + hash; les més grans emmagatzemen sal + haixix + haixix derivat del pebre.
- Argon2 és sempre millor que bcrypt?
- Per a sistemes nous, sí. Argon2 té una durada de memòria (resistent a la GPU/ASIC), no té límit de 72 caràcters i va guanyar el concurs de hashing de contrasenyes per bones raons. bcrypt encara és acceptable quan Argon2 no està disponible o les restriccions organitzatives prefereixen l'estàndard més antic. Per als sistemes heretats que utilitzen bcrypt amb un cost ≥ 10, la urgència per migrar és baixa.
- Quant de temps hauria de trigar a utilitzar una contrasenya?
- OWASP suggereix uns 100-500 ms al maquinari del servidor. Més ràpid significa més feble contra els atacants; més lent comença a afectar l'experiència d'inici de sessió legítima. El nombre correcte depèn del vostre trànsit: els serveis de gran volum trien un cost més baix; Els serveis d'alta seguretat amb tarifes d'inici de sessió baixes poden triar més alts.
- Puc emmagatzemar les contrasenyes xifrades en lloc d'utilitzar hash?
- No ho facis. El xifratge és reversible, la qual cosa significa que la clau de xifratge ha d'existir en algun lloc on pugui accedir l'aplicació. Si es viola la base de dades, sovint també ho és la clau i heu emmagatzemat de manera efectiva el text sense format. La irreversibilitat del hashing és el punt: fins i tot la vostra pròpia aplicació no pot recuperar la contrasenya, que és la propietat de seguretat.