Auteur Sujet: Sécurité contre l'écoute lors de la connexion lafibre.info (Lu 14257 fois)

corrector · « **le:** 05 juillet 2013 à 01:12:20 »

Je constate avec plaisir que le formulaire de connexion à lafibre.info est protégé contre l'écoute passive indépendamment de la sécurisation du transport :

Lors du login, les données sont :
user=corrector&passwrd=&cookieneverexp=on&hash_passwrd=d0e8581e75baad853b310e2fde3fbb86bcc4d754

en effet le formulaire est [1] :

<form action="https://lafibre.info/login2/" name="frmLogin" id="frmLogin" method="post" accept-charset="UTF-8" onsubmit="hashLoginPassword(this, 'd3de1bd9345835ceb39bc81fb4c06c27');">

la fonction hashLoginPassword(doForm, cur_session_id) qui contient notamment :

doForm.hash_passwrd.value = hex_sha1(hex_sha1(doForm.user.value.php_to8bit().php_strtolower() + doForm.passwrd.value.php_to8bit()) + cur_session_id);

donc au lieu d'envoyer le mot de passe, le script envoie :

hash = SHA-1(SHA-1(lower (login) || password) || sid)

S -> C : sid
C -> S : login, hash

notations :

S = serveur
C = client
|| indique la concaténation

J'ai indiqué les données transmises explicitement par HTTP, mais je n'ai pas indiqué les données "ambiantes" [2], qui sont envoyées automatiquement (les cookies HTTP).

On voit que non seulement le mot de passe est haché, mais surtout le haché n'est pas un authentifiant rejouable : un adversaire ne peut pas capturer hash et l'envoyer à nouveau, parce qu'il faut que le sid corresponde.

Je suppose que le sid est lié au PHPSESSID.

Notes :

[1] mon mot de passe ne peut pas être testé à partir de ce hachage, qui est basé sur un mot de passe faux ("toto").
[2] comme les variables d'environnement Unix sont passées à tous les processus, automatiquement (sauf si on s'y oppose en utilisant execve au lieu de exec/execv)

BadMax · « **Réponse #1 le:** 05 juillet 2013 à 16:31:18 »

C'est pas faux.

corrector · « **Réponse #2 le:** 08 juillet 2013 à 17:45:48 »

Rappel du contexte :

Un client veut s'authentifier auprès d'un authentificateur (ici le serveur HTTP); il ne veut pas transmettre le mot de passe au serveur (même pas dans un tunnel chiffré).

Revenons sur la formule :

h = SHA-1(SHA-1(login || pw) || sid)

sid est un "nonce" : un numéro aléatoire [1] généré par l'authentificateur, qui est donc unique.

[1] aléatoire au sens cryptographique : la probabilité de le prédire est infime

Ce calcul est exécuté sur le client, qui par définition connait le mot de passe; mais on voit qu'on peut écrire la formule sous la forme :

hash = hash(hpw || sid)
hpw = hash(login || pw)

hash = SHA-1
pw = mot de passe

Quel est l'intérêt de cette remarque? Pourquoi décomposer ce calcul?

Suite au prochain épisode...

corrector · « **Réponse #3 le:** 09 juillet 2013 à 12:35:21 »

Parce que les données au repos sont vulnérables :
- certaines la base de données peuvent être récupérées par des failles stupides, comme les injections de code (aucun système ne doit pouvoir être vulnérable à ça; si vous pouvez être vulnérable, c'est que vous vous y prenez mal)
- certains protègent bien les serveurs, mais laissent traîner des sauvegardes en clair un peu partout
etc.

donc il est bon ne pas conserver trop de données en mémoire de masse sur le serveur : il serait souhaitable que si un adversaire récupère une copie de la base de données des utilisateurs :

1) il ne prenne pas connaissance des mots de passe en clair : pour ça, il ne faut donc pas que la base contienne les mots de passe en clair ou chiffrés d'une façon que le serveur sait déchiffrer;

2) il ne puisse pas usurper l'identité d'un utilisateur : pour ça, il faut donc que la base ne contienne pas les données qui permettent de s'authentifier auprès du serveur

1) Pour cela, on utilise une fonction "one way" (non inversible), c'est à dire un hachage cryptographique; on peut par exemple remplacer partout pw par hpw = hash(login || pw)

Le serveur ne stocke pour chaque utilisateur que hpw; ainsi le serveur ne peut pas récupérer les valeurs de pw à partir de la base de données. Lors d'une tentative d'authentification, il génère sid et peut calculer hash(hpw || sid) et le comparer à la valeur envoyée par le client.

2) Pour cela, on utilise aussi une fonction "one way" : le serveur demande un authentificateur, il applique une fonction non inversible et compare à une valeur connue :

Le serveur stocke hpw = hash(login || pw) pour chaque utilisateur.

Le protocole est simplement :

C->S : login,pw

Le serveur recalcule hash(login || pw) et compare à la valeur hpw stockée.

1) Dans ce cas, le serveur connaissant hpw peut usurper l'identité de n'importe quel utilisateur.

2) Dans ce cas, le serveur ne connaissant pas l'authenficateur pw, ne peut pas usurper l'identité d'un utilisateur.

On peut bien sûr combiner un peu les deux approches :

3) On évite de manipuler/stocker/transmettre pw, on utilise à place : hpw = hash(login || pw)

Le code secret est donc hpw et non pw.

On évite de transmettre hpw : on transmet l'authentificateur auth = hash(hpw); le serveur stocke hpw.

C->S : login,auth

Le serveur peut vérifier que auth = hash(hpw)
Donc
- le serveur ne dispose pas du mot de passe en clair (mais il dispose de hpw en clair)
- hpw n'est jamais transmis
- mais la propriété 2) n'est pas garantie : le serveur a l'info pour usurper n'importe quelle identité.

corrector · « **Réponse #4 le:** 09 juillet 2013 à 12:37:24 »

Citation de: corrector le 08 juillet 2013 à 17:45:48

Rappel du contexte :

Un client veut s'authentifier auprès d'un authenficateur (ici le serveur HTTP); il ne veut pas transmettre le mot de passe au serveur (même pas dans un tunnel chiffré).

Revenons sur la formule :

h = SHA-1(SHA-1(login || pw) || sid)

Supposons qu'on utilise une formule proche :

h = SHA-1(SHA-1(login || sid) || pw)

Quel impact?

Electrocut · « **Réponse #5 le:** 09 juillet 2013 à 13:47:11 »

Il faudrait alors, afin de pouvoir appliquer la formule, que le serveur stocke "pw" pour chaque client, ce qui n'est pas souhaitable

J'ai bon ?

corrector · « **Réponse #6 le:** 09 juillet 2013 à 14:11:06 »

Exact!

On perd donc la propriété (1).

Optrolight · « **Réponse #7 le:** 09 juillet 2013 à 18:31:19 »

Je comprends un peu mieux les mail envoyés par ubisoft par exemple quand ils disent que les mots de passe ou données bancaires n'ont pas été impactés.

corrector · « **Réponse #8 le:** 10 juillet 2013 à 00:28:13 »

Ah bon?

Tu peux m'expliquer?

Optrolight · « **Réponse #9 le:** 10 juillet 2013 à 20:59:40 »

Avec les explications ici, je comprends mieux pourquoi les donnés ne sont pas toutes sur le même serveur et pourquoi en cas d'attaque comme celle qu'a eu ubisoft, les données bancaires et autres ne sont pas impactés alors que les loging oui.

corrector · « **Réponse #10 le:** 12 juillet 2013 à 21:07:31 »

Citation de: corrector le 05 juillet 2013 à 01:12:20

Je constate avec plaisir que le formulaire de connexion à lafibre.info est protégé contre l'écoute passive indépendamment de la sécurisation du transport :

Lors du login, les données sont :
user=corrector&passwrd=&cookieneverexp=on&hash_passwrd=d0e8581e75baad853b310e2fde3fbb86bcc4d754

en effet le formulaire est [1] :

<form action="https://lafibre.info/login2/" name="frmLogin" id="frmLogin" method="post" accept-charset="UTF-8" onsubmit="hashLoginPassword(this, 'd3de1bd9345835ceb39bc81fb4c06c27');">

la fonction hashLoginPassword(doForm, cur_session_id) qui contient notamment :

doForm.hash_passwrd.value = hex_sha1(hex_sha1(doForm.user.value.php_to8bit().php_strtolower() + doForm.passwrd.value.php_to8bit()) + cur_session_id);

Question suivante :

Quel est le risque quand on se connecte à https://lafibre.info/unread/ ?

corrector · « **Réponse #11 le:** 12 juillet 2013 à 21:12:29 »

Citation de: Optrolight le 10 juillet 2013 à 20:59:40

Avec les explications ici, je comprends mieux pourquoi les donnés ne sont pas toutes sur le même serveur et pourquoi en cas d'attaque comme celle qu'a eu ubisoft, les données bancaires et autres ne sont pas impactés alors que les loging oui.

Le coup de "on a été piraté, mais rien d'important n'a été atteint", j'ai comme du mal à y croire...

Par définition, piratage = ça ne s'est pas du tout passé comme prévu.

Sinon, on aurait dit : "notre pot de miel a fonctionné".