Discussion :

[laclac]

un ami vient de me donner la réponse : pour un serveur web, il est possible de récupérer son stamp...

A ma connaissance cela n'existe pas. Il s'est mélangé les pinceaux, la fonction existe mais côté serveur. Tu ne peux pas côté client connaitre le temps d'execution sur le serveur à distance (la norme http n'en fais pas part).

Imaginons qu'il rentre le mot de passe "toto", et que les hacker arrivent tant bien que mal à trouver que les deux premières lettres du hach sont les bonnes. Ils font quoi ensuite... ils essaient "touo" "totp" ? le hache va changer complétement... ça ne rime à rien...

Effectivement avec un hash son attaque tombe à l'eau (coté serveur). Effectivement un hash coté client n'a pas réellement de sens autant utiliser https.

Conclusion: je pense qu'on est d'accord pour dire qu'il vaut mieux pas céder la sécurité à

Nate Lawson (fondateur de Root Labs) et Taylor Nelson deux experts en sécurité informatique

initiateur de ce faux probleme.

[susanoo]

En, il faut faire attention et être à l'affût de toutes failles!
Pas facile à priori, mais rien n'est facile non plus!
Bon courage à tous les maîtres de la sécurité et merci aux hackers qui les poussent à employer tout leur génie!

[bill86]

...Certains développeurs Web réfutent ces thèses et affirment que d'autres facteurs (les "network jitter") ont une influence sur le temps de réponse d'un PC et peuvent soit l'accélérer, soit le ralentir. DE ce fait, et selon eux, il serait impossible d'obtenir un résultat assez précis (de l'ordre de la nanoseconde) pour réaliser une timing attack sur Internet.

Ceci est d'autant plus vrai surtout sur un réseau totalement décentralisé tel que internet, ça sera très difficile de mesurer les temps de réponses avec exactitude si on tient compte de la bande passante qui nous est fournie par les FAI.

...Ils ne dévoileront pas la liste des produits atteints tant qu'ils ne seront pas patchés. La solution qu'ils proposent : reprogrammer le système pour qu'il envoie une réponse d'un temps égal en cas de mot de passe correct comme de mot de passe erroné, ce qui ne prendrait que 6 lignes de code d'après Lawson.

Voilà une idée très simple pour contrer le problème (s'il existe)

[StreamEarth]

Moi je dirais que c'est un peu le code qui rime à rien, le système qui vérifie par une boucle caractère par caractères...

Pourquoi ne pas vérifier simplement la chaine si a = b et renvoyer la réponse positive ou négative. La au moins il n'y a pas de temps de réponse etc.

[henolivier]

Moi je dirais que c'est un peu le code qui rime à rien, le système qui vérifie par une boucle caractère par caractères...

Pourquoi ne pas vérifier simplement la chaine si a = b et renvoyer la réponse positif ou négatif. Là au moins il n'y a pas de temps de réponse etc.

Ce n'est pas aussi simple, la plupart des langages lorsque tu leurs donnes à comparer 2 chaines de caractères vont comparer les caractères un par un, tu auras donc l'impression d'une comparaison globale alors que ce sera une comparaison caractère par caractère (avec arrêt au premier différent).

Java en est un très bon exemple. il te suffit de regarder le code source de la méthode equals de String pour comprendre, alors que c'est exactement cette méthode que tu appellerais pour vérifier 2 chaines.

[cs_ntd]

Pour le Network jitter, il me semble qu'il y a des réponses dans ces documents (comment le mesurer, en faire des statistiques, etc... j'ai pas tout lu encore ) :

IP Packet Delay Variation Metric for IP Performance Metrics (IPPM) : RFC3393
A One-way Delay Metric for IP Performance Metrics : RFC2679
Framework for IP Performance Metrics : RFC2330

En sachant que le premier se base sur le 2ème, qui lui se base sur le 3ème.

En plus aujourd'hui en DSL et avec les capacités de calcul d'un ordi, c'est facile de mesurer en temps réel l'état du réseau sur un chemin (avec plusieurs lignes on peut facilement mesurer l'état du réseau à la nanoseconde près, avec une ligne 20Mb/s et peu d'heuristique et de proba, on peut mesurer de l'ordre de 10µs (microseconde) - je pense).

[iguypouf]

Très intéressant tout ça.

Personnellement, j'ajoute une petite couche lors du login.

La page qui va proposer un login - password génére un "login_request" dans la DB, qui n'est valable qu'une fois. Lors de la comparaison pour authentification, d'abord le système vérifie que le "Login_Request" envoyé est valide dans la DB, et seulement alors il compare les login et password.

De cette manière,
- il devient beaucoup plus dur de tenter de se co via un "$_POST final" lancé depuis ailleurs que ma propre page
- le temps de réponse n'est pas QUE le login - pw.

Qu'en pensez-vous ?

[jblecanard]

C'est pas mal aussi, bien que je continue de penser qu'un bon hashage du mot de passe est bien suffisant.