Hoy, el World Wide Web Consortium (W3C) aprobó WebAuthn, un nuevo estándar de autenticación que busca reemplazar la contraseña como una forma de proteger sus cuentas en línea. Anunciado por primera vez el año pasado, WebAuthn (que significa Autenticación Web) ya es compatible con la mayoría de los navegadores, incluidos Chrome, Firefox, Edge y Safari. Su publicación como estándar oficial de la web debería allanar el camino para una adopción más amplia por parte de los sitios web individuales.
|
etiquetas: webauthn , autentificación
la biometría en todo caso reemplaza al usuario, no a la contraseña.
webauthn.org/
-----------------------
Register start:
Sending Message to Server:
>>>>>>>>>>>>>>>>
{"username":"KickAss","displayName":"KickAss"}
>>>>>>>>>>>>>>>>
Received Message from Server:
<<<<<<<< [ STATUS 200 ] <<<<<<<<
{"status":"ok","errorMessage":"","rp":{"name":"WebAuthn.org"},"user":{"name":"KickAss","id":"mEyeuRyfmPQ8VjW2Q9-x6Q","displayName":"KickAss"},"challenge":"mH-F1Lz5bdv4tP-WqTRrtlUGXuLZw7FsC4M71gexV4RBGG2wwAx6NEi4YeK7foL7svkKmKUSwMRFgYxAozhgHw","pubKeyCredParams":[{"type":"public-key","alg":-7},{"type":"public-key","alg":-257}],"timeout":60000,"attestation":"direct"}
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
WebAuthn navigator.credentials.create() options:
[CreateOptions] {
rp: {
name: "WebAuthn.org",
},
user: {
name: "KickAss",
id: [ArrayBuffer] (16 bytes)
98 4C 9E B9 1C 9F 98 F4 3C 56 35 B6 43 DF B1 E9,
displayName: "KickAss",
},
challenge: [ArrayBuffer] (64 bytes)
98 7F 85 D4 BC F9 6D DB F8 B4 FF 96 A9 34 6B B6
55 06 5E E2 D9 C3 B1 6C 0B 83 3B D6 07 B1 57 84
41 18 6D B0 C0 0C 7A 34 48 B8 61 E2 BB 7E 82 FB
B2 F9 0A 98 A5 12 C0 C4 45 81 8C 40 A3 38 60 1F,
pubKeyCredParams: [
{
type: "public-key",
alg: -7,
},
{
type: "public-key",
alg: -257,
},
],
timeout: 60000,
attestation: "direct",
}
Waiting for user presence...
Register start:
Sending Message to Server:
>>>>>>>>>>>>>>>>
{"username":"KickAss","displayName":"KickAss"}
>>>>>>>>>>>>>>>>
Received Message from Server:
<<<<<<<< [ STATUS 200 ] <<<<<<<<
{"status":"ok","errorMessage":"","rp":{"name":"WebAuthn.org"},"user":{"name":"KickAss","id"… » ver todo el comentario
Por otro lado, esto suena a que los navegadores se convierten en proveedores de autenticación, más difícil lo veo aún.
Si no se han implantado ya a nivel general es porque la gente gente no está por la labor de pagar 100€ por un par de yubis.
Vamos, que el que lo quiera lo tiene disponible y más que probado y testado como el estándar de seguridad más alto.
Ni de coña uso un dispositivo de hardware para autenticarme...
Y (a no ser que lo haya entendido mal) ME CAGO en la W3C por proponer algo que todavía más permite a empresas localizarme y por cargarse en mi privacidad!!!
Para evitar que alguien te lo robe y pueda utilizarlo, deberían protegerlo con una contraseña...
Un dni electrónico, con una acreditada autoridad de certificación que no controlan empresas privadas, es mejor solución.
Me parece que el doble factor de auténticacion es de lejos más garantista y seguro para los usuarios.
support.mozilla.org/en-US/kb/privacy-web-authentication?as=u&utm_s
NUNCA!!!
Así funciona la administración de nuestro país. Y encima esa web habrá costado centenares de miles de euros que a saber dónde habrán ido a parar.
En linux (Fedora 29) me pide llave de seguridad y eso que tengo lector de dnie con el token pkcs11 iniciada sesión... pero pasa de usarlo; y no digamos ya de los certificados fnmt
Las llavecitas esas de marras cuestan 40 euros en Amazón.
Vamos, todo un invento
Y sí te localizan, porque detectan el dispositivo utilizado y lo almacenan en su base de datos... para que la próxima vez...
Con una password no, sólo saben mi password, no tienen manera de identificar quién la escribe ni con qué dispositivo (teclado).
Cualquiera puede hacerse una cuenta en twitter y usar el nombre de usuario de otra persona... pero no puede crear una cuenta usando mi dispositivo WebAuthn de esa persona a no ser que tenga ya de entrada la posibilidad de autenticarse en todas sus cuentas (vamos el equivalente digital a ser yo).
Podrías compararlo a asociar a tu correo electrónico, pero incluso en ese caso es mucho más fácil hacer un correo nuevo que comprarte un dispositivo WebAuthn nuevo....
Yo diría que el ejemplo más comparable es cuando aplicaciones como Whatsapp usan tu número de teléfono para autenticar la cuenta, lo cual me parece igual de peligroso en cuanto a la ruptura del anonimato.
Estamos hablando de un escenario global, donde hasta un barrendero que no sabe de informática pueda disponer de un método de autenticación que no pase por tener que comprarse una caja fuerte para guardar las copias de seguridad de su clave privada.
Necesitas una CA
Lo he mirado y las tarjetas estas permiten almacenar varias identidades, con lo que se podría resolver este problema.
Todos los sistemas tienen puntos flacos, no existe el sistema perfecto y fantabuloso (porque entonces lo estaríamos usando, no discutiendo). Se trata de escoger el menos malo y el que tenga un mejor compromiso entre comodidad y seguridad.
Privacy Protection: A FIDO2 authenticator generates a new pair of keys for every service, and the service stores only the public key. With this approach, no secrets are shared between service providers.
Para el que no entienda inglés, el dispositivo genera un nuevo par de claves para cada servicio en el que te registres, así que ningún servicio conoce tu identidad en otro lugar.
Salu2
I expect the attestation is the same even when the new key pair is generated, since it's used as a sort of "certificate authority" to sign the keys.
developer.mozilla.org/en-US/docs/Web/API/Web_Authentication_API/Attest
The purpose of attestation is to cryptographically prove that a newly generated key pair came from a specific device. This provides a root of trust for a newly generated key pair as well as being able to identify the attributes of a device being used (how the private key is protected; if / what kind of biometric is being used; whether a device has been certified; etc.).
It looks like the device can be identified regardless of whether the keys change every time. And it seems to be actually an intended behavior for the standard.
Ya no lo puedo editar... pero abajo la traducción:
Eso lo sospechaba, de lo contrario no sería seguro. Pero eso no significa que no puedan identificar el dispositivo, se intercambian más parámetros aparte de las claves (en la página que enlazas muestran "credentialid" y "attestation").
Imagino que el "attestation" es el mismo incluso cuando se genera un nuevo par de claves.
developer.mozilla.org/en-US/docs/Web/API/Web_Authentication_API/Attest
The purpose of attestation is to cryptographically prove that a newly generated key pair came from a specific device. This provides a root of trust for a newly generated key pair as well as being able to identify the attributes of a device being used (how the private key is protected; if / what kind of biometric is being used; whether a device has been certified; etc.).
Aparentemente el dispositivo puede ser identificado independientemente de que las claves cambien, y al parecer eso forma parte del disenio del estándar.
Imaginate que cada estado empezase a firmar certificados digitales asociados a tu ID nacional, con nombre y apellidos (como se hace con el DNI electrónico o con los certificados de la FNMT) y que se obligase a los servicios web a aceptar sólo claves que estén firmadas por la entidad certificadora del estado. Sería el fin del anonimato en internet.
O que Apple/Google/Sony/MS.. use esta tecnología para obligar a la gente a usar hardware de Apple/Google/Sony/MS...
Con lo cual serás uno más entre los miles o cientos de miles de personas que tengan el mismo modelo de dispositivo.
¿y como lo usas con dispositivos como móviles, tablets, kioskos, etc?
las yubi son unos 50€
Con las contraseñas tenemos dos problemas de seguridad:
1) Que se pueda acceder a un sistema que no deberíamos
2) Que la contraseña se vea comprometida por un filtrado de los datos que se han guardado
En ambos casos, la responsabilidad la delegamos en el usuario, y debería ser principalmente responsabilidad del sistema.
En el primero, se trata de evitar que puedan entrar por fuerza bruta. Si tú en un servicio no permites más de 3-5 fallos antes de bloquear la cuenta, no puedes hacer un ataque por fuerza bruta, por muy sencilla que sea la contraseña, no la vas a adivinar en 5 intentos ( por ejemplo, el pin del cajero o del móvil tiene tres intentos, y son sólo 4 dígitos ).
En el segundo caso, la responsabilidad de que los datos no sirvan aunque se produzca una filtración de los datos, sigue siendo del sistema, utilizando medidas para almacenar estas contraseñas de la forma más segura posible, cifradas, con salt y lo que sea necesario. Aquí puede haber un ataque por fuerza bruta, pero debemos ser capaces de proteger al usuario también contra esto.
El único problema a mayores que puede proteger un pincho, es que el usuario utilice la misma contraseña para cosas importantes y para registrarse en sitios dudosos, o no dudosos pero poco escrupulosos. Y eso no lo vas a evitar, salvo que obligues a todos los sitios a utilizar este modelo, o que los sitios 'más importantes' lo utilicen todos. En este último caso, la ventaja está en centralizar el sistema de autenticación, pero si se basa en introducir un pincho, no es un buen sistema. Contraseña más código sms, como muchos 2FA es bastante más versátil y bastante seguro.
¿qué ventajas hay frente a las yubikey? En que ahora han definido el estándar de cómo se debe implementar la autenticación con una Yubikey u otra llave para que todo el mundo vaya por un igual y la Yubi esa vaya bien en todos los sitios.
No estaría de más que te leyeras el enlace que te pasaron.
#48 ¿y qué pasa si pierdes tu contraseña? ¿también necesitas una CA o se puede recuperar a través de otros métodos?
En esos aspecto esto funciona igual pero la autenticación con llave es más segura porque la clave privada nunca sale del dispositivo, no necesitas ninguna caja fuerte. Del dispositivo solo sale la respuesta, así que no te pueden robar la "contraseña" (clave privada)
"¿en qué se parecen Google Authenticator y las Yubikey? "
En que los dos son un sistema de OTP, de hecho la única diferencia es el canal, la yubikey simula un teclado y Google Auth usa al usuario como canal.
"En que ahora han definido el estándar"
Como la autenticación http-basica, ntlm, ssl/tls, etc.
No sé en que mejora el nuevo estándar a los existentes, pero veo muchas dificultades para que se implante de manera masiva.
".No estaría de más que te leyeras el enlace que te pasaron. "
Además de habermelo leído, visto los errores de concepto de los que partes, no creo que seas el más adecuado para mandarme a leer.
"No sé en que mejora el nuevo estándar a los existentes"
En que no hay ningún estándar para esto. http-basica, ntlm, ssl/tls, etc. no tienen nada que ver.
"no creo que seas el más adecuado para mandarme a leer. "
Ostias, pues acabas de decir que las Yubikey son un sistema de autenticación de contraseña de un solo uso igual que el Google Auth que crea códigos para usar como segundo factor. Mientras que las Yubikey se basan en: Once communication is established, the application exercises a challenge–response authentication with the device using public-key cryptography methods and a secret unique device key manufactured into the device.[24] The device key is secured against duplication by a degree of social trust in the commercial manufacturer, and logically secured against reverse-engineering or counterfeiting by the robustness of the encryption and physical possession.
Google hablando de por qué las llaves estas son más seguras que su Google Auth. Me tengo que ir.
Abstract.“Security Keys” are second-factor devices that protect usersagainst phishing and man-in-the-middle attacks. Users carry a single de-vice and can self-register it with any online service that supports theprotocol. The devices are simple to implement and deploy, simple touse, privacy preserving, and secure against strong attackers. We haveshipped support for Security Keys in the Chrome web browser andin Google’s online services. We show that Security Keys lead to bothan increased level of security and user satisfaction by analyzing a twoyear deployment which began within Google and has extended to ourconsumer-facing web applications. The Security Key design has beenstandardized by the FIDO Alliance, an organization with more than250 member companies spanning the industry. Currently, Security Keyshave been deployed by Google, Dropbox, and GitHub. An updated andextended tech report is available at github.com/google/u2f-ref-code/docs/SecurityKeys_TechReport.pdf.
[..]
Authentication Failure Rate.Authentication failures result in increased au-thentication time and user frustration. In our examination of the time periodstudied, 3% of OTP-based authentications resulted in failure, while SecurityKeys did not present any authentication failures.
en.m.wikipedia.org/wiki/YubiKey
Aun asi, las ventajas son esas que se nombran.
De hecho, la evolución ideal sería algo tipo captcha, que combinase alguna información biométrica con un análisis de cómo tecleas o mueves el ratón, con lo que tendríamos casi casi el sistema ideal: no haría falta recordar nada, y sería un sistema infalible que no se puede robar ni "prestar" a nadie.