Una nota sobre la financiación: CypherpunkGuide no lleva publicidad de vigilancia. Nada de redes publicitarias, píxeles de rastreo ni contenido patrocinado. Nos sostienen fuentes transparentes: hoy, las donaciones de los lectores; más adelante, una suscripción y afiliados alineados con nuestra línea editorial. Respondemos ante quienes nos leen, no ante los anunciantes.
Las claves de acceso ya superan la prueba del inicio de sesión cotidiano. El Passkey Index 2025 de FIDO Alliance registró una tasa de éxito del 93 %, frente al 63 % de otros métodos, y un tiempo medio de 8,5 segundos en lugar de 31,2. También resisten el phishing: una web falsa no puede pedirte que escribas un secreto reutilizable porque no existe ningún secreto de ese tipo que puedas teclear.
La dificultad aparece al recuperar el acceso. Una credencial excelente para entrar a diario puede seguir dependiendo del número de teléfono, la cuenta de correo, el proveedor en la nube, un dispositivo de confianza o un código en papel que la respaldan. El 1 de agosto de 2026 revisé 25 documentos oficiales o fuentes primarias de Google, Apple, Microsoft, GitHub, FIDO y NIST. Después apliqué el mismo fallo a cada ecosistema: has perdido el teléfono y la computadora que usas a diario, además de la llave física que llevas contigo; solo quedan los recursos de recuperación guardados en otro lugar. No encontré un único proceso de «recuperación de passkeys», sino una cadena de dos o tres recuperaciones con distintos puntos de bloqueo definitivo.
Por eso no basta con preguntar si una clave de acceso es más segura que el doble factor por SMS (2FA, una segunda prueba que se pide después de la contraseña). Contra el phishing, lo es. La pregunta decisiva es otra: si pierdes los dispositivos cotidianos, ¿puedes recuperar tanto la cuenta del proveedor que guarda la clave como la cuenta de destino que la aceptó, sin volver a depender del mismo dispositivo perdido? Esta guía traza esas dependencias, corrige una confusión entre cuentas personales de Microsoft y cuentas empresariales de Entra que ya aparece en buscadores, y propone una migración que prepara la recuperación antes de retirar nada. No elimines tu último método de acceso operativo mientras lees.
Recuperar una clave de acceso exige resolver dos problemas distintos#
Puedes recuperar la credencial desde el proveedor que la guarda o recuperar la cuenta de destino y registrar una clave nueva. Son operaciones controladas por empresas diferentes: completar una no garantiza la otra.
Una clave de acceso (passkey) es una credencial criptográfica para una web o una aplicación concreta. El servicio conserva la clave pública; el dispositivo o el gestor de credenciales conserva la privada. WebAuthn, el estándar web que usan las claves de acceso, vincula esa clave al dominio auténtico del servicio. Por eso NIST SP 800-63B-4 considera que WebAuthn bien configurado resiste el phishing, mientras que un código de un solo uso introducido a mano no lo hace.
Detrás de ese acceso sencillo intervienen dos actores:
- El proveedor de credenciales guarda o sincroniza la clave de acceso. Cumplen esa función la aplicación Contraseñas de Apple con el Llavero de iCloud, Google Password Manager, Microsoft Password Manager, un gestor de contraseñas independiente, Windows Hello o una llave física de seguridad.
- El servicio de destino —la relying party en WebAuthn— es la web que acepta la clave. GitHub ocupa ese papel. Google y Microsoft pueden ser a la vez proveedor y servicio de destino cuando guardan la clave que abre una cuenta propia.
La primera conclusión de la auditoría nace de esa diferencia. Muchas comparativas colocan Apple, Google, Microsoft y GitHub en cuatro columnas equivalentes. No lo son: en este análisis Apple actúa sobre todo como proveedor de credenciales; GitHub, como servicio de destino. La diferencia importa especialmente después de una pérdida.
| Credencial o vía | Dónde se guarda el secreto | ¿Resiste la pérdida de un dispositivo? | Si pierdes todos los dispositivos cotidianos | Riesgo principal |
|---|---|---|---|---|
| Clave de acceso sincronizada | Gestor de credenciales cifrado de extremo a extremo | Por lo general sí, si ya hay otro dispositivo con sesión iniciada | Recuperar la cuenta del proveedor y superar su control para restaurar las claves cifradas | La recuperación pasa a depender de la cuenta del proveedor |
| Clave vinculada al dispositivo | Un teléfono, una computadora o una llave física | No; esa clave se pierde. La cuenta puede seguir accesible con otro autenticador | Recuperar la cuenta de destino por otra vía y registrar una clave nueva | Pérdida permanente de esa credencial |
| Código de recuperación | Papel o almacenamiento seguro fuera de línea | Sí | Introducir el código largo o de un solo uso | Robo, pérdida o guardarlo junto al dispositivo |
| Recuperación por correo o teléfono | Otra cuenta o la operadora | A veces | Recuperar primero ese canal | Phishing, SIM swap o un fallo común que elimine ambos accesos |
El documento de FIDO sobre el despliegue de claves sincronizadas delimita bien la promesa. Sincronizar aumenta las probabilidades de sobrevivir a la pérdida de un dispositivo, pero aún puedes perder la cuenta del proveedor o no superar su proceso de restauración. «Sincronizada» significa que existe una copia protegida; no significa que el proveedor siempre pueda devolvértela.
Qué ocurre si pierdes todos los dispositivos cotidianos#
Una clave sincronizada solo regresa a través de su proveedor de credenciales; una clave vinculada al dispositivo se pierde junto con él. Solo podrás volver a entrar en la cuenta de destino si queda operativo un método de recuperación guardado en otro lugar.
Apliqué exactamente ese escenario a cuatro ecosistemas y dejé las pruebas en la auditoría descargable de recuperación de claves de acceso. Es una auditoría documental, no un experimento en el que provoqué bloqueos: no retiré autenticadores de cuentas activas. Tampoco deberías hacerlo solo para reproducirla.
La matriz se limita a cuentas personales que controla su propio titular. Las cuentas administradas por una organización o por un proveedor de identidad —Google Workspace, Managed Apple Accounts, GitHub Enterprise Managed Users y las identidades de Microsoft Entra— obedecen políticas propias y quedan fuera. Las fechas de Entra aparecen más adelante únicamente para corregir la confusión entre el calendario empresarial y el de las cuentas personales.
| Ecosistema | Función en esta auditoría | Cómo vuelve la clave sincronizada | Controles documentados para recuperar el acceso al proveedor o a la cuenta | Sobrevive a la pérdida de los dispositivos cotidianos si… | Límite de fallo o bloqueo definitivo |
|---|---|---|---|---|---|
| Cuenta personal de Google | Proveedor y servicio de destino | Google Password Manager mediante la cuenta de Google y su PIN, o un dispositivo usado antes que cumpla los requisitos | Proveedor / cuenta de Google: datos de recuperación; algunas cuentas elegibles pueden añadir un contacto de recuperación | Sigue accesible al menos un canal o contacto independiente del equipo perdido | No se puede recuperar el PIN y se restablecen todas las claves de la colección de Password Manager; después hay que recuperar por separado cada servicio de destino |
| Cuenta personal de Apple | Principalmente proveedor | Recuperación segura del Llavero de iCloud mediante los controles de la Cuenta de Apple | Proveedor / Cuenta de Apple: recuperación estándar, un contacto de recuperación aceptado o la vía opcional de la clave de recuperación | Se puede recuperar el número de confianza, o queda fuera de los dispositivos perdidos un contacto registrado o la clave de 28 caracteres | La clave de recuperación está activa, pero no queda ningún dispositivo de confianza ni la clave de 28 caracteres ni —cuando la Protección de Datos Avanzada permite ambas opciones— un contacto de recuperación configurado por separado y aún utilizable |
| Cuenta personal de Microsoft | Proveedor y servicio de destino | Un gestor sincronizado vuelve al iniciar sesión en su proveedor; Windows Hello o una llave física pueden quedar vinculados a un dispositivo | Proveedor / cuenta Microsoft: información de seguridad alternativa o un código de recuperación de 25 dígitos | Sigue accesible un canal alternativo o se guardó fuera de línea el código de 25 dígitos | El doble factor está activo y no hay ningún método alternativo; Microsoft afirma que el soporte técnico no puede saltarse ese control |
| Cuenta personal de GitHub | Principalmente servicio de destino | El proveedor restaura la credencial sincronizada; GitHub no conserva esa clave privada | Cuenta personal de destino: 16 códigos de un solo uso, otra clave de acceso o llave de seguridad, una clave SSH, un token de acceso personal (PAT) o un dispositivo verificado | Sobrevive un código fuera de línea o un autenticador guardado aparte; SSH, PAT y dispositivos verificados solo cuentan si siguen disponibles y GitHub los acepta para recuperar | No queda ninguna clave de acceso ni método de recuperación aceptado; GitHub Support no puede devolver el acceso |
La tabla revela otro problema: decir «uso una clave de acceso» no aclara dónde está guardada. Un aviso de Windows puede almacenar una credencial en Windows Hello de una sola computadora y otra en un gestor sincronizado. Un proceso con código QR puede usar el teléfono solo durante esa sesión o guardar allí la clave. Antes de diseñar la recuperación, abre la lista de claves en la web y la lista de credenciales en el proveedor. Anota el proveedor y el dispositivo, no solo el nombre del servicio.
Cuatro plataformas, cuatro rutas de recuperación#
Los cuatro ecosistemas permiten usar claves de acceso con seguridad, pero no recuperan igual. El lugar de almacenamiento, la recuperación de la cuenta del proveedor y una copia fuera del dispositivo deciden si la pérdida termina en bloqueo.
Cuentas personales de Google: el PIN de Password Manager importa#
Google Password Manager sincroniza claves de acceso entre Android, Chrome, iPhone y iPad. Al crear por primera vez una clave en una computadora, un iPhone o un iPad, Google puede generar un PIN específico de Password Manager. La documentación del PIN explica que sirve para desbloquear las claves en un dispositivo nuevo y mantener los datos cifrados fuera del alcance de Google.
Añadir una clave de acceso a una cuenta personal de Google no elimina automáticamente la contraseña, los datos de recuperación ni los demás factores. La guía de claves de acceso de la cuenta añade que la propia clave puede satisfacer el segundo paso al iniciar sesión. Ambos hechos son compatibles: una clave puede sustituir a contraseña más código en el uso diario, mientras los factores anteriores siguen disponibles para recuperar, salvo que los retires deliberadamente.
El límite aparece cuando olvidas el PIN. Google permite restablecerlo desde un dispositivo que no sea Android donde ya hayas usado claves de Google Password Manager. Si pruebas todos los dispositivos aptos y aun así no puedes recuperarlo, la salida documentada es Restablecer tus claves de acceso. Esa acción borra todas las claves guardadas en Google Password Manager; no vuelve a emitirlas en cada web. Tendrás que recuperar cada cuenta de destino y crear credenciales nuevas.
Aquí conviene separar dos procesos que muchos resúmenes mezclan. El procedimiento de recuperación de Google puede devolverte el acceso a Gmail y a la propia cuenta. Recuperar Password Manager significa volver a abrir la colección cifrada de claves. Lo primero no demuestra por sí solo que puedas descifrar lo segundo. En algunos bloqueos con verificación en dos pasos, la guía de incidencias advierte que la revisión puede tardar de tres a cinco días laborables. Google presentó Recovery Contacts para cuentas personales elegibles en 2025, pero la disponibilidad y el despliegue varían: trátalo como una opción adicional, no como una promesa universal.
Cuentas personales de Apple: recuperar el Llavero de iCloud tiene condiciones#
Apple diseñó el Llavero de iCloud para sincronizar contraseñas y claves de acceso con cifrado de extremo a extremo. Sus servidores transfieren registros cifrados sin conservar copias legibles. La guía de seguridad de la plataforma indica expresamente que el sistema está concebido para recuperar el llavero incluso cuando todos los dispositivos del usuario están inaccesibles. Es una afirmación más precisa que «tus claves están en iCloud».
También es una ruta condicionada. La página de Apple sobre seguridad de las claves de acceso explica que, si todos los dispositivos están fuera de alcance, la recuperación puede pedir la contraseña de la Cuenta de Apple, un SMS al número registrado y el código del dispositivo. El servicio que custodia los datos cifrados para la recuperación permite 10 intentos de autenticación; el décimo fallo destruye el registro depositado. El sistema contempla una ruta para el caso en que pierdes todos los dispositivos, pero no ofrece una garantía ilimitada.
El proceso sigue apoyándose en la Cuenta de Apple. La recuperación estándar puede combinar las credenciales de la cuenta, un número de confianza, códigos de dispositivos y, en algunos casos, un periodo de espera. Un contacto de recuperación puede entregar un código de seis dígitos, y Apple permite registrar hasta cinco contactos. Esa persona no puede ver el contenido de la cuenta; solo ayuda a confirmar la identidad.
Apple también advierte que la recuperación completa puede tardar varios días o más y que el soporte técnico no puede acortar la espera. Es una vía de último recurso, no acceso de emergencia para el mismo día.
La clave de recuperación opcional exige una advertencia clara. La documentación de Apple señala que la clave de 28 caracteres desactiva la recuperación estándar de la cuenta. Con la Protección de Datos Avanzada, una clave y un contacto de recuperación pueden coexistir, y cualquiera de los dos puede servir para volver a entrar. Sin la contraseña de la cuenta, un dispositivo de confianza, la clave de 28 caracteres ni un contacto configurado que aún funcione, el bloqueo puede ser permanente. Esa clave solo te da más control si la guardas fuera de la cuenta que protege. Guardarla en Notas de Apple, iCloud Drive o la aplicación Contraseñas crea una dependencia circular; Apple desaconseja expresamente esos lugares.
Las llaves físicas de seguridad de la Cuenta de Apple son otra función, distinta de las claves sincronizadas del Llavero de iCloud. Apple exige al menos dos llaves físicas y admite hasta seis. Su guía de llaves de seguridad avisa de que perder todos los dispositivos de confianza y todas las llaves registradas puede bloquear la cuenta para siempre. Una llave de repuesto solo ayuda si ya está registrada, comprobada y guardada lejos de los dispositivos cotidianos.
Microsoft: las cuentas personales no siguen el calendario de Entra#
Microsoft admite claves sincronizadas y claves vinculadas al dispositivo. Su guía para consumidores define la primera como una credencial que vuelve mediante un gestor, y la segunda como una credencial que se pierde con el dispositivo si no existe otro método. Microsoft Password Manager se está desplegando en perfiles personales de Edge; Windows Hello y las llaves físicas pueden permanecer locales.
Comprobé el titular «Microsoft retira el SMS en septiembre de 2026» contra la fuente original porque altera la recomendación práctica. El cambio del 1 de septiembre de 2026 afecta a entornos de Entra ID administrados por una organización: a las personas que ya tienen habilitado SMS o voz se les habilita automáticamente la opción de registrar claves de acceso y se les invita a hacerlo. Los administradores del entorno pueden excluirlo temporalmente hasta el 1 de febrero de 2027, cuando Microsoft retira su propio servicio de SMS y voz para Entra. Por separado, Microsoft dice que retirará gradualmente los códigos SMS de las cuentas personales, pero esa página no fija septiembre de 2026 como fecha universal. Mezclar ambos ámbitos empujaría a titulares de cuentas personales a eliminar un método por un plazo que no existe.
La recuperación personal tiene su propio límite. Si la verificación en dos pasos está activa y no puedes usar ninguno de los métodos alternativos, el formulario normal y el soporte técnico no pueden devolverte el acceso, según la página del formulario de recuperación. Microsoft ofrece por separado un código de recuperación de 25 dígitos. Su guía del código advierte que cambiar datos de seguridad con la verificación en dos pasos puede tardar 30 días. Genera y guarda el código antes de una crisis, no cuando ya hayas perdido el dispositivo con la clave.
Cuentas personales de GitHub: varias opciones, ninguna excepción del soporte técnico#
Este análisis cubre a quienes administran sus propias credenciales en una cuenta personal; la documentación de GitHub no extiende este modelo a cuentas empresariales administradas. En una cuenta personal, una clave de acceso satisface tanto la contraseña como el 2FA al entrar desde el navegador. Recuperar una clave sincronizada corresponde a Apple, Google, Microsoft o al proveedor que guardó la clave privada. La página de gestión de claves de GitHub remite a ese proveedor. Una llave de seguridad vinculada a un dispositivo no se vuelve recuperable solo porque GitHub aún la muestre en la lista.
GitHub sí detalla el otro lado de la recuperación. Según su documentación de métodos, GitHub genera 16 códigos de un solo uso y contempla como posibles pruebas las claves SSH —claves criptográficas usadas para Git o acceso remoto—, los tokens de acceso personal (PAT, credenciales para API y Git) y los dispositivos verificados. Haber usado antes una opción no garantiza que siga siendo apta; una clave SSH inactiva, por ejemplo, puede quedar excluida. Una solicitud con un dispositivo verificado o una clave SSH que GitHub acepte puede tardar hasta tres días laborables.
El último límite es inequívoco: si desaparecen todas las credenciales y todos los métodos aceptados, GitHub Support no restaura una cuenta personal con 2FA. La guía para credenciales perdidas considera permanente esa pérdida. Guarda los códigos fuera de línea y registra más de un método antes de convertir la clave de acceso en tu forma cotidiana de entrar.
La paradoja de la recuperación: acceso fuerte, respaldo más débil#
La paradoja aparece cuando un acceso resistente al phishing depende de un método de recuperación más débil. El atacante puede dirigirse al correo, el teléfono, el proceso de soporte o la cuenta en la nube que permiten sustituir la clave.
Eso no convierte las claves de acceso en una mala idea. Significa que la recuperación forma parte de la autenticación y no es un trámite posterior. La guía de recuperación de NIST trata la recuperación de cuentas como un evento de gestión de autenticadores y exige mecanismos adecuados al nivel de garantía. Un código de un solo uso resulta útil porque puede ser independiente, pero deja de resistir el phishing si lo escribes en una web falsa.
| Vía de recuperación | ¿Independiente de los dispositivos perdidos? | ¿Resiste el phishing? | Uso más adecuado | Cómo reforzarla |
|---|---|---|---|---|
| Código de recuperación fuera de línea | Sí, si se guarda fuera del dispositivo | No | Acceso de emergencia | Papel o copia cifrada fuera de línea; nunca solo en la nube |
| Segunda llave física | Sí, si se guarda en otro lugar | Sí | Cuentas de alto valor | Registra dos, prueba ambas y guarda una en un lugar distinto |
| Clave sincronizada en el mismo proveedor | En parte | Sí para iniciar sesión | Comodidad diaria y pérdida de un solo dispositivo | Refuerza la recuperación del proveedor y conserva una opción externa |
| Correo de recuperación | Solo si pertenece a otra cuenta | No por sí solo | Recuperación general de cuentas | Otro proveedor, una clave de acceso y recuperación independiente |
| Teléfono de recuperación / SMS | Solo si el servicio telefónico sigue disponible | No | Compatibilidad de último recurso | Configura un PIN con la operadora y reduce la exposición con un modelo de amenazas para tu número |
| Contacto de recuperación | Sí, si la persona y su dispositivo siguen disponibles | No por sí solo | Recuperar Apple o una cuenta de Google elegible | Elige con cuidado y ensaya el contacto y las comprobaciones de identidad |
La portabilidad mejora, pero no diseñes tu recuperación sobre una promesa futura. FIDO publicó en marzo de 2026 el Credential Exchange Format como estándar propuesto para importar y exportar credenciales con seguridad. Que exista el estándar no demuestra que los proveedores que usas permitan hoy transferir todas tus claves. Verifica las funciones de exportación e importación de ambos productos antes de depender de una migración entre proveedores.
La contrapartida para la privacidad también está clara. La sincronización protege frente a la pérdida de un dispositivo, pero concentra la recuperación en una cuenta en la nube. Las claves vinculadas al dispositivo reducen esa dependencia a costa de hacer más grave la pérdida física. Es la misma diferencia entre administrar algo directamente y limitarse a trasladar la confianza a un panel de administración, distinción que aplico en la auditoría de soberanía en cinco capas. Decide en función de un adversario y un fallo concretos, no de un eslogan.
Migra empezando por la recuperación#
Una migración segura empieza por preparar la recuperación, no por eliminar métodos. Haz inventario del almacenamiento, añade un método fuera del proveedor, compruébalo sin borrar nada y solo entonces relega el SMS o la contraseña.
- Anota por separado la cuenta y el proveedor. Escribe
GitHub — Google Password Manager, no soloGitHub — clave de acceso. Marca cada clave como sincronizada, vinculada al dispositivo o desconocida. Si no lo sabes, todavía no retires nada. - Protege primero la cuenta del proveedor. Para recuperar una clave sincronizada, primero debes recuperar la cuenta de Apple, Google, Microsoft o del gestor independiente y superar los controles que protegen el cifrado. Actualiza el correo de recuperación, el teléfono de confianza, el contacto de recuperación y un autenticador independiente. Empieza también por identificar al adversario, como en el modelo de amenazas en la era de la IA.
- Crea una vía de recuperación fuera del proveedor. Según el servicio, usa códigos impresos, una segunda llave física guardada en otro lugar o una clave SSH cuya clave privada —o una copia ya probada— esté en otro dispositivo y que el servicio todavía acepte para recuperar. No dejes la única copia dentro de la misma cuenta en la nube.
- Haz una prueba sin borrar nada. Abre una ventana privada o un perfil distinto del navegador y comprueba que el método de reserva aparece entre las opciones de acceso. Usa una comprobación de estado que no cambie nada cuando exista. Si la prueba consume un código de un solo uso, márcalo como usado y sustitúyelo de inmediato, o genera y guarda un juego nuevo. No inicies una recuperación completa, ni elimines la clave principal, ni borres un dispositivo, ni cierres todas las sesiones de confianza solo como ensayo.
- Documenta las instrucciones fuera de línea. Incluye el nombre del proveedor, la cuenta de destino, el lugar donde guardas la reserva y la URL oficial de recuperación. La disciplina se parece al primer ensayo de recuperación de autocustodia de bitcoin: si nunca probaste una copia, solo supones que funcionará; todavía no es una salvaguarda comprobada.
- Relega el método anterior de una cuenta cada vez. Prefiere la clave de acceso para el uso diario. Retira el SMS solo después de que funcione la vía independiente y únicamente si el servicio no exige el número para recuperar. Vuelve a comprobar después de cambiar de teléfono, gestor de contraseñas, cuenta de Apple, Google o Microsoft, o llaves de seguridad.
El orden es una medida de seguridad. Si eliminas primero el SMS y dejas la reserva para después, habrá un intervalo en el que una caída que dañe el teléfono, una pantalla rota, una llave perdida o un proveedor mal elegido pueden cerrar la cuenta para siempre. El trabajo de seguridad debe reducir los fallos simultáneos, no crear otros nuevos.
Conclusión: ¿deberías sustituir ya el SMS?#
Usa claves de acceso para entrar a diario, pero no relegues el SMS hasta comprobar con éxito otra vía desde un navegador sin una sesión iniciada. Combina un acceso resistente al phishing con recuperación independiente de un solo dispositivo o cuenta en la nube.
Las pruebas sobre el inicio de sesión normal son sólidas. Los datos de FIDO citados arriba y el informe de Google de 2024 —más de 1.000 millones de autenticaciones en 400 millones de cuentas y accesos un 50 % más rápidos— miden el uso cotidiano, no la recuperación después de perder dispositivos.
La recuperación después de una pérdida tampoco depende de una sola función. Google Password Manager puede pedir su PIN; Apple puede depender de la recuperación de cuenta, un contacto o una clave de recuperación; las cuentas personales de Microsoft tienen información alternativa y un código de 25 dígitos; GitHub depende de sus códigos o de otra prueba ya registrada. «Está respaldado en la nube» oculta todas esas condiciones.
Empieza por la cuenta cuya pérdida causaría más daño. Relaciona proveedor y servicio de destino, guarda un método de recuperación fuera de ambos, pruébalo y pasa después a la siguiente cuenta. Tarda más que pulsar «usar una clave de acceso» en todas partes durante una tarde. A cambio, obtienes protección contra el phishing sin que perder una bolsa te deje fuera de todas tus cuentas importantes.
Preguntas frecuentes#
¿Son las claves de acceso más seguras que el doble factor por SMS?#
Contra el phishing, sí. Una clave WebAuthn está vinculada al dominio real, de modo que una web falsa no puede recoger un secreto reutilizable. En cambio, puedes introducir un código SMS en una web falsa, o un atacante puede interceptarlo después de un SIM swap (secuestro de la SIM). La recuperación sigue siendo otra capa: si el servicio acepta SMS para sustituir una clave perdida, esa vía conserva el riesgo del SMS.
¿Qué ocurre con mis claves de acceso si pierdo el teléfono?#
Las claves sincronizadas pueden volver cuando recuperas y desbloqueas su gestor en otro dispositivo. Una clave vinculada únicamente al teléfono se pierde. En ambos casos, un segundo autenticador o el método de recuperación del servicio determinan si puedes volver a entrar sin ese teléfono.
¿Pueden Apple, Google o Microsoft leer mis claves sincronizadas?#
La documentación de sus plataformas describe colecciones cifradas de extremo a extremo o protegidas para que el proveedor no reciba la clave privada en forma legible. Eso no elimina la dependencia: el proveedor sigue operando la cuenta, el servicio de sincronización, las reglas de recuperación y el software que controla el acceso a la colección cifrada.
¿Debo borrar la contraseña y el número usado para SMS después de añadir una clave de acceso?#
No de inmediato. Añade primero un método independiente y pruébalo desde un navegador sin una sesión iniciada, sin eliminar nada. Después retira o relega los métodos más débiles, una cuenta cada vez, si el servicio lo permite y la recuperación no depende del mismo dispositivo o proveedor.
¿Puede el soporte técnico recuperar mi cuenta si pierdo todas las claves y códigos?#
No lo des por hecho. GitHub afirma que su equipo de soporte no puede recuperar una cuenta con 2FA cuando no queda un método aceptado. Microsoft indica que el formulario para cuentas personales tampoco sirve si la verificación en dos pasos está activa y no puedes usar ninguna alternativa. Prepara el factor independiente antes de la pérdida.
Fuentes#
