En resumen
La leaked password protection hace que Supabase Auth rechace las contraseñas que aparecen en el corpus de filtraciones de Have I Been Pwned. Está disponible en el plan Pro y superiores. El 23 de octubre de 2026 ese corpus contenía password123 2.266.543 veces, y mi Supabase Auth local, con los ajustes por defecto, la aceptó en el registro. No juzga la fortaleza: Lovable2026! apareció 0 veces. Actívela donde pueda y fije una longitud mínima mayor en cualquier caso.
Mi verificador de seguridad de Supabase gratuito lee los ajustes de Auth de un proyecto, y “Protección contra contraseñas filtradas desactivada” es una de sus reglas, junto a “Longitud mínima de contraseña corta”. Esta nota explica qué comprueba realmente el ajuste, con números que saqué del mismo servicio que usa.
¿Qué es la leaked password protection en Supabase?
Es uno de los ajustes de contraseña en los ajustes de Auth de su proyecto en el Dashboard. Cuando está activado, Supabase Auth comprueba cada contraseña nueva con el servicio Pwned Passwords de Have I Been Pwned y rechaza las que aparecen allí. La guía de seguridad de contraseñas de Supabase lo enumera junto a la longitud mínima y los caracteres requeridos, e indica que está disponible en el plan Pro y superiores.
La comprobación nunca envía la contraseña. Pwned Passwords usa una consulta de rango con k-anonimato: el cliente calcula el hash SHA-1 de la contraseña, envía solo los 5 primeros caracteres del hash y compara localmente los sufijos devueltos.
¿Cuánto aparecen las contraseñas comunes en filtraciones?
Ejecuté yo mismo esa consulta de rango el 23 de octubre de 2026, con unas cuantas contraseñas que veo en cuentas de prueba y en datos semilla generados por IA:
| Contraseña | Veces vista en filtraciones |
|---|---|
123456 |
210.461.208 |
qwerty123 |
13.871.714 |
password123 |
2.266.543 |
Password1! |
584.516 |
Welcome1! |
239.099 |
Summer2026! |
45 |
supabase123 |
7 |
Lovable2026! |
0 |
123456 queda fuera del gráfico porque aplastaría todas las demás barras. Las tres últimas filas son lo importante: una contraseña puede no estar en ninguna filtración y seguir siendo fácil de adivinar. La leaked password protection frena el credential stuffing con contraseñas conocidas. No mide la fortaleza.
¿Qué pasa sin ella?
En un stack local de Supabase (CLI 2.109.1, Auth v2.192.0) con los ajustes por defecto, registré un usuario de prueba con password123. Auth respondió 200 y creó el usuario. Lo único que rechazó fue una contraseña de 5 caracteres, con 422 weak_password y el motivo length, porque el mínimo local por defecto es de 6 caracteres.
Así que sin el ajuste, nada se interpone entre un usuario y una contraseña que se ha filtrado millones de veces, aparte de la regla de longitud.
¿Qué conviene ajustar?
- En Pro y superiores: active la leaked password protection. Los usuarios existentes siguen iniciando sesión, y la guía dice que aquellos cuya contraseña no cumpla los nuevos requisitos reciben un
WeakPasswordErrorque explica el motivo, así que puede pedirles que la cambien. - En todos los planes: suba la longitud mínima. La guía califica cualquier valor por debajo de 8 caracteres como no recomendado; la regla de mi verificador sugiere 12 o más.
- Exija clases de caracteres solo si sus usuarios pueden vivir con ello; la longitud hace más que un símbolo obligatorio.
- Añada MFA a las cuentas que importan, y exija la contraseña actual o un nonce de reautenticación para cambiarla; ambos están en la misma guía.
La leaked password protection es uno de varios ajustes de Auth que solo existen en la configuración del proyecto alojado, no en su repositorio. El resto de lo que reviso en una app de Supabase, desde RLS hasta los límites de peticiones en el inicio de sesión, está en mi lista de seguridad para apps Lovable, y lo que cubre Supabase frente a lo que es suyo está en ¿es seguro Supabase?.