web-dev-qa-db-fra.com

Stockage du secret TOTP dans la base de données, en texte brut ou crypté?

J'ai lu sur 2FA et comment il est utilisé, et ce qui m'a le plus frappé, c'est que tout le monde semble stocker le secret TOTP sous forme de texte en clair dans leur base de données.

Je comprends que vous avez besoin du secret sous forme de texte en clair afin de vérifier l'OTP, donc vous ne pouvez pas le hacher, mais ne pourriez-vous pas au moins le crypter d'une certaine manière, au cas où votre base de données serait divulguée? J'ai l'impression qu'il existe des moyens de rendre cela un peu plus sûr, mais je me demande s'il y a des chutes dans les idées que j'ai.

  1. Crypter le secret TOTP en utilisant une clé stockée sur le serveur: Ce ne serait pas idéal car vous crypteriez tout avec la même clé, mais une base de données peut être divulguée sans que l'attaquant ait un accès complet à tous fichiers sur le serveur. Dans ce scénario, au moins les secrets TOTP sont toujours protégés.
  2. Crypter le secret TOTP à l'aide du mot de passe utilisateur: Lorsque l'utilisateur se connecte et que la vérification du hachage du mot de passe est valide, le même mot de passe qui a été envoyé peut être utilisé comme clé pour crypter/décrypter le secret TOTP. Lorsque l'utilisateur configure son 2FA pour la première fois, vous exigez qu'il entre son mot de passe afin que nous puissions l'utiliser pour crypter le secret TOTP. Lorsqu'ils se connectent avec un mot de passe correct, vous déchiffrez le secret TOTP à l'aide du mot de passe et vous validez l'OTP. Si votre base de données est divulguée, le mot de passe est haché et le secret TOTP est crypté, de sorte que l'attaquant n'a aucune information sur aucun compte à moins qu'il ne connaisse le mot de passe.
  3. Combinez les deux méthodes: Combinez le mot de passe avec une clé stockée localement et utilisez-la comme clé de cryptage pour le secret TOTP. De cette façon, si la base de données est divulguée et que l'attaquant connaît le mot de passe, il ne peut toujours pas déchiffrer le secret TOTP à moins d'avoir accès à la clé stockée

Y a-t-il des défauts dans ce cas, et si oui, quels sont-ils? Je pense que tout serait mieux que de simplement stocker le TOTP en texte brut.

15
Y0lk

Où avez-vous lu sur 2FA et pourquoi supposez-vous que tout le monde stocke les clés secrètes en texte brut?

Comme vous parlez de TOTP, vous devriez probablement lire les RFC4226 et RFC6238.

Oui, par ex. le module Google PAM stocke les secrets en texte brut dans le répertoire personnel des utilisateurs. Mais veuillez noter : L'algorithme HOTP a été publié en 2005, l'iPhone 1 a été publié en 2007. Nous pouvons simplement déduire que l'algorithme HOTP n'était pas ment pour smartphones - ni l'algorithme TOTP, qui a été publié encore plus tard.

Le problème avec le chiffrement ou le texte brut devient immanent, si vous utilisez HOTP/TOTP pour vous authentifier sur une machine locale. Mais les algorithmes OTP sont conçus pour être utilisés avec un système backend de confiance. Une machine locale ne peut bien sûr pas faire confiance, car un attaquant pourrait s'asseoir devant cette même machine.

Jetez un oeil à la section 7.5 Gestion des secrets partagés, RFC4226 :

Ici, il est recommandé de crypter les secrets partagés, comme vous l'avez suggéré dans # 1. Et bien sûr, si quelqu'un obtient la clé de cryptage, l'authentification est inutile. Mais il s'agit d'un système backend que vous devez protéger. Par exemple. notre (avertissement!) logiciel open source privacyIDEA chiffre réellement les secrets partagés et si vous le souhaitez, même avec un module de sécurité matériel. (Encore une fois - c'est un système backend)

Vous voudrez peut-être également en savoir un peu plus sur les défauts de la conception de Google Authenticator: https://netknights.it/en/the-problem-with-the-google-authenticator/

1
cornelinux