Comment fonctionne le 2FA d'Authy s'il ne se connecte pas au serveur?
Je pensais savoir comment fonctionne l'authentification à deux facteurs:
- J'entre le mot de passe.
- Le serveur génère un nombre aléatoire (jeton) et me l'envoie par SMS.
- J'entre ce jeton.
- Le serveur vérifie que le jeton que j'ai entré correspond à celui généré pour ma demande 2FA précédente.
Mais aujourd'hui, j'ai découvert Authy , et il semble que je ne sais pas comment fonctionne l'authentification à deux facteurs (2FA) de ce programme.
Authy me montre des numéros secrets (jetons 2FA) sans aucune connexion avec le serveur. Comment se peut-il?
Je suppose que ces jetons ne sont pas aléatoires? Peut-être s'agit-il d'une sorte de séquence de nombres, où la connaissance des paramètres initiaux d'ensemencement en fait un processus déterministe? Peut-être que cette séquence est fonction du temps? Est-ce ainsi que cela fonctionne?
Est-ce sécurisé? Puis-je, par exemple, déterminer les prochains jetons 2FA, si je connais un [~ # ~] n [~ # ~] nombre de jetons précédents?
Authy me montrer des numéros secrets sans aucune connexion avec le serveur. Comment peut-il le faire?
Authy utilise un algorithme de code d'accès unique (OTP) qui se décline en plusieurs versions, les deux plus populaires étant OTP basé sur HMAC (HOTP) et OTP basé sur le temps (TOTP). Authy utilise TOTP.
Les deux algorithmes sont essentiellement les mêmes; ils nécessitent des données de départ et un compteur pour générer le prochain mot de passe de la série. Les implémentations HOTP incrémentent le compteur chaque fois que l'utilisateur demande/utilise un mot de passe, TOTP incrémente le compteur après un intervalle de temps donné.
Dans le cas d'Authy, lorsque l'utilisateur soumet un code d'accès au serveur, le serveur recherche les données de départ de l'utilisateur, calcule la valeur du compteur en fonction de l'horodatage de la demande, puis génère le code d'accès approprié. Le serveur vérifie ensuite que le code d'accès généré correspond au code d'accès soumis par l'utilisateur.
Est-ce sécurisé? Puis-je connaître le numéro suivant si je connais N numéros précédents?
Oui et non, cela dépend si vous faites confiance ou non à la sécurité du serveur.
Étant donné N jetons précédents, un attaquant ne devrait toujours pas être en mesure de récupérer les données de départ. Cependant, ces algorithmes nécessitent que le serveur stocke les données de départ pour tous les utilisateurs. Si un attaquant est en mesure de compromettre la base de données (par injection SQL, etc.), il pourra alors générer des codes d'accès valides. C'est ce qui est arrivé à RSA et à leurs jetons SecurID ( http://arstechnica.com/security/2011/06/rsa-finally-come-clean-securid-is-compromised/ )
Certaines entreprises comme Duo Security ( https://www.duosecurity.com/ ) et Twitter ( https://blog.Twitter.com/2013/login-verification-on-Twitter -for-iphone-and-Android ) s'attaquent à ce problème en implémentant une authentification à deux facteurs défi-réponse avec chiffrement à clé asymétrique. Ils n'ont besoin que de stocker les clés publiques dans ce cas, ce qui signifie que si leur base de données est divulguée, un attaquant ne possède pas les clés privées nécessaires pour générer des réponses valides.
Avertissement, j'ai travaillé chez Duo.
Mis à jour en fonction des questions dans les commentaires
Les algorithmes (HOTP ou TOTP) doivent être les mêmes sur le serveur et l'application cliente?
L'algorithme est identique, la façon dont la valeur du compteur est générée est différente. Si Google était HOTP et Authy voulait prendre en charge les comptes Google, leur application devrait générer et stocker la valeur du compteur différemment des comptes TOTP.
Le client HOTP nécessite-t-il une connexion avec le serveur pour obtenir le prochain mot de passe (car il ne sait pas combien de demandes ont été faites la dernière fois), alors que TOTP ne l'exige pas?
Non, HOTP ne nécessite pas de connexion pour fonctionner, mais HOTP n'est généralement pas utilisé car il est facile pour le téléphone et le serveur de se désynchroniser.
Supposons que le serveur et l'application commencent avec une valeur de compteur de 0. Le serveur a généralement une fenêtre, peut-être les 10 prochains codes d'accès, qu'il considérera comme valide. Lorsque l'utilisateur soumet un code d'accès, le serveur compare le code d'accès soumis avec les 10 codes d'accès suivants générés. Si l'un des 10 correspond, le serveur peut mettre à jour la valeur du compteur stocké et rester synchronisé.
Cependant, le problème est que l'utilisateur peut générer trop de codes d'accès dans l'application sans les utiliser. Si l'utilisateur peut incrémenter le compteur au-delà de la taille de la fenêtre de code d'accès, le serveur ne peut plus vérifier que les codes d'accès sont valides.
Pour voir en détail comment les jetons OTP sont générés, voir ce blogpost informatif .
Il semble qu'il communique à l'aide d'une simple REST API. En termes de sécurité des jetons -
Le jeton est généré à l'aide d'une fonction à sens unique (SHA-2) et d'une clé de 256 bits. Même si l'attaquant avait accès à des centaines de jetons, il lui serait encore mathématiquement impossible de générer un nouveau jeton valide. Si vous êtes enclin à en savoir plus, Authy est basé sur RFC4426 ( http://www.ietf.org/rfc/rfc4226.txt ).
En bref - Oui, il utilise une méthode sécurisée pour générer un jeton.