Generador de hash bcrypt para contraseñas
Bcrypt está diseñado para almacenar contraseñas: lento a propósito, y con sal automática para que dos contraseñas idénticas nunca produzcan el mismo hash.
Leer esa extraña cadena que te da
Un hash bcrypt parece ruido de línea, pero tiene una anatomía fija que vale la pena conocer. Empieza con un marcador de versión como $2a$ o $2b$, seguido del factor de coste que elegiste, luego veintidós caracteres de la sal aleatoria, y por último los treinta y un caracteres del propio hash. Todo lo que un verificador necesita viaja dentro de esa única cadena — por eso todo cabe en una sola columna de base de datos, y por eso generar un hash para la misma contraseña dos veces da dos cadenas distintas que, no obstante, son ambas válidas. La sal difiere cada vez, así que la salida difiere cada vez; cuando tu backend comprueba más tarde un inicio de sesión, lee la sal de vuelta desde la cadena guardada, hashea el intento con ella, y compara el resultado.
Dónde usarías realmente esta página
La mayor parte del tiempo el hasheo con bcrypt ocurre dentro de tu aplicación, no en un navegador — pero hay momentos en los que un hash hecho a mano es exactamente lo que necesitas. Poblar una base de datos de pruebas con cuentas cuyas contraseñas conoces. Rescatar una cuenta de administrador bloqueada escribiendo un hash nuevo directamente en la tabla de usuarios. Comprobar qué forma de cadena va a producir una librería antes de dimensionar la columna para ella. En todos estos casos pegas una contraseña, copias el hash, y lo colocas donde tu código de inicio de sesión espera uno. Una cosa que nunca hay que hacer: comparar hashes como cadenas de texto en tu propio código. Debido a la sal, la misma contraseña produce hashes distintos — la verificación tiene que pasar por la función de comparación de tu librería, que sabe cómo leer la sal de vuelta.
Elegir un coste con el que puedas vivir
Cada escalón en el factor de coste duplica el trabajo, tanto para ti como para un atacante. Ocho es rápido y es mejor dejarlo solo para compatibilidad heredada; diez, el valor predeterminado aquí, es la opción habitual en producción; doce compra tranquilidad si los inicios de sesión son poco frecuentes; catorce tarda segundos incluso en generarse. Un aviso justo sobre el tiempo: esta página ejecuta una implementación en JavaScript puro, que es más lenta que el código nativo de tu servidor, así que trata el retraso que notas aquí como un límite superior y no como un benchmark — mide en la máquina que realmente va a gestionar los inicios de sesión. Y ya que un hash solo es tan bueno como lo que le metes, el generador de contraseñas produce una entrada fuerte, mientras que cualquier cosa que no sea una contraseña — archivos, documentos, texto plano — pertenece en cambio al generador de hash SHA.
Por qué bcrypt en lugar de un hash normal
Un hash SHA normal de una contraseña se puede atacar por fuerza bruta rápidamente en hardware moderno. Bcrypt es deliberadamente lento —el factor de coste controla exactamente cuánto— y añade sal automáticamente, de modo que la misma contraseña nunca produce dos veces el mismo hash almacenado. Por eso sigue siendo una opción estándar para guardar contraseñas en el servidor.
¿Qué factor de coste debería usar?
10–12 es un valor habitual por defecto en 2026 — lo bastante alto para resistir la fuerza bruta, y lo bastante bajo para no ralentizar de forma notable los inicios de sesión reales. Un coste mayor es más seguro pero más lento de calcular en cada inicio de sesión.
¿Puedo usar esto para hashear un documento o un texto largo?
No — bcrypt trunca la entrada a partir de unos 72 bytes y está diseñado específicamente para contraseñas. Para hashear texto o archivos de forma general, usa en su lugar el generador de hash SHA.
¿Se envía mi contraseña a algún sitio?
No — el hasheo se ejecuta íntegramente en tu navegador con JavaScript. No se sube nada.
