Qué debería significar realmente «gestor de contraseñas de código abierto»
Todos los gestores de contraseñas afirman que tus datos están seguros. Esa afirmación es infalsable mientras no puedas leer el código que los cifra. Por eso «código abierto» importa aquí como en pocos otros programas, y por eso conviene interrogar la etiqueta en lugar de creerla.
La parte que debe estar abierta es el cliente
En una arquitectura zero-knowledge, el cifrado ocurre en tu dispositivo antes de transmitir nada. El servidor recibe únicamente texto cifrado. La promesa de seguridad recae por completo en el cliente: la extensión del navegador, la aplicación móvil, la de escritorio.
Un proveedor que publica su servidor pero no su cliente ha publicado la parte que no puede traicionarte y se ha guardado la que sí. Es la mitad equivocada. Si solo puedes auditar un componente, el cliente es el que cuenta.
Tu extensión ya es legible, la cuestión es la honestidad
Algo que poca gente sabe: una extensión de navegador no se compila a código máquina. Un archivo .crx o .xpi es un zip con JavaScript. Cualquiera puede descargarlo y leerlo hoy mismo, minificado pero perfectamente analizable.
Publicar el código de una extensión no revela nada que un atacante no pudiera obtener ya. Lo que cambia es la honestidad: código legible, nombres de variables reales, comentarios que explican el razonamiento y un historial que muestra qué cambió y cuándo.
Cuatro preguntas para cualquier proveedor
- ¿Se publica el cliente o solo el servidor? En el cliente es donde se manejan tus secretos.
- ¿Está la criptografía en el repositorio publicado? Un repositorio con la interfaz que importa el cifrado desde un paquete cerrado es puro teatro.
- ¿Lleva cada versión su etiqueta? Sin una etiqueta que corresponda a lo que hay en la tienda, no puedes comprobar que el código publicado sea el que instalaste.
- ¿Hay una política de seguridad? Un proyecto que busca escrutinio publica cómo informar de un fallo y a qué se compromete a cambio.
Qué publica SandPass
La extensión de SandPass y toda su criptografía son públicas bajo licencia GPL-3.0 en github.com/sandprivacy/sandpass-extension. Incluye:
- La extensión completa: popup, panel lateral, service worker y autocompletado.
@sandpass/crypto: derivación de claves, cifrado AES-256-GCM, cliente OPAQUE, TOTP y generación de contraseñas.@sandpass/core: el cliente de la API y el servicio de bóveda.
Cada versión lleva su etiqueta, y esa etiqueta es el árbol de código exacto del que salió la compilación. Si encuentras una divergencia entre una etiqueta y la extensión que instalaste desde la tienda, eso es un problema de seguridad y queremos saberlo.
Qué no publica SandPass, y por qué lo decimos
El backend no es público. Preferimos decirlo con claridad antes que dejar que «código abierto» sugiera más de lo que abarca.
El razonamiento: en un modelo zero-knowledge el servidor solo recibe datos ya cifrados, y el cliente publicado basta para comprobarlo. Publicar el servidor tampoco probaría qué código se ejecuta realmente en producción, porque seguirías confiando en nosotros. La auditoría que importa es la que puedes hacer tú, y recae sobre el cliente.
También publicamos lo que aceptamos
Nuestra política de seguridad enumera las limitaciones que conocemos y hemos aceptado deliberadamente, incluidas restricciones de Manifest V3 que comparte cualquier gestor de contraseñas en extensión, como que material de clave pase por chrome.storage.session.
Preferimos declararlas nosotros a que alguien las descubra y se pregunte qué más quedó sin mencionar. Un proveedor que no tiene nada que divulgar suele ser un proveedor que no ha mirado.
Léelo antes de confiar
No hace falta ser criptógrafo. Abre el repositorio, mira si los comentarios explican un razonamiento o parafrasean el código, comprueba si las versiones llevan etiqueta, lee la política de seguridad. Esas señales dicen mucho sobre la seriedad de un equipo respecto a lo que te pide confiarle.