Las cuentas de Google activan las llaves de acceso como opción de inicio de sesión predeterminada
(blog.google)- Google ofrece las llaves de acceso como opción predeterminada en las Google Account personales, para facilitar la transición hacia inicios de sesión sin contraseña
- A partir del próximo inicio de sesión, se mostrará un mensaje para crear y usar llaves de acceso, y en la configuración de la cuenta aparecerá activada la opción “Skip password when possible”
- Las llaves de acceso permiten iniciar sesión con la huella dactilar, el escaneo facial o el PIN que se usa para desbloquear el dispositivo; Google considera que son 40% más rápidas que las contraseñas y más seguras por su método de cifrado
- El inicio de sesión con contraseña se mantendrá por ahora, y quienes no quieran usarlo pueden desactivar “Skip password when possible” para rechazar el uso de llaves de acceso
- Las llaves de acceso ya se usan en YouTube, Search y Maps, y también tienen soporte en Uber y eBay; la compatibilidad con WhatsApp llegará pronto
Cambio en el valor predeterminado de inicio de sesión para Google Account personales
- Google considera que, tras lanzar el soporte para llaves de acceso a comienzos de este año, la respuesta de los usuarios fue positiva
- Ahora, en todas las Google Account personales, las llaves de acceso se ofrecen como opción predeterminada de inicio de sesión
- La próxima vez que se inicie sesión en la cuenta, se mostrará un mensaje para crear y usar una llave de acceso
- En la configuración de Google Account, la opción “Skip password when possible” aparecerá activada
Cómo se usan las llaves de acceso y sus características de seguridad
- Las llaves de acceso usan la huella dactilar, el escaneo facial o el PIN, igual que al desbloquear el dispositivo, para iniciar sesión en una cuenta
- Según Google, iniciar sesión con llaves de acceso es 40% más rápido que con contraseñas
- Al depender de un método de cifrado, son más seguras y también tienen resistencia al phishing
- Los usuarios pueden reducir la carga de tener que recordar números y caracteres especiales de sus contraseñas
Se mantienen las contraseñas y la elección del usuario
- Google considera que las nuevas tecnologías tardan en consolidarse, por lo que las contraseñas podrían seguir existiendo por un tiempo
- Los usuarios aún pueden iniciar sesión con contraseña
- Quienes no quieran usar llaves de acceso pueden desactivar la opción “Skip password when possible”
El soporte para llaves de acceso se expande más allá de Google
- Desde el lanzamiento de las llaves de acceso, los usuarios las han usado en apps de Google como YouTube, Search y Maps
- Google ve con buenos ojos la tendencia de adopción de llaves de acceso en toda la industria
- Uber y eBay ofrecen opciones para iniciar sesión en sus plataformas sin usar contraseñas
- La compatibilidad con WhatsApp también estará disponible pronto
El siguiente paso hacia inicios de sesión sin contraseña
- Google seguirá informando en qué lugares se pueden usar llaves de acceso en otras cuentas en línea
- La empresa impulsa que la industria migre a llaves de acceso para reducir el uso de contraseñas y, con el tiempo, hacer que sean poco frecuentes
- La información relacionada con la seguridad de las cuentas de Google se puede consultar en myaccount.google.com/safer
1 comentarios
Opiniones de Hacker News
Como ya dijeron varias personas, si pierdes el dispositivo, volver a poner en marcha la autenticación criptográfica es muy difícil.
El mes pasado mi esposa rompió el vidrio de su iPhone y lo mandó a reparar con AppleCare, pero Apple no nos dijo que la “reparación del vidrio” en la práctica incluía reemplazar componentes internos y restablecer el equipo.
Las copias de seguridad de Apple iPhone no incluyen secretos criptográficos como la eSIM.
Al final, para activar la eSIM necesitas correo electrónico; para el correo electrónico necesitas MS Authenticator; y MS Authenticator no puede activarse sin SMS, así que caes en un bucle.
Tuvimos que ir hasta una tienda del operador con un montón de identificaciones con foto para que reemitieran la eSIM, y aunque la contraseña era correcta, la cuenta bancaria también quedó bloqueada por algún bloqueo de hardware del teléfono.
Resolverlo tomó varios días y hubo que visitar varias instituciones en persona. Si hubiéramos estado viajando en el extranjero, habríamos quedado totalmente varados.
Los tiempos cambiaron, y ahora toda tu identidad digital se convirtió en una smart card dentro del teléfono. Ya sea una SIM o un chip TPM integrado, si pierdes esa smart card, para los demás es casi como si estuvieras muerto.
Las Passkey empeoran mucho este problema. Con una SIM física al menos puedes pasarla de un teléfono a otro, pero las Passkey no se pueden transferir entre proveedores.
Hay que salir corriendo y gritando. No crean en el bombo publicitario; hay que esperar hasta que los proveedores ofrezcan soluciones decentes de transferencia y recuperación.
La gente odia las contraseñas, pero siendo realistas, en muchas situaciones y modelos de amenaza las contraseñas son el mejor compromiso. Si sacas 32 bytes o más de
/dev/randomy los codificas como quieras, nadie en este universo podrá romperlas por fuerza bruta, y un gestor de contraseñas también resuelve el problema de la reutilización.Además, tienen la ventaja de que puedo controlar cómo se almacenan y aplicar tantas copias de respaldo redundantes como me dejen tranquilo.
Las copias de seguridad del iPhone incluyen el respaldo de los elementos guardados en iCloud Keychain, y si tienes otro dispositivo Apple o una clave de recuperación, puedes volver a acceder. Con el código del dispositivo o la clave de recuperación puedes volver a arrancar todo desde cero.
La eSIM es un caso especial porque es cosa del operador; esas cosas siempre han sido y seguirán siendo problemáticas, atadas a tiendas y llamadas telefónicas.
Yo uso casi 3: una Yubikey en la estación de trabajo, una Yubikey portátil y el teléfono. Esas 3 me permiten recuperar tanto Google para el correo como Apple para el teléfono. El resto está en 1Password, y puedo acceder mediante esos medios.
Incluso en la peor emergencia imaginable, creo que de algún modo podría recuperar el correo. Si verifico mi identidad con el proveedor de DNS y cambio los registros MX, puedo volver a hacer las cosas. Aun así, no diría que es indispensable para la vida diaria. Perder el acceso sería enormemente incómodo, pero no creo que sea una sentencia de muerte.
Mis contactos de SMS y Signal también están en otros lugares, y el dinero de la cuenta bancaria puedo usarlo emitiendo cheques. Para las cuentas relacionadas con la empresa, puedo entrar si me presento físicamente en la oficina.
Dicho eso, creo que las Passkey probablemente sean demasiado complejas para el usuario común de computadora. Lamentablemente, el método de “te enviaremos un enlace por correo cada vez que inicies sesión” parece ser la autenticación sin contraseña más amigable para el usuario.
Tampoco me deja del todo tranquilo el hábito de poner las Passkey en 1Password. Sé que quedo atado para siempre. Aun así, me gusta el servicio y, si algún día quiero moverme, al menos tengo una lista de cuentas que debo recrear.
Lo que más temo es olvidarme el código del teléfono. Una vez me desperté y, en un momento muy desafortunado de distracción, no podía recordar de ninguna manera el código de 6 dígitos. Uso el mismo código para desbloquear la estación de trabajo. Después de distraerme un rato con otra cosa, apenas logré recordarlo por memoria muscular.
Fue realmente uno de esos momentos de “¿acabo de tener un derrame cerebral?”. Ahora guardo ese código en 1Password, así que si tengo al menos un dispositivo desbloqueado puedo refrescar la memoria. Fue hace bastante tiempo, no creo que sea demencia; simplemente fue un fenómeno raro y temporal.
En cambio, recuerdo perfectamente todas las contraseñas del trabajo que tenían una vida útil máxima de un año. Aunque eso no sirve de mucho si no puedo recordar los 6 dígitos.
Así que supongo que pronto las contraseñas también entrarán en “Killed by Google”, junto con mi cuenta. Yo no dejo ningún dispositivo con sesión iniciada.
Hace rato que debería haber migrado los pocos usos que todavía me quedan. Me pregunto si, cuando llegue la situación inevitable, la empresa podrá restablecer la Passkey de mi cuenta de trabajo.
Creo que esta es la dirección correcta, pero he visto demasiados casos de terror de personas bloqueadas fuera de sus cuentas de Google o iCloud sin una forma real de recuperarlas.
No creo ser el único que piensa así, pero siento que algún día, probablemente por un error mío, Google me dejará bloqueado y mi vida digital se acabará.
Con gusto pagaría si una empresa privada ofreciera un sistema de inicio de sesión como login.gov y, cuando uno queda bloqueado, permitiera hablar con una persona real como en USPS.
https://mastodon.laurenweinstein.org/@lauren/111103819626952...
https://mastodon.laurenweinstein.org/@lauren/111211366080459...
No es cuestión de si pasa, sino de cuándo. Para quien valora sus datos, son imprescindibles los respaldos y un plan sólido de recuperación ante desastres. Alguna empresa va a arruinar algo aunque no sea culpa tuya, y eso es inevitable.
Por desgracia, para algunos aspectos de las cuentas perdidas no hay buenas opciones de recuperación ante desastres, pero tener varias cuentas y evitar puntos únicos de falla ayuda en cierta medida.
Hay que asegurarse de tener varias formas independientes de iniciar sesión. Por ejemplo, imprimir códigos de respaldo y guardarlos junto con documentos importantes.
Pero eso tampoco evita quedar bloqueado por cambios en las políticas de Google, así que, idealmente, también habría que practicar cómo arreglárselas sin una cuenta de Google.
Lauren Weinstein advierte que Passkey es defectuoso y que, en especial para los usuarios comunes, se va a convertir en un enorme dolor de cabeza.
https://mastodon.laurenweinstein.org/@lauren/111103819626952...
https://mastodon.laurenweinstein.org/@lauren/111211366080459...
Dejando de lado por un momento los problemas de privacidad y dependencia de proveedores, Passkey no es una alternativa terrible para quienes reutilizan la misma contraseña básica en todos los sitios web sin autenticación de dos factores.
Pero en cuanto empiezas a depender de eso para proteger algo de verdad, se convierte rápidamente en una pesadilla enorme. Y empeora porque se lo trata como algo equivalente a contraseña + autenticación de dos factores.
Dice que “son fáciles de encontrar”, pero parece que no los encuentra.
https://mastodon.laurenweinstein.org/@lauren/111211489395997...
Si de todos modos es probable que el usuario use una contraseña débil para el servicio, no entiendo por qué una contraseña débil del dispositivo sería una razón para evitar Passkey.
En ese caso, si se vulnera la autenticación del dispositivo, la cuenta también queda comprometida de todos modos.
En particular, Google actualmente no tiene una estructura en la que haya que elegir solo entre contraseña y Passkey. Si el dispositivo no tiene una Passkey, se puede volver al flujo de inicio de sesión con contraseña.
Para comparar riesgos y beneficios, habría que saber cuánto reutiliza la gente sus contraseñas en la práctica, si usa autenticación de dos factores, si depende únicamente del bloqueo de pantalla del teléfono para acceder a todas sus cuentas, si usa autenticación biométrica, cuánta recuperación de cuentas se necesita, etc.
Solo esos datos podrían ordenar el debate y permitir que cada persona llegue a una conclusión distinta según su propia situación.
Google tiene la mayoría de esos datos. Si quiere respaldar su postura, debería publicarlos.
1Password activó hace poco el soporte para passkeys, y me “sorprendió” darme cuenta de que no hay forma de exportarlas fuera de 1Password.
No se incluyen ni en la exportación en formato 1PUX ni en CSV.
Es decir, literalmente no se pueden respaldar. Si 1Password se cae, la empresa cierra o pasa algo parecido, las passkeys simplemente desaparecen. No hay ninguna forma de recuperarlas.
Ver este AMA reciente de 1Password sobre passkeys:
https://old.reddit.com/r/1Password/comments/16to6x7/hey_redd...
Sobre qué pasa si 1Password deja de estar disponible: cuando las contraseñas y las passkeys se sincronizan con tus dispositivos, ambas también se guardan localmente. Aunque por alguna razón pierdas acceso a 1Password, puedes seguir accediendo a todos los elementos dentro de tu bóveda; lo único que dejaría de funcionar es la sincronización entre dispositivos.
Más que mover una passkey entre dispositivos, hay que verlo como un esquema donde se genera una passkey distinta por dispositivo, como con las claves SSH, y se registran todas en el servicio correspondiente.
Claro que un usuario podría ser engañado para agregar la passkey de un atacante a su cuenta.
En móviles este problema se resolvió hace años, pero el correo electrónico sigue siendo un desastre. La lección es no quedar nunca atado a un proveedor.
Intercepta las llamadas a
window.credentials, y si quieres usar 1Password junto con otros medios de verificación como Yubikey, tienes que entrar a la configuración y desactivar por completo la función de passkeys.También se parece a la forma en que intercepta el prompt de Google One Tap y lo desactiva globalmente para mostrar su propio prompt de OAuth. Yo solo uso la extensión de Chrome, así que no sé si la experiencia en la app nativa es muy distinta.
Desde el punto de vista del usuario, todavía no lo entiendo.
Si se incendia mi casa o pasa algo así y se destruyen todos los dispositivos donde tenía sesión iniciada en Google, ¿qué ocurre? ¿Cómo vuelvo a iniciar sesión en mi cuenta?
Le dimos un teléfono viejo y pudo mover la SIM sin problema, pero no hubo forma de iniciar sesión en la cuenta de Google. Google insistía una y otra vez en que “usara el teléfono”. La laptop también tenía cerrada la sesión del correo.
Por suerte, por un incidente anterior yo tenía tokens de respaldo, así que se pudo resolver. No sé qué harían otras personas.
Se divide la clave en M fragmentos, y se requieren N de ellos para reconstruirla. Por ejemplo, con 3/8 basta con 3 de 8 fragmentos para recuperar la clave. Se entrega cada fragmento a personas de confianza y, al recuperar, se obtienen fragmentos de al menos 3 de ellas para reconstruir la clave.
Cuando lo implementé en una demo para YC llamada multipasskey, hacía que eligieras contactos de confianza y enviaba fragmentos de la clave a esas personas en segundo plano. Si necesitabas recuperar, les enviabas una solicitud y, cuando recibías suficientes fragmentos, reconstruías la clave del dispositivo. Una vez que tenías la clave del dispositivo, descargabas del servidor remoto una copia de seguridad cifrada de la clave y quedaba restaurado como nuevo.
En 2017/2018 postulé a YC con este proyecto, llamado multipasskey, como una demo funcional, pero me rechazaron. Supongo que no supe explicarlo bien.
Como técnico, supongo que significa dejarle un dispositivo de respaldo a un amigo, o guardar también las passkeys en una cuenta de Apple/Microsoft/gestor de contraseñas.
Pero Google debería explicarlo con más detalle.
Y nunca, jamás, hay que perder el número de teléfono. Aunque tengas usuario, contraseña y correo de recuperación, si no puedes recibir el código por SMS, no puedes volver a entrar a tu cuenta de Google.
Durante esta transición, se recomienda ofrecer passkeys como alternativa a los métodos ya existentes. Google y muchos proveedores de servicios lo están haciendo así.
Dicho eso, la pregunta que planteas es un problema de recuperación de cuenta que todos deberían hacerse incluso sin passkeys. Hay que tener un plan para iniciar sesión si olvidas la contraseña, pierdes acceso al gestor de contraseñas o pierdes el segundo dispositivo de autenticación. Adoptar passkeys no elimina por completo la necesidad de pensar en la recuperación de cuenta.
Aun así, hay casos particulares en los que las passkeys son mejores para la recuperación de cuentas. Si creas una passkey para una cuenta de Google en un dispositivo Apple que usa iCloud Keychain, esa passkey se sincroniza con iCloud. Entonces, aunque se queme tu casa y pierdas todos los dispositivos, mientras puedas acceder a tu cuenta de iCloud podrás recuperar la passkey de tu cuenta de Google y de otros sitios web.
Por supuesto, la pregunta “¿y si pierdo acceso a la cuenta de Apple iCloud?” es válida. Por eso el problema de recuperación de cuenta no desaparece por completo, pero en muchos casos las passkeys pueden reducirlo considerablemente.
Aquí hay una paradoja de Simpson
En promedio, puede mejorar la seguridad, porque la gran mayoría de los usuarios usa contraseñas de manera pésima.
Pero para los usuarios avanzados que usan contraseñas de forma segura, si se les impone, la seguridad cae drásticamente.
La autenticación de dos factores obligatoria por número telefónico tiene el mismo efecto. En el caso de Big G, la 2FA obligatoria por número telefónico es una política anti-anonimato disfrazada de seguridad. En este caso parece un intento de obtener datos biométricos.
El número telefónico es la mejor identidad de largo plazo que tiene la mayoría de la gente, y Google tiene que dar soporte a la recuperación de cuentas de miles de millones de usuarios a una escala absurda.
Mucha gente pierde contraseñas y dispositivos, pero muy poca pierde su número telefónico.
Por eso, tiene lógica que Google use números telefónicos para otorgar y delegar identidad en su plataforma. Es malo para la privacidad, pero muy bueno para la seguridad, porque permite controlar los datos mediante una “credencial” de autenticación de terceros que el usuario no tiene que administrar por su cuenta.
Y no estoy seguro de esta parte, así que agradecería que alguien que sepa me corrija. Incluso suponiendo un usuario avanzado inmune a contraseñas débiles, reutilización y phishing, entiendo que hay una ventaja de seguridad: aunque se filtre una passkey de Google, lo que se filtra es solo la clave pública, y con la clave pública no se puede iniciar sesión, así que la filtración se vuelve casi inútil.
Si Google estuviera recolectando datos biométricos, ya lo habría estado haciendo, y no tendría relación con esta función.
Estos detalles muy básicos del modelo de seguridad son ciertos desde hace mucho, desde la época en que el iPhone empezó a usar Secure Enclave. No entiendo por qué en este sitio la gente habla con tanta contundencia sobre cosas que no entiende en absoluto y, sinceramente, me sorprende.
Una passkey es moralmente equivalente a usar una clave SSH en lugar de una contraseña SSH para iniciar sesión en un servidor, pero aplicado a sitios web. Además, objetivamente hay un hecho simple que no se puede reemplazar con la idea de “usar contraseñas de forma segura”: las passkeys son literalmente resistentes al phishing.
Me sorprende que ya estén impulsando esto con tanta fuerza. Incluso hasta la semana pasada todavía quedaban suficientes asperezas en la implementación como para que lo desactivara en mi tenant de Workspace.
Las dos cosas más molestas son que Advanced Protection todavía no soporta passkeys, así que por ahora hay que mantener U2F, y que si una cuenta tiene configurada una llave U2F, Google primero te indica que la uses como passkey y luego, como no es una passkey, te pide iniciar sesión con contraseña.
Como resultado, quienes usan autenticación multifactor resistente al phishing pierden la función de “recordar” el paso de MFA en el dispositivo, porque Google siempre exige el factor U2F antes de la contraseña.
Aparte de eso, mientras nos preparábamos para desplegar inicios de sesión sin contraseña basados en Okta para algunos clientes pequeños, estuvimos probando mucho los flujos FIDO2 con llaves de seguridad y passkeys en distintos tipos de dispositivos y plataformas. En general me gusta el flujo de autenticación en sí, pero hay muchas trampas con las que tener cuidado.
Pasamos bastante tiempo ordenando los caminos normales, creando material de onboarding y documentando escenarios de continuidad operativa. Los casos de uso personales son, en cierto sentido, más difíciles, porque hay que pensar en cada servicio y no en un único IdP.
Si necesitas soportar varios entornos, el camino fácil ahora mismo es invertir en 1Password u otro administrador de contraseñas compatible con passkeys. Ofrece la experiencia de usuario más consistente y funciona en la mayoría de las plataformas, pero en Android 14 todavía hay problemas.
Para cuentas con privilegios altos seguiremos usando llaves de hardware, así que los administradores recibirán un par de llaves FIDO2. El resto recibirá una Yubikey, que servirá como respaldo si pierden acceso al dispositivo o necesitan iniciar sesión desde un dispositivo no confiable. Android también es un problema aquí. Incluso en la versión 14 parece no soportar flujos FIDO2 sin contraseña.
Es una dirección interesante. Dicho eso, vale la pena señalar que los datos biométricos, como huellas digitales o reconocimiento facial, en realidad no son “secretos”.
Pueden observarse o aprovecharse sin conocimiento ni consentimiento del usuario y, en muchos sentidos, se comportan más como un nombre de usuario que como una contraseña.
La huella solo desbloquea el par de claves criptográficas que se usará para la autenticación.
Yo uso una Yubico Security Key como passkey y está protegida con un PIN de 6 dígitos. Ese PIN solo existe localmente en el dispositivo y sirve para impedir que alguien que tenga físicamente el dispositivo pueda iniciar sesión de inmediato. Si ingresas mal el PIN 10 veces seguidas, la llave se borra.
Al ingresar el PIN, la llave se desbloquea, y esa llave es la que te permite entrar a la cuenta de Google.
La mayoría de las cuentas con contraseña tienen una protección del tipo “si demuestras tu identidad ante la empresa, te la restablecen”. Si no recuerdas la contraseña del banco, el banco tiene una vía para restablecerla.
Con las cosas que controla Google, no hay ninguna forma de contactar a alguien para resolver el problema. Ya es un problema en todos los productos de Google.
Encerrar todo el acceso detrás de una puerta controlada por Google es prepararse una pesadilla futura.
Qué lástima que todavía no se puedan guardar passkeys en Bitwarden. Aun así, según el mensaje en la parte superior de esta página, parece que llegará en octubre.
https://bitwarden.com/blog/bitwarden-passkey-management/