La primera vez que envié un sistema de inicio de sesión, hice lo que todos los tutoriales de esa época me decían que hiciera: almacenado md5($password) en la tabla de usuarios y siguió adelante. Funcionó y fue silenciosamente un desastre. Años de creación de autenticación en complementos de WordPress y aplicaciones de Laravel más tarde, tengo un respeto mucho más saludable por la brecha entre " la verificación de contraseña pasa y quot; y " las contraseñas son seguras si esta base de datos se filtra." Bcrypt es la herramienta que cierra la mayor parte de esa brecha y es el valor predeterminado en casi todos los marcos a los que accedo. Entonces construí un generador bcrypt según Toolz.dev que procesa una contraseña con un factor de costo que usted controla, verifica una contraseña con un hash existente y lo hace todo en su navegador para que nunca se envíe nada que escriba a ninguna parte. Esta es la guía para ello y para criptarse.
TL;Dr: Bcrypt convierte una contraseña en un hash salado y deliberadamente lento de 60 caracteres para que una base de datos filtrada no sea una lista de contraseñas filtrada. La herramientaz generador bcrypt aplica hash a cualquier contraseña con un factor de costo ajustable (4 a 31), verifica una contraseña con un hash que pega y muestra la versión, el costo y la sal que analizó. Produce el estándar
$2b$formatee que OpenBSD, PHPpassword_hash, las bibliotecas Bcrypt de Laravel y Node aceptan y se ejecuta completamente del lado del cliente.
¿qué es bcrypt?
Bcrypt es una función de hash de contraseñas diseñada por Niels Provos y David Mazieres y presentada en su artículo USENIX de 1999 "Un esquema de contraseña adaptable al futuro". Está construido sobre el cifrado de bloque Blowfish, pero con un giro: en lugar de cifrar datos, ejecuta el paso de configuración de claves de Blowfish' una y otra vez, utilizando la contraseña y una sal aleatoria como material clave. El resultado es un hash unidireccional que es barato de calcular una vez y costoso de calcular mil millones de veces, que es exactamente la propiedad que necesita el almacenamiento de contraseñas.
Eso " caro a propósito" La idea es el corazón de esto. Un hash de propósito general como SHA-256 está diseñado para ser rápido, porque las sumas de verificación y las comprobaciones de integridad quieren velocidad. El hash de contraseña quiere lo contrario. Si un atacante roba su base de datos, lo único que se interpone entre ellos y cada contraseña de texto sin formato es cuánto tiempo lleva adivinar. Un hash rápido permite que una GPU moderna pruebe miles de millones de candidatos por segundo; un hash bcrypt con un costo máximo razonable de unos pocos miles por segundo por núcleo. Mismo archivo filtrado, resultado tremendamente diferente.
Bcrypt ha sobrevivido más de dos décadas porque acertó en los fundamentos y porque es adaptable. El factor de costo significa que el mismo algoritmo que se ajustó para el hardware de 1999 se puede marcar para el hardware de 2026 sin cambiar nada más. Sigue siendo una opción recomendada en el Hoja de referencia de almacenamiento de contraseñas OWASP, y es el valor predeterminado listo para usar en Laravel, Spring Security y muchas otras pilas en las que trabajo. Si desea obtener más información sobre por qué los hashes rápidos están mal para este trabajo, el herramientas en línea de privacidad de datos la guía cubre el razonamiento que empujó a toda la industria hacia el hash lento y salado.
¿qué contiene un hash bcrypt?
Una de las cosas más interesantes de bcrypt es que su salida se describe a sí misma. Toma un hash real:
$2b$12$R9h/cIPz0gi.URNNX3kh2OPST9/PgBkqquzi.Ss7KIUgO2t0jWMUW
Lea de izquierda a derecha, divida los signos del dólar y le indicará todo lo necesario para verificar una contraseña:
| prado | ejemplo | significación |
|---|---|---|
| versión | 2b |
La variante bcrypt. 2b es el formato OpenBSD corregido actualmente |
| precio | 12 |
El factor de trabajo. La configuración de claves ejecuta 2^12 = 4096 iteraciones |
| Sal | R9h/cIPz0gi.URNNX3kh2O |
22 caracteres de Base64 personalizado, decodificando en 16 bytes aleatorios |
| Digesto | PST9/PgBkqquzi.Ss7KIUgO2t0jWMUW |
31 caracteres que codifican la salida bcrypt de 23 bytes |
Debido a que la sal y el costo viven dentro de la cuerda, la verificación no necesita nada más. Cuando pegas un hachís en el generador bcrypt modo de verificación, lee el costo y la sal directamente de la cadena, vuelve a calcular el resumen con esa sal exacta y compara. No hay una columna de sal separada para administrar, lo cual es una de las razones por las que bcrypt es tan agradable de almacenar: es un único campo opaco en la tabla de usuarios.
Vale la pena señalar el alfabeto Base64 personalizado, porque hace tropezar a la gente. Usos de Bcrypt ./A-Za-z0-9, que es un orden diferente al estándar Base64. Una sal bcrypt no es una cadena Base64 estándar, así que no intente decodificarla con una herramienta Base64 genérica y espere bytes significativos. Si tiene curiosidad sobre la variante estándar utilizada en cualquier otro lugar, el codificación base64 el guía recorre el alfabeto normal y dónde aparece.
¿cómo genero un hash bcrypt?
En la herramienta hay tres pasos: escriba una contraseña, elija un costo, haga clic en Generar. Debajo del capó, generar un hash hace más de lo que parece. Primero se crea una sal aleatoria criptográficamente fuerte de 16 bytes utilizando la API Web Crypto. Luego, bcrypt ejecuta su costoso programa de claves, sembrando Blowfish con la contraseña y salt e iterando 2^tiempos de costo. Finalmente cifra una cadena mágica fija ("OrpheanBeholderScryDoubt") 64 veces con el estado de cifrado resultante y codifica Base64 la salida. Todo ese baile produce el hash de 60 caracteres.
La sorpresa más común es que aplicar dos veces la misma contraseña da dos hashes diferentes. Eso es correcto e intencional. Cada hash obtiene su propia sal aleatoria, por lo que dos usuarios eligen hunter2 termina con valores almacenados completamente diferentes. Un atacante que roba la tabla no puede decir que dos cuentas comparten una contraseña y no puede reutilizar una tabla precalculada en todas las cuentas. Si desea reproducir un hash específico para realizar pruebas, proporciona la cadena de sal completa en lugar de un costo mínimo, que es exactamente lo que hace el modo de verificación internamente.
En el código de tu aplicación nunca ensamblas nada de esto a mano. Llamas a la biblioteca:
// PHP
$hash = password_hash($password, PASSWORD_BCRYPT, ['cost' => 12]);
// Node with bcrypt / bcryptjs
const hash = await bcrypt.hash(password, 12)
// Laravel
use Illuminate\Support\Facades\Hash;
$hash = Hash::make($password); // bcrypt by default
La herramienta Toolz es para los momentos relacionados con ese código: verificar la cordura de cómo se ve un hash a un costo determinado, generar un hash conocido para una sembradora o un dispositivo de prueba, o confirmar que un hash que encontró en una configuración coincide con la contraseña que cree que sí.
¿Cómo elijo un factor de costo?
El factor de costo es la única perilla en la que debe pensar, y la respuesta honesta es " medir, no copiar." La regla general de OWASP es que un solo hash debería tardar alrededor de un cuarto de segundo en su hardware de producción. Ese objetivo equilibra dos fuerzas opuestas: demasiado bajo y abaratas, demasiado alto y cada inicio de sesión legítimo paga el precio, lo cual importa cuando un punto final ocupado tiene hash en cada solicitud.
Debido a que el costo es una potencia de dos, cada paso duplica el trabajo. El costo 11 es dos veces más lento que el costo 10, el costo 12 es cuatro veces más lento. En el hardware de servidor típico de la década de 2020, el costo de 10 a 12 aterriza en el vecindario correcto, razón por la cual los marcos están predeterminados allí. La herramienta muestra una estimación aproximada del tiempo a medida que arrastra el control deslizante para que pueda sentir qué tan rápido se compone el costo, pero trátelo como una guía relativa, no como un punto de referencia de su servidor. El número real depende de su CPU y la única forma de saberlo es el tiempo password_hash en la caja que lo ejecutará.
Un patrón práctico que vale la pena conocer: debido a que el costo se almacena dentro de cada hash, puede aumentarlo con el tiempo sin necesidad de migrarlo. Al iniciar sesión correctamente, tendrá el texto sin formato en la mano por un momento, por lo que verificará si el costo del hash 's almacenado está por debajo de su objetivo actual y, de ser así, lo repetirá y actualizará. PHP expone esto directamente a través de password_needs_rehash. Significa que su seguridad sigue el ritmo del hardware sin necesidad de restablecer la contraseña.
Bcrypt frente a SHA-256, Argon2 y scrypt
La comparación que más importa es bcrypt frente a un hash rápido y simple y frente a las funciones más nuevas de memoria dura. Así es como se alinean para el almacenamiento de contraseñas:
| Función | Salado | Lento a propósito | Memoria dura | ¿Bien para contraseñas? |
|---|---|---|---|---|
| MD5/SHA-256 | No (por sí solo) | prohibido | prohibido | No, demasiado rápido |
| bcrypt | Sí, incorporado | Sí, costo sintonizable | prohibido | Sí, recomendado |
| scrypt | sí | sí | sí | sí |
| Argón2id | sí | sí | sí | Sí, preferido para sistemas nuevos |
Un SHA-256 desnudo con contraseña, incluso salado, es la herramienta incorrecta: está diseñado para la velocidad, por lo que una base de datos filtrada de hashes SHA-256 salados cae rápidamente a una GPU. Si solo necesita un resumen rápido para una suma de verificación o una clave de caché en lugar de una contraseña, eso es lo que dice generador hash Es para, y la distinción es el punto. Argon2id, el ganador del Concurso de hash de contraseñas de 2015, agrega dureza de memoria, lo que resiste el hardware personalizado que puede acelerar bcrypt, y es la primera opción para un sistema completamente nuevo donde controlas el tiempo de ejecución. Pero bcrypt no está obsoleto. Está probado en batalla, es el valor predeterminado en las herramientas que uso a diario, y elegirlo es una decisión acertada, especialmente cuando su marco lo envía. El error a evitar no es "bcrypt en lugar de Argon2," es " un hash rápido en lugar de cualquiera de ellos." Para un recorrido más amplio por las utilidades de seguridad que se combinan con el hash, el Herramientas de productividad para desarrolladores la guía tiene el mapa.
¿qué pasa con el límite de 72 bytes y otros gotchas?
Bcrypt solo lee los primeros 72 bytes de la contraseña. Cualquier cosa que pase y que se ignore silenciosamente, lo que para las contraseñas normales nunca importa, pero puede morder una frase de contraseña muy larga, especialmente una con caracteres UTF-8 de múltiples bytes donde el recuento de bytes aumenta más rápido que el recuento de caracteres. La herramienta le advierte cada vez que su entrada cruza 72 bytes UTF-8, por lo que el truncamiento nunca es una sorpresa silenciosa. Algunos sistemas sortean el límite al aplicar hash previo a la contraseña con SHA-256 y Base64 antes de entregársela a bcrypt, que pliega una contraseña arbitrariamente larga en una entrada corta fija; Si hace esto, hágalo de manera consistente tanto al registrarse como al iniciar sesión.
El otro gotcha es el prefijo de versión. Verás $2a$, $2y$y $2b$ en la naturaleza. $2a$ era el original, $2y$ se introdujo una etiqueta específica de PHP después de que se encontró un error de extensión de signo en algunas implementaciones, y $2b$ es la versión actual corregida de OpenBSD. Para nuevos hashes que deseas $2b$, que es lo que produce esta herramienta. Los tres verifican de manera idéntica las contraseñas ASCII ordinarias; las diferencias solo surgen con bytes particulares que no son ASCII cerca del límite de 72 bytes. Cuando pegas un token en una herramienta que también inspecciona credenciales estructuradas, como Decodificador JWT, tenga en cuenta que un hash bcrypt no es un token que decodifica para leer una carga útil; es un resumen unidireccional sin nada que revelar.
Donde el generador bcrypt encaja en un flujo de trabajo real
Por sí solo, un hash es solo la mitad de la historia, por lo que el mezclador se ubica junto a las otras herramientas de credenciales que mantengo abiertas. Cuando estoy sembrando una base de datos de prueba o configurando una cuenta de demostración, genero la contraseña con generador de contraseñas, comprueba que despeja una barra de fuerza sensible con el comprobador de fuerza de contraseña, y sólo entonces ejecútelo generador bcrypt para obtener el hash almacenado. Ese orden importa: una contraseña aleatoria fuerte detrás de un hash bcrypt de costo 12 es realmente difícil de descifrar, mientras que una contraseña débil detrás del mismo hash todavía cae en un ataque de diccionario, porque el atacante solo tiene que adivinar el puñado de candidatos probables en lugar de todo el espacio de claves. El factor costo le da tiempo; la entropía de la contraseña es contra lo que se gasta ese tiempo.
El modo de verificación gana su lugar durante la depuración. Cuando un inicio de sesión falla misteriosamente en la preparación, la forma más rápida de aislar el problema es pegar el hash almacenado y la contraseña que cree que es correcta y ver si coinciden. Una coincidencia significa que el error está aguas arriba, en la forma en que la contraseña llega a la verificación; una discrepancia significa que el hash almacenado se escribió con una contraseña diferente o una codificación destrozada. Cualquiera de las respuestas le evita adivinar y, debido a que todo se ejecuta localmente, puede hacerlo con un hash real extraído de una base de datos sin que ese hash salga de su máquina. Es el mismo principio del lado del cliente detrás de cada herramienta del sitio, y para cualquier cosa que toque las credenciales no es una delicia, es el requisito.
Preguntas frecuentes
¿es seguro aplicar una contraseña real en este generador de bcrypt?
Sí, porque el hash ocurre completamente en su navegador y no se envía nada a ninguna parte. Puede confirmar esto en la pestaña Red de sus herramientas de desarrollo: generar un hash no realiza ninguna solicitud. Dicho esto, la pestaña del navegador no es un administrador de contraseñas, así que evite pegar las credenciales en vivo de una cuenta de producción en cualquier página web que no haya creado y cierre la pestaña cuando haya terminado.
¿por qué la misma contraseña produce un hash bcrypt diferente cada vez?
Porque bcrypt genera una nueva sal aleatoria para cada hash y la mezcla con el resultado. Esta es una característica: dos usuarios que eligen la misma contraseña aún obtienen diferentes hashes almacenados, por lo que un atacante no puede detectar contraseñas compartidas ni reutilizar una tabla precalculada. La verificación aún funciona porque la sal se almacena dentro de la cadena hash.
¿qué factor de costo debo usar para bcrypt?
Utilice el costo más alto que su flujo de inicio de sesión pueda tolerar sin un retraso molesto, que para la mayoría de los servidores de la década de 2020 cuesta de 10 a 12. OWASP sugiere que un solo hash debería tomar aproximadamente un cuarto de segundo en su hardware de producción. Debido a que cada paso duplica el trabajo, mida en su propio servidor en lugar de copiar un número y aumente el costo cada pocos años a medida que el hardware se acelera.
¿se puede revertir un hash bcrypt a la contraseña?
No. Bcrypt es una función unidireccional, por lo que no existe una forma matemática de convertir un hash nuevamente en la contraseña original. El único ataque es adivinar: un atacante aplica contraseñas candidatas con el mismo sal y costo y busca una coincidencia. Es por eso que el factor costo importa, porque establece qué tan costosa es cada suposición y por qué las contraseñas únicas y sólidas más un costo alto hacen que adivinar no sea práctico.
¿bcrypt seguirá siendo seguro en 2026 o debería cambiarme a Argon2?
Bcrypt todavía se considera seguro para el almacenamiento de contraseñas y sigue siendo una opción recomendada en la hoja de trucos de almacenamiento de contraseñas de OWASP. Se prefiere Argon2id, el ganador del concurso de hash de contraseñas de 2015, para los nuevos sistemas en los que controlas el tiempo de ejecución porque también resiste ataques de GPU y hardware especializado. Bcrypt es una buena opción, especialmente cuando su marco lo envía como predeterminado; el verdadero error es utilizar un hash rápido de uso general en lugar de cualquier función de hash de contraseñas.
¿cuál es el límite de 72 bytes en bcrypt?
Bcrypt solo lee los primeros 72 bytes de la contraseña codificada UTF-8, por lo que se ignoran los caracteres que no sean así. Para contraseñas normales esto nunca importa, pero una frase de contraseña muy larga se puede truncar, razón por la cual algunos sistemas prehash la contraseña con SHA-256 antes de bcrypt. Esta herramienta le avisa siempre que su entrada supere los 72 bytes, por lo que el truncamiento nunca es una sorpresa.
¿qué significan los prefijos $2a$, $2b$ y $2y$?
Son etiquetas de versión para el formato de salida bcrypt. $2a$ era el original, $2y$ era una solución específica de PHP para un error de extensión de signo y $2b$ es la versión OpenBSD corregida actualmente. Para nuevos hashes $2b$ es correcto, que es lo que produce esta herramienta. Los tres verifican de manera idéntica las contraseñas ASCII; las diferencias solo aparecen con ciertos bytes que no son ASCII en el límite de 72 bytes.
¿bcrypt es lo mismo que el cifrado?
No. El cifrado es reversible con una clave, por lo que los datos cifrados se pueden descifrar al original. El hashing de Bcrypt es unidireccional y deliberadamente lento, y está destinado únicamente a verificación: nunca necesita recuperar la contraseña, solo para confirmar que alguien escribió la correcta. Almacenar contraseñas con cifrado en lugar de hash es un antipatrón, porque quien tenga la clave puede recuperar todas las contraseñas.
