11
votes

Prévenir les attaques de timing

Il semble que pendant un moment , l'utilitaire de connexion sur UNIX Systems n'a que calculé un hachage quand un nom d'utilisateur valide existait; Cela a ouvert une faille de sécurité autorisée à une attaque de synchronisation, car l'utilisateur pouvait indiquer lorsqu'un nom d'utilisateur a été trouvé à la quantité de temps nécessaire pour générer une clé hachée à la comparaison.

Cela donne un sens aux applications de bureau, mais cela aurait-il un sens aux applications Web aussi? Je me pencherais vers le faire, mais ce genre de solution est-il nécessaire? p>

Par exemple, dans un module d'authentification Django: P>

class MyBackend(ModelBackend):

    def authenticate(self, email=None, password=None):
        try:
            user = User.objects.get(email=email)
            return user if user.check_password(password) else None
        except User.DoesNotExist:
            User().check_password(password) # is this line necessary?
            return None

security

3 commentaires

+1 C'est une vraie préoccupation. Que se passe-t-il si quelqu'un tente de s'inscrire avec un email qui existe déjà?

Je filtre déjà ceux-ci, ce n'est pas vraiment la question de la question.

L'exposition des utilisateurs est la question de la question. Cela peut arriver de nombreuses manières différentes.

3 Réponses :

1
votes

Pourrait ne pas être une réponse définitive, mais il semble que vous puissiez pouvoir vous assurer que toutes les opérations de contrôle de nom d'utilisateur ont pris la même quantité de temps. Faites-leur d'aller dans un état d'attente après leur fin de finition jusqu'à ce qu'un temps prédéterminé soit passé.

1 commentaires

En ce qui concerne votre principale question, je ne pense pas que cette attaque n'aurait aucune incidence sur un réseau, car le temps de retour dépendrait de la charge du serveur, qui peut varier chaque fois que la demande est effectuée.

10
votes

L'attaque de chronométrage originale, le Tenex Attack , n'a rien à voir avec le hachage - cela a fonctionné en positionnant le mot de passe pour qu'elle a traversé les limites de la page menant à une mémoire de mémoire virtuelle Miss. L'attaquant pourrait essayer une série de mots de passe positionnés de manière à ce que seul le premier caractère était dans la première page, et sachez que le premier caractère correspondant lorsque la vérification a pris assez longtemps pour que le cache manquait de se soit passé. L'attaquant pourrait répéter que pour chaque caractère du mot de passe.

Sauf si l'attaquant n'a pas de contrôle sur le positionnement fin-grain des entrées en mémoire, aucune attaque de chronométrage sur les mots de passe n'est pas un problème, mais un enregistrement secret algo qui est super- WRT linéaire la longueur du secret (> = o (longueur de secret)) peut éduquer des informations sur la longueur du mot de passe. p>

Si vous faites attention à comparer tous les caractères du mot de passe, quel que soit le succès, vous vaincuez également le Attaque: P>

boolean match = true;
for (int i = 0; i < min(salted_from_db_length, salted_from_user_length); ++i) {
  if (salted_from_db[i] != salted_from_user[i]) {
    match = false;
    //break;  // Stopping early leaks info.
  }
}
match = salted_from_db_length == salted_from_user_length && match;

0 commentaires

2
votes

C'est une bonne question, et oui, vous devriez envisager de prendre des mesures pour vous assurer que le temps nécessaire pour renvoyer une réponse «logon refusé» pour un nom d'utilisateur non valide est comparable à celui d'un nom d'utilisateur valide avec un mot de passe incorrect.

Les attaques de chronométrage ont été utilisées dans le cas où le nom d'utilisateur est connu afin de découvrir le hachage de, et éventuellement du mot de passe lui-même, en analysant la quantité de temps nécessaire au serveur pour effectuer la comparaison des chaînes, d'où l'utilisation de une fonction «Slow_equals» pour comparer les hachages et qui ne quitte pas tôt la recherche d'une inadéquation.

En cas de panne de connexion, vous ne devriez jamais faire rapport que ce soit le nom d'utilisateur ou mot de passe est incorrect, car cela serait alors aider un attaquant de découvrir les noms d'utilisateur valides (bien que vous devriez probablement informer l'utilisateur pourquoi vous ne leur dire si C'est le nom d'utilisateur ou le mot de passe qu'ils ont eu mal, car il a tendance à les résoudre autrement).

Un attaquant aléatoire doit découvrir des noms d'utilisateur valides, puis les mots de passe pour eux. Si vous les aidez à découvrir des noms d'utilisateur valides, ils sont à mi-chemin. Donc, s'ils peuvent découvrir des noms d'utilisateur valides en fonction du temps qu'il faut votre script de connexion pour retourner un échec, vous les aiderez.

Considérons le processus: 1. Requête de base de données pour récupérer le hachage et le sel; 2. Mot de passe hachage avec du sel; 3. Comparez le hachage récupéré avec hachage généré à partir du mot de passe fourni.

La requête exit tôt quand il trouve l'enregistrement correspondant? Cela peut faire si nous spécifiions une clé unique pour la colonne Nom d'utilisateur, nous ne devrions donc probablement pas faire cela et avoir d'autres mécanismes en place pour éviter la duplication lorsque nous modifions la DB.
Effectuons-nous ces étapes ultérieures si la requête de DB n'a trouvé aucun enregistrement? (Est-ce que votre processus de hachage prend un peu de temps?) Il suit donc qu'un hasch "par défaut" et du sel doit être utilisé si le nom d'utilisateur n'est pas correspondant pour compléter le processus de temps constant [et c'est la raison de la raison de la code de gestionnaire d'exception dans le q].
Utilisez 'slow_equals' ici.
Un répondeur a suggéré ici que la variance de la latence de réseau rend ce non-problème. Je soutiens qu'un attaquant n'a pas besoin d'un taux de réussite de 100% et que l'analyse statistique sera révélatrice. Vous ne pouvez pas être trop prudent.

0 commentaires