2017-10-08 1 views
2

Certains suggèrent que l'utilisation de la comparaison de chaîne simple pour faire correspondre les mots de passe n'est pas sûre en raison de timing attacks. Par exemple, voir this question. Eh bien, j'ai essayé de mesurer la différence de temps entre deux suppositions de mot de passe dans node.js. Voici le code:La comparaison de chaînes est-elle vraiment non sécurisée?

const pass = '................................................................'; 
 
const guess1 = '..X.............................................................'; 
 
const guess2 = '.............................................................X..'; 
 

 
function ns(hrtime) { 
 
    return hrtime[0] * 1e9 + hrtime[1]; 
 
} 
 

 
test(guess1); 
 
test(guess2); 
 
test(guess1); 
 
test(guess2); 
 
test(guess1); 
 
test(guess2); 
 
test(guess1); 
 
test(guess2); 
 
test(guess1); 
 
test(guess2); 
 
test(guess1); 
 
test(guess2); 
 

 
function test(guess) { 
 
    const start = process.hrtime(); 
 
    for (let i = 0; i < 1e5; ++i) { 
 
    if (guess === pass) throw new Error('HIT'); 
 
    } 
 
    const time = ns(process.hrtime(start)); 
 
    console.log('%d ns %s', time, guess); 
 
}

Voici le résultat d'une exécution sur ma machine:

2073045 ns ..X............................................................. 
58420 ns .............................................................X.. 
57778 ns ..X............................................................. 
57468 ns .............................................................X.. 
57554 ns ..X............................................................. 
57436 ns .............................................................X.. 
57589 ns ..X............................................................. 
57798 ns .............................................................X.. 
57798 ns ..X............................................................. 
57506 ns .............................................................X.. 
57969 ns ..X............................................................. 
57974 ns .............................................................X.. 

Il semble y avoir aucune corrélation entre le temps et le mot de passe différent suppositions. Est-ce que je fais quelque chose de mal ou il n'y a vraiment pas de différence de temps mesurable?

+2

Les gens n'ont pas fait ce risque. Faites un peu de recherche car beaucoup a été écrit sur le sujet et juste parce que vous ne le reproduisez pas au premier essai ne signifie pas qu'il n'existe pas. Reportez-vous à la section [Temporisation des attaques par rapport à la comparaison de chaînes] (https://thisdata.com/blog/timing-attacks-against-string-comparison/) et [Utilisation de la boucle d'événements node.js pour les attaques de synchronisation] (https://snyk.io/blog/node-js-timing-attaque-ccc-ctf /) et des centaines d'autres références trouvées facilement dans une recherche Google. – jfriend00

+1

Pour ajouter à mon commentaire précédent, le fait qu'il existe ou non un risque de temps réel dépend de la circonstance et du code précis utilisés. Donc, il faudrait montrer un exemple réel de code de production afin d'évaluer le risque de timing. Pour éviter de vous inquiéter de savoir si vous avez ou non une situation qui présente un tel risque, nombreux sont ceux qui choisiront simplement d'utiliser une comparaison neutre en termes de temps comme moyen le plus simple d'être en sécurité. – jfriend00

Répondre

2

1) J'espère que vous avez haché les mots de passe en toute sécurité. Cela signifie que l'on peut chronométrer à quel point les hachages sont proches les uns des autres. Tant que la fonction de hachage est sûre, ce n'est pas utile du tout.

2) Il y a une différence entre la mesure directe sur la machine et une attaque réelle. Quand un attaquant lance une requête qui inclura la latence du réseau ainsi que la latence de node.js. Si nous parlons de nanosecondes, personne ne remarquera de différence.

+0

Si vous ne pouvez pas le mesurer dans le processus, vous pouvez le mesurer encore moins de l'extérieur. Ou suggérez-vous que hrtime fournit un timing incorrect? –

+0

@peter non c'est exactement ce que 2) devrait signifier –