Me gusta la idea, pero también tengo muchas preguntas abiertas. No vea esto como una forma de ataque, porque lo escribí tratando de aplicar mi experiencia de autenticación a este nuevo esquema.
Me preocupa (sin ningún orden en particular):
- Uso no autorizado de la clave privada
- Soporte de cliente enriquecido (Outlook, Notes, etc.)
- Uso de varias computadoras
- Protección de clave privada o encriptación (en el cliente)
- Autenticación de solicitudes de generación de claves
- Privacidad
Detalles a continuación. Primero, un resumen de una línea (en negrita cursiva ) y algunas aclaraciones.
1. Uso no autorizado de la clave privada
La clave privada estará protegida por el cliente, con diversos grados de seguridad.
Me preocupa que alguna clave privada se use sin mi consentimiento. Cuando se intenta autenticar, se realizará una operación de firma. Debo recibir una solicitud antes de que se use o, de lo contrario, un script malicioso podría hacer que mi navegador firme un ticket de inicio de sesión y lo envíe. El script Rogue podría provenir de un widget, un complemento u otro XSS. La implementación de este mecanismo variará en cada navegador, e incluso en diferentes plataformas para el mismo navegador, o diferentes versiones, etc. Con una visión un tanto inconsistente, los usuarios corren un mayor riesgo de ser atraídos a aprobar una solicitud de inicio de sesión.
2. Soporte de cliente enriquecido (Outlook, Notes, etc.)
Fue diseñado para trabajar con cuentas de correo web. Los clientes de correo "grandes" de la empresa se quedan un poco atrás.
Para que la ID del navegador funcione, necesita un navegador que lo admita. Mientras tanto, algunos browserid.org emitieron "shim de JavaScript que implementa la funcionalidad faltante utilizando técnicas estándar de HTML5 y rutinas criptográficas implementadas en JavaScript".
Los usuarios de un entorno corporativo que utilizan el cliente de correo electrónico (Outlook, Notes, Thunderbird) serán usuarios tardíos, ya que el protocolo también se implementará en esos clientes. Sin mencionar que Outlook no comparte un almacén de claves con Firefox o Thunderbird con IE.
3. Usando desde múltiples computadoras
Esto lleva a una proliferación de claves privadas, porque el esquema no tiene una autoridad central.
Y hay un problema de movilidad. Tendré que registrarme (generar una clave privada) para cada computadora que use. ¿Cómo voy a eliminar mi clave privada en un quiosco de Internet o en una computadora prestada? Incluso con una sola computadora, ¿cómo revocaré una clave almacenada en una computadora robada? Dado que para un solo usuario, varias claves de firma son válidas (ya que cada una de mis computadoras tiene su propia clave privada válida), desde el punto de vista del proveedor de servicios, cualquier token de acceso firmado por una autoridad conocida debe ser válido.
4. Protección de clave privada o encriptación (en el cliente)
El acceso a la clave debe estar autenticado, lo que hace que las contraseñas vuelvan a aparecer en la imagen.
Puede protegerse con una contraseña (limitando su reutilización maliciosa), pero si alguna vez cambio mi contraseña en algún lugar, no se sincronizará a menos que use alguna red de sincronización basada en navegador / nube. Tener una contraseña para recordar anula un tanto el propósito de este esquema. Es probable que se use la misma contraseña para asegurar cada clave, al igual que la misma contraseña que se usa ahora para autenticarse en varios sitios web.
5. Autenticación de solicitudes de generación de claves
Hay una brecha entre la solicitud de acceso y la generación de claves, que un atacante podría usar para el phishing.
No me queda claro cómo el proveedor de correo electrónico / autoridad de certificación manejará los problemas de CSRF. ¿Cómo sabrán que una solicitud de generación de claves es legítima? ¿Se llenará mi carpeta de correo no deseado con solicitudes de generación de certificados? ¿O será la clave emitida sólo con los servidores de correo electrónico DKIM? ¿Qué pasaría si la solicitud fuera interceptada en su forma SMTP al servidor, podría ser modificada?
6. Privacidad
El uso de una etiqueta permite a browserid.org romper la misma política de origen.
Y el uso de una etiqueta de script para incluir el browserid.js les permite omitir la misma política de origen. BrowserID.org (tendrá el poder de) conocer cada intento de inicio de sesión que realice. O tendrá que alojar el script usted mismo (asumiendo que es autónomo) y actualizarlo si / cuando se detecten fallas de seguridad en él.