La Fibre

Télécom => Réseau => reseau Protocoles réseaux sécurisés (https) => Discussion démarrée par: corrector le 05 juillet 2013 à 01:12:20

Titre: Sécurité contre l'écoute lors de la connexion lafibre.info
Posté par: 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) (https://lafibre.info/Themes/default/scripts/script.js?fin20) 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 (http://linux.die.net/man/2/execve) au lieu de exec/execv)
Titre: Sécurité contre l'écoute lors de la connexion lafibre.info
Posté par: BadMax le 05 juillet 2013 à 16:31:18
C'est pas faux.
Titre: Sécurité contre l'écoute lors de la connexion lafibre.info
Posté par: corrector 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...
Titre: Sécurité contre l'écoute lors de la connexion lafibre.info
Posté par: corrector 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é.
Titre: Sécurité contre l'écoute lors de la connexion lafibre.info
Posté par: corrector 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?
Titre: Sécurité contre l'écoute lors de la connexion lafibre.info
Posté par: Electrocut 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 ?  :P
Titre: Sécurité contre l'écoute lors de la connexion lafibre.info
Posté par: corrector le 09 juillet 2013 à 14:11:06
Exact!

On perd donc la propriété (1).
Titre: Sécurité contre l'écoute lors de la connexion lafibre.info
Posté par: Optrolight 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.
Titre: Sécurité contre l'écoute lors de la connexion lafibre.info
Posté par: corrector le 10 juillet 2013 à 00:28:13
Ah bon?

Tu peux m'expliquer?
Titre: Sécurité contre l'écoute lors de la connexion lafibre.info
Posté par: 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.
Titre: Sécurité sur http://lafibre.info/unread/
Posté par: corrector 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) (https://lafibre.info/Themes/default/scripts/script.js?fin20) 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/ (https://lafibre.info/unread/) ?
Titre: "on a été piraté, mais rien d'important n'a été atteint"
Posté par: corrector 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é".
Titre: Sécurité contre l'écoute lors de la connexion lafibre.info
Posté par: Optrolight le 13 juillet 2013 à 12:17:05
Je suis daccord qu'il faut rester vigilent mais d'autre évenement de ce genre ont révéler par al suite exactement les fuites qu'il y a eu. Donc je ne fait pas une confiance aveugle mais je m'inquiète pas trop non plus.
Titre: Problème de l'usage de la concaténation dans un protocole cryptographique
Posté par: corrector le 11 novembre 2013 à 05:15:01
Citation de: corrector le 05 juillet 2013 à 01:12:20
donc au lieu d'envoyer le mot de passe, le script envoie :

hash = SHA-1(SHA-1(lower (login) || password) || sid)
On remarque qu'il y a là une fonction non injective : la concaténation de (login = toto, password = tata) donnera le même résultat qu'avec (login = totota, password = ta).

QUESTIONS

Pensez-vous que cela peut poser problème? Pourquoi?

Est-ce que l'usage de fonction non injective comme entrée d'une hachage cryptographique peut poser problème en général?
Titre: Problème de l'usage de la concaténation dans un protocole cryptographique
Posté par: Marin le 11 novembre 2013 à 07:43:30
Citation de: corrector le 11 novembre 2013 à 05:15:01
Pensez-vous que cela peut poser problème?

Non.

Citation de: corrector le 11 novembre 2013 à 05:15:01
Pourquoi?

Car le nom d'utilisateur est transmis en clair dans le paramètre POST user, ainsi il n'y a pas de confusion possible pour le serveur.

Citation de: corrector le 11 novembre 2013 à 05:15:01
Est-ce que l'usage de fonction non injective comme entrée d'une hachage cryptographique peut poser problème en général?

Oui, dans le cas où il n'y aurait pas ce genre de vérification supplèmentaire.
Titre: Problème de l'usage de la concaténation dans un protocole cryptographique
Posté par: corrector le 11 novembre 2013 à 17:59:10
Citation de: Marin le 11 novembre 2013 à 07:43:30
Non.

Car le nom d'utilisateur est transmis en clair dans le paramètre POST user, ainsi il n'y a pas de confusion possible pour le serveur.
Mais le contenu peut être intercepté et modifié, ou bien le POST peut être refait avec un autre user...
Titre: Sécurité contre l'écoute lors de la connexion lafibre.info
Posté par: Optrolight le 12 novembre 2013 à 20:14:16
Oui et donc il n'y aura plus correspondant id mot de pass non?
Titre: Sécurité contre l'écoute lors de la connexion lafibre.info
Posté par: corrector le 12 novembre 2013 à 21:29:30
En fait la collision est "exploitable", mais les conditions pour la provoquer sont de connaitre les mots de passe.

Donc le problème n'existe pas (si on connait le mot de passe d'un autre compte aucune attaque cryptographique contre ce compte n'a de sens, on utilise le mdp point). Mais la concaténation non injective est un souci en général.
Titre: Sécurité contre l'écoute lors de la connexion lafibre.info
Posté par: jack le 12 novembre 2013 à 23:30:03
Mouais, j'ai déjà vu ce genre de méthodologie.

Au final, tu ninja le cookie et hop
Titre: Sécurité contre l'écoute lors de la connexion lafibre.info
Posté par: corrector le 13 novembre 2013 à 00:42:49
C'est pour ça qu'il faut quand même utiliser HTTPS.

Le système de hachage chez le client ne protège que le mdp contre l'écoute passive, mais si le reste est en clair, ça ne protège pas la session!
Titre: Sécurité contre l'écoute lors de la connexion lafibre.info
Posté par: jack le 13 novembre 2013 à 11:10:33
Tu peux me redire ce que tu entends par "écoute passive" ?
Titre: Sécurité contre l'écoute lors de la connexion lafibre.info
Posté par: corrector le 13 novembre 2013 à 11:31:55
Prenons un forum sous SMF, qui n'est pas en HTTPS (contrairement à lafibre.info).

Faire un tcpdump sur la ligne où passent les données. Tu récupères les données échangées en HTTP, sans modifier quoi que ce soit.

Si tu fais ça sur un forum SMF, tu ne récupères pas le mdp, mais tu as le cookie HTTP.
Titre: A
Posté par: Electrocut le 25 octobre 2014 à 18:22:19
Bonjour :)

Dans le cadre du boulot, j'ai besoin de mettre en place un système d'authentification, avec BDD de données d'authentification.
Du coup, je repasse sur ce topic, pour m'inspirer des pratiques dans ce domaine ;)

Je comprends donc que dans le cas de l'authentification sur lafibre.info, le serveur stocke dans sa base, les éléments suivants :

La phase d'authentification se déroule ainsi :

Je crois voir plusieurs problèmes :

1- Si une personne vole la base utilisateurs, elle peut s'authentifier en tant que n'importe qui.

En effet, en récupérant SHA-1(lower (login) || password), elle peut dorénavant construire la réponse hash = SHA-1(SHA-1(lower (login) || password) || sid).
En d'autres termes, la propriété 2 énoncée par corrector n'est pas couverte :
Citation de: corrector le 09 juillet 2013 à 12:35:21
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

2- La fonction de hachage est basée sur l'algorithme SHA1.

D'après ce que j'ai lu ailleurs, afin de limiter les risques d'attaques par bruteforce, il est conseillé d'utiliser plutôt des fonctions de hachage "lente", telle que bcrypt.

-> Effectivement, la solution de vivien évite que le mot de passe ne transite, durant la phase authentification.
Cependant, en cas de vol de la base utilisateur, l'attaquant peut faire ce qu'il veut.

Sachant que lafibre.info utilise dorénavant du HTTPS, ne vaudrait-t-il pas mieux que le client envoie carrèment son mot de passe, lors de l'authentification ?
Pour vérifier le mot de passe, le serveur calculerait alors SHA-1(lower (login) || password), et vérifierait que le résultat correspond bien à la valeur stockée.
Dès lors, un vol de SHA-1(lower (login) || password) ne permettrait plus de s'authentifier.

Ais-je bien compris ? Avez-vous des remarques à ce sujet ?
Titre: Sécurité contre l'écoute lors de la connexion lafibre.info
Posté par: Electrocut le 25 octobre 2014 à 18:55:11
Je poursuis un peu ma réflexion.

J'ai lu que la bonne pratique, pour le stockage d'informations d'authentification utilisateur sur un serveur, était de stocker en base de donnée, pour chaque utilisateur les éléments suivants :
salt étant choisi aléatoirement, différent pour chaque utilisateur
pepper étant codé en dur quelque part (idéalement, offusqué).

Avec une telle méthode de stockage côté serveur, peut-t-on protéger la confidentialité du mot de passe, durant la phase d'authentification ? (sans reposer sur la sécurisation de la couche transport)
En effet, pour que le serveur puisse calculer (et vérifier) bcrypt (pepper || password || salt), je ne vois pas d'autre solution de procéder que d'envoyer le mot de passe en clair (ex : authentification HTTP Basic).

Procéder autrement (ex : que le serveur envoie pepper et salt au client, pour que celui-ci calcule bcrypt (pepper || password || salt)) nous ferait retomber dans travers décrit dans mon précédent post (un vol de BDD permettant alors de s'authentifier)

J'en tire donc la conclusion suivante. Il faut choisir son camp entre 2 méthodes :

La meilleur méthode étant donc la 1 + HTTPS.

Ma réflexion (et sa conclusion) sont-t-elles correctes ?
D'avance merci pour vos éclaircissement ou corrections  ;)
Titre: Sécurité contre l'écoute lors de la connexion lafibre.info
Posté par: corrector le 25 octobre 2014 à 22:14:14
Plusieurs commentaires rapides :

- L'idée du poivre est d'être archi-protégé, il n'apparaît jamais en BDD (donc il n'est pas attaquable via SQL, ni via une sauvegarde de la BDD), il est dans un fichier spécial auquel seul le processus d'authentification accède, si n'importe quel client peut le récupérer ça n'apporte plus rien, autant le virer, le sel suffit bien.

- Comme fonction lente, bcrypt est vieux, scrypt est plus à la mode.

- L'analyse est imparable si on se limite à la crypto symétrique.
Titre: Sécurité contre l'écoute lors de la connexion lafibre.info
Posté par: corrector le 25 octobre 2014 à 23:11:28
SRP Protocol Design

SRP is the newest addition to a new class of strong authentication protocols that resist all the well-known passive and active attacks over the network. SRP borrows some elements from other key-exchange and identification protcols and adds some subtle modifications and refinements. The result is a protocol that preserves the strength and efficiency of the EKE family protocols while fixing some of their shortcomings.
The following is a description of SRP-6 and 6a, the latest versions of SRP:

  N    A large safe prime (N = 2q+1, where q is prime)
       All arithmetic is done modulo N.
  g    A generator modulo N
  k    Multiplier parameter (k = H(N, g) in SRP-6a, k = 3 for legacy SRP-6)
  s    User's salt
  I    Username
  p    Cleartext Password
  H()  One-way hash function
  ^    (Modular) Exponentiation
  u    Random scrambling parameter
  a,b  Secret ephemeral values
  A,B  Public ephemeral values
  x    Private key (derived from p and s)
  v    Password verifier

The host stores passwords using the following formula:

  x = H(s, p)               (s is chosen randomly)
  v = g^x                   (computes password verifier)

The host then keeps {I, s, v} in its password database. The authentication protocol itself goes as follows:

User -> Host:  I, A = g^a                  (identifies self, a = random number)
Host -> User:  s, B = kv + g^b             (sends salt, b = random number)

        Both:  u = H(A, B)

        User:  x = H(s, p)                 (user enters password)
        User:  S = (B - kg^x) ^ (a + ux)   (computes session key)
        User:  K = H(S)

        Host:  S = (Av^u) ^ b              (computes session key)
        Host:  K = H(S)

Now the two parties have a shared, strong session key K. To complete authentication, they need to prove to each other that their keys match. One possible way:

User -> Host:  M = H(H(N) xor H(g), H(I), s, A, B, K)
Host -> User:  H(A, M, K)

The two parties also employ the following safeguards:
The user will abort if he receives B == 0 (mod N) or u == 0.
The host will abort if it detects that A == 0 (mod N).
The user must show his proof of K first. If the server detects that the user's proof is incorrect, it must abort without showing its own proof of K.

http://srp.stanford.edu/design.html (http://srp.stanford.edu/design.html)

COMMENTAIRE

Toute ressemblance avec Diffie–Hellman est purement fortuite ... ou pas!
Titre: Sécurité contre l'écoute lors de la connexion lafibre.info
Posté par: Electrocut le 26 octobre 2014 à 19:39:18
Merci pour ta réponse
Citation de: corrector le 25 octobre 2014 à 22:14:14
Plusieurs commentaires rapides :

- L'idée du poivre est d'être archi-protégé, il n'apparaît jamais en BDD (donc il n'est pas attaquable via SQL, ni via une sauvegarde de la BDD), il est dans un fichier spécial auquel seul le processus d'authentification accède, si n'importe quel client peut le récupérer ça n'apporte plus rien, autant le virer, le sel suffit bien.
Tout à fait.
Je note pour les conseils de mise en place ;)

Citer
- Comme fonction lente, bcrypt est vieux, scrypt est plus à la mode.
Je note :)

Citer
SRP Protocol Design.
...
Merci pour cette solution, qui permet à la fois :
En revanche, il faut avouer qu'on monte tout de suite d'un cran en terme de complexité algorithmique, de complexité des échanges (nombreux allers retours clients <-> serveurs), et de complexité de mise en œuvre.

A noter que je viens de tomber sur une question d'un utilisateur, dont la réflexion l'avait amené à se poser la même question que moi :
How can salted, hashed password storage be combined with a plaintext, nonce and hash based authentication? (http://security.stackexchange.com/questions/38845/how-can-salted-hashed-password-storage-be-combined-with-a-plaintext-nonce-and)

Et la réponse qui lui a été proposée est ... Secure Remote Password protocol (https://en.wikipedia.org/wiki/Secure_Remote_Password_protocol) (SRP Protocol)
Voilà qui est rassurant, ça converge avec ta suggestion ;D
Titre: Sécurité contre l'écoute lors de la connexion lafibre.info
Posté par: corrector le 26 octobre 2014 à 21:25:13
Citation de: Electrocut le 26 octobre 2014 à 19:39:18
Merci pour cette solution, qui permet à la fois :
  • De protéger la confidentialité du mot de passe, durant la phase d'authentification
  • Qu'une compromission de la BDD utilisateurs ne permette pas à un attaquant de s'identifier en tant qu'un utilisateur
Oui, et aussi à l'utilisateur de vérifier l'identité d'un serveur TLS sans passer par un tiers de confiance, en initialisant la session avec la clé générée (TLS en mode PSK, sans certificat).

On peut aussi faire l'identification en TLS afin de protéger le nom d'utilisateur, en mode TLS classique avec certificat.

Citation de: Electrocut le 26 octobre 2014 à 19:39:18
En revanche, il faut avouer qu'on monte tout de suite d'un cran en terme de complexité algorithmique, de complexité des échanges (nombreux allers retours clients <-> serveurs), et de complexité de mise en œuvre.
Oui, la sécurité est rarement gratuite : quand le coût n'est pas la difficulté pour l'utilisateur, c'est en complexité d'implèmentation.
Titre: Sécurité contre l'écoute lors de la connexion lafibre.info
Posté par: corrector le 27 octobre 2014 à 00:11:35
Parlons de risques de sécurité en pratique : type d'attaques et impact.

Les attaques peuvent porter sur le serveur ou le réseau; on met de coté les attaques sur le logiciel client, bien qu'en pratique les maliciels sur le poste client soient parmi les menaces les plus sérieuses (on pourrait gagner en robustesse au niveau de l'architecture de l'OS du client, mais c'est un autre sujet).

Il faut distinguer les attaques purement passives, par exemple une sonde sur un routeur, ou bien l'écoute sur n'importe quel nœud d'un média à diffusion (p.ex. Wifi ouvert), et les attaques actives qui impliquent de modifier les données. Les attaques actives ne sont pas spécialement difficiles à pratiquer, mais elles ne sont pas furtives.

Les piratages de serveurs stockant des fichiers d'utilisateurs sont très courants.

Le piratage d'une copie de sauvegarde d'un serveur ne compromet que la confidentialité, mais le piratage d'un serveur live permet de modifier le programme afin qui conserve des données qu'il devrait effacer. Cependant la plupart des attaques sont one-shot : récupération des données et non modification durable du fonctionnement du serveur. (L'attaque par injection SQL est un grand classique qui ne permet évidemment pas de reprogrammer le serveur.)

Bien sûr, la possibilité de certaines attaques est inhérente au fonctionnement d'un réseau ouvert comme Internet, alors que d'autres sont liées à l'incompétence des programmeurs (p.ex. fabriquer une requête SQL par concaténation de chaines de caractères de diverses origines).

On parlera de robustesse d'un système quand une erreur de programmation n'a pas de conséquences catastrophique.

Concernant les mdp :

Les utilisateurs sont des humains et pas des machines (sinon chacun génère un mdp avec 80 bits d'entropie sur chaque service et ne l'oublie jamais, et tout ce qui suit n'existe pas), donc :

- les mdp ne sont pas des suites de lettres purement aléatoires et n'ont pas une entropie idéale, donc il faut freiner le plus possible les attaques de type dictionnaire, pour protéger les utilisateurs qui ont un mdp qui n'est pas password ou 1234 (qui sera cassable de toute façon) mais qui n'est pas non plus l8z0gU7-I_J0qafgr6'=NBk7BD_0eg

- les mdp sont souvent soient réutilisés tels quels sur plusieurs services, soient réutilisés avec des variations mineurs; il faut éviter les attaques croisées trop faciles.
Titre: Sécurité contre l'écoute lors de la connexion lafibre.info
Posté par: corrector le 27 octobre 2014 à 00:30:04
L'objectif premier est donc selon moi de minimiser l'exposition du mdp (entré par l'utilisateur); ensuite, de protéger les secrets et autres jetons permettant à l'utilisateur de s'authentifier, qu'ils soient dérivés du mdp ou bien générés à chaque occasion, comme un témoin HTTP (HTTP cookie) de session (p.ex. "lafibreinfo" sur ce site).

En effet, le mdp donne une information sur l'utilisateur et son choix de mdp, et potentiellement à d'autres mdp, alors qu'un jeton ne donne accès qu'à un service.

Concernant un site Web, il est possible d'exécuter du code sur le client en JS, mais celui-ci sera fourni par le serveur à chaque connexion, donc la confiance dans le code dépend de la possibilité pour le client d'identifier et de faire confiance au serveur. (P.ex. sur lafibre il suffirait qu'un tiers de confiance soit compromis pour établir un faux certificat et pratiquer une attaquer MITM, et ajouter un script qui envoie le mdp en clair à un serveur.)

On pourrait imaginer une solution de type "client lourd" avec un plugin ou une app Google Chrome (qui n'a besoin d'aucun privilège) pour implèmenter une procédure coté client (avec possibilité de contrôler les MàJ auto et de les refuser).
Titre: Sécurité contre l'écoute lors de la connexion lafibre.info
Posté par: corrector le 27 octobre 2014 à 01:55:28
Quelques définitions :

u = nom d'utilisateur
p = le mdp
sid = ID de session
h = fonction de hachage cryptographique (généralement très rapide)
hp  = fonction de traitement cryptographique lente (relativement lente, sur une archi donnée : à une époque DES était considéré comme "lent")

Le vérificateur est une donnée qui permet de tester si un mdp est correct.

p.ex. h(p), hp(salt,p) ou h(h(u,p),sid) sont des vérificateurs

La connaissance d'un vérificateur est donc suffisante pour effectuer une attaque par dictionnaire. (Le serveur doit stocker au moins les vérificateurs et pourrait tenter une attaque par dictionnaire.)

Un vérificateur trivial est le p, ou p chiffré avec une méthode symétrique dont le serveur a la clef. Ceci est intrinsèquement moins sûr évidemment.

Un authentifiant est une donnée suffisante pour s'authentifier comme un utilisateur. (Le mdp est trivialement un authentifiant.)

p.e. sur Simple Forum : SHA1(u || ":" || p) est un authentifiant

Cet authentifiant peut être considéré comme le mdp réel du système; le mdp de l'utilisateur n'étant que le mdp apparent. Cependant, la révélation d'un authentifiant n'est pas aussi grave que celle du mdp car elle ne révèle pas quel genre de mdp l'utilisateur a choisi.
Titre: Sécurité contre l'écoute lors de la connexion lafibre.info
Posté par: corrector le 27 octobre 2014 à 02:18:17
Citation de: Electrocut le 25 octobre 2014 à 18:55:11
J'ai lu que la bonne pratique, pour le stockage d'informations d'authentification utilisateur sur un serveur, était de stocker en base de donnée, pour chaque utilisateur les éléments suivants :
  • login
  • hash = bcrypt (pepper || password || salt)
  • salt
salt étant choisi aléatoirement, différent pour chaque utilisateur
pepper étant codé en dur quelque part (idéalement, offusqué).
L'idée du poivre est de protéger au maximum l'accès au vérificateurs : seul le serveur qui a accès au poivre par un mécanisme hyper sécurisé peut faire les calculs de vérification des mdp. Ainsi même un pirate ayant accès à la table (SQL ou simple fichier texte) des utilisateurs ne peut rien en faire, il ne peut même pas tenter d'attaque par dictionnaire hors ligne.

Une modification simple de cette méthode est d'avoir deux couches de hachage : une couche intérieure qui protège le mdp entré par l'utilisateur et une couche extérieure qui dépend du poivre, p.ex.:

v = h2(pepper, h1(salt, p))
Titre: Sécurité contre l'écoute lors de la connexion lafibre.info
Posté par: corrector le 27 octobre 2014 à 02:35:57
Un nonce (nounce) est un nombre qui n'est généré qu'une seule fois, dans l'Histoire. C'est un grand nombre aléatoire tel que la probabilité de le générer plusieurs fois est négligeable.

On fait des calculs avec cette valeur; le résultat de calcul a forcèment été produit après que le nonce ait été émis, et est lié à ce nonce : le nonce agit comme un identifiant de session.

L'exemple typique est l'authentification HTTP Digest constituée de deux messages :

S->C : n
C->S : h(n, p)

Le nonce crée une courte session de 2 messages, mais avec l'authentification HTTP Digest la session s'arrête là et ne protège  ni la requête HTTP ni la réponse, puisqu'il n'y a aucune crypto en dehors des messages HTTP Digest. Un attaquant actif ne pourrait pas altérer ces deux échanges messages HTTP Digest mais il pourrait modifier tout le reste. Il faut donc que la session HTTP soit elle même protégée par TLS pour que l'authentification HTTP, la requête et la réponse soient reliés (TLS protège la session en utilisant un même jeu de clefs cryptographiques).

Dans les protocoles de mdp, le nonce est souvent appelé "challenge".
Titre: Sécurité contre l'écoute lors de la connexion lafibre.info
Posté par: corrector le 27 octobre 2014 à 02:59:28
Les caractéristiques souhaitables d'un protocole de vérification de mdp sont donc :

(clear-pw) aucun mdp ne circule en clair
(pass-ver) l'écoute passive ne révèle pas un vérificateur de mdp
(mitm-ver) une attaque réseau active (MITM) ne révèle pas un vérificateur de mdp
(stor-pw) le serveur ne stocke pas les mdp en clair (ou équivalent clair)
(prot-pw) le serveur n'obtient pas le mdp en clair lors de l'exécution du protocole
(stor-auth) le serveur ne stocke pas un authentifiant
(prot-auth) le serveur n'obtient pas un authentifiant lors de l'exécution du protocole
(slow-verif) l'exécution du vérificateur est lente
(sec-session) le protocole crée une session sécurisée
(no-dos) le serveur ne peut pas être forcé faire des calculs ridiculement lourds (pour éviter le DoS)

La lenteur du vérificateur est importante pour résister le plus possible aux attaques hors ligne par dictionnaires et force brute contre les mdp relativement courts.

La session sécurisée empêche une attaque active une fois que l'authentification a eu lieu : les requêtes sont liées à l'authentification par mdp, si elles sont modifiées elles ne seront plus considérées comme authentifiées.
Titre: Sécurité contre l'écoute lors de la connexion lafibre.info
Posté par: corrector le 27 octobre 2014 à 03:31:13
Parmi les protocoles utilisant un mdp, il y a notamment WPA (ou WPA2) en mode Personal (= PSK = clé pré-partagée).

On en a discuté récemment : https://lafibre.info/cryptographie/wifi-mode-de-securisation/

C'est un cas d'école de protocole où :
- chaque participant est authentifié, de façon symétrique;
- le mdp n'est jamais transmis;
- une session sécurisée est crée;
- protocole permettant l'attaque hors ligne par dictionnaire.

Un mdp peut être traité comme une clé pré-partagée, mais cela va généralement permettre ces attaques hors-ligne. Quand le mdp a une entropie faible, ce n'est pas un compromis souhaitable.
Titre: Sécurité contre l'écoute lors de la connexion lafibre.info
Posté par: corrector le 27 octobre 2014 à 03:45:17
Citation de: Electrocut le 26 octobre 2014 à 19:39:18
Merci pour ta réponseTout à fait.
Je note pour les conseils de mise en place ;)
Je note :)
Merci pour cette solution, qui permet à la fois :
  • De protéger la confidentialité du mot de passe, durant la phase d'authentification
  • Qu'une compromission de la BDD utilisateurs ne permette pas à un attaquant de s'identifier en tant qu'un utilisateur
En revanche, il faut avouer qu'on monte tout de suite d'un cran en terme de complexité algorithmique, de complexité des échanges (nombreux allers retours clients <-> serveurs), et de complexité de mise en œuvre.
En terme de subtilité, parce que la cryptographie est un domaine pas du tout évident plein de pièges, surtout la crypto asymétrique et le choix de nombres premiers.

En terme de temps de calculs aussi, parce qu'il y a des exponentielles avec de grands nombres à calculer dans des corps finis.

Ce qui signifie que le serveur doit faire des calculs importants pour toute demande d'authentification - enfin, pas plus importants que pour ouvrir une nouvelle session TLS. Mais quand même, il faut en tenir compte; c'est autre chose que de calculer un ou deux malheureux MD5 dans CHAP/APOP/DIGEST-MD5/CRAM-MD5/HTTP Digest.
Titre: Sécurité contre l'écoute lors de la connexion lafibre.info
Posté par: corrector le 27 octobre 2014 à 04:02:04
Citation de: corrector le 27 octobre 2014 à 02:59:28
Les caractéristiques souhaitables d'un protocole de vérification de mdp sont donc :
- l'écoute passive ne révèle pas un vérificateur de mdp
On voit facilement que cela n'est pas faisable avec de la crypto symétrique uniquement.

On a donc le choix entre des protocoles plus simples qui s'exécutent avec peu de mémoire mais qui exposent le mdp à une attaque par dictionnaire, ou des protocoles plus évolués qui nécessitent de stocker de grands nombres et de travailler dans des corps finis. Ce n'est pas un problème pour un PC (ou une box), mais ça peut être un problème pour certains systèmes "embarqués".
Titre: Sécurité contre l'écoute lors de la connexion lafibre.info
Posté par: corrector le 27 octobre 2014 à 04:18:06
Citation de: Electrocut le 25 octobre 2014 à 18:55:11
Procéder autrement (ex : que le serveur envoie pepper et salt au client, pour que celui-ci calcule bcrypt (pepper || password || salt))
Envoyer au client le poivre est hors de question. Admettons donc qu'il n'y a pas de poivre.

Envoyer au client le sel correspondant un utilisateur arbitraire crée plusieurs soucis :
Titre: Sécurité contre l'écoute lors de la connexion lafibre.info
Posté par: corrector le 27 octobre 2014 à 04:30:20
Citation de: corrector le 27 octobre 2014 à 02:35:57
Un nonce (nounce) est un nombre qui n'est généré qu'une seule fois, dans l'Histoire. C'est un grand nombre aléatoire tel que la probabilité de le générer plusieurs fois est négligeable.

On fait des calculs avec cette valeur; le résultat de calcul a forcèment été produit après que le nonce ait été émis, et est lié à ce nonce : le nonce agit comme un identifiant de session.
Je reviens sur les nonces : il faut impérativement qu'ils n'y ai jamais de répétition, et qu'ils soient imprévisibles; pour ça il faut un générateur de nombres pseudo aléatoire de qualité cryptographique.

Il s'agit d'une nécessité absolue. Si les valeurs ne sont pas réellement aléatoires, tout le système s'effondre. Je dis bien tout!
Titre: Sécurité contre l'écoute lors de la connexion lafibre.info
Posté par: Electrocut le 27 octobre 2014 à 10:02:38
Merci pour ces complèments d'information ;)

Citation de: corrector le 27 octobre 2014 à 02:59:28
Les caractéristiques souhaitables d'un protocole de vérification de mdp sont donc :
  • aucun mdp ne circule en clair
  • l'écoute passive ne révèle pas un vérificateur de mdp
  • une attaque réseau active (MITM) ne révèle pas un vérificateur de mdp
  • le serveur ne stocke pas les mdp en clair (ou équivalent clair)
  • le serveur n'obtient pas le mdp en clair lors de l'exécution du protocole
  • le serveur ne stocke pas un authentifiant
  • le serveur n'obtient pas un authentifiant lors de l'exécution du protocole
  • l'exécution du vérificateur est lente
  • le protocole crée une session sécurisée
  • le serveur ne peut pas être forcé faire des calculs ridiculement lourds (pour éviter le DoS)

Si j'ai bien compris le mécanisme d'authentification en place sur lafibre.info (et que celui-ci n'a pas changé depuis le premier post de ce topic) :
- celui-ci possède les caractéristiques 1, 2, 3, 4, 5, 9 et 10.
- en revanche, celui-ci ne possède pas les caractéristiques 6, 7 et 8.

Tu confirmes ?
Titre: Sécurité contre l'écoute lors de la connexion lafibre.info
Posté par: corrector le 27 octobre 2014 à 19:46:04
lafibre est en HTTPS, donc est-ce que tu parles du serveur HTTPS ou du serveur HTTP "derrière"?
Titre: Sécurité contre l'écoute lors de la connexion lafibre.info
Posté par: Optrolight le 27 octobre 2014 à 19:51:17
Citation de: corrector le 27 octobre 2014 à 19:46:04
lafibre est en HTTPS, donc je ne vois pas de quoi tu parles.

On dit "c'est pas faux" corrector  ;D
Titre: Sécurité contre l'écoute lors de la connexion lafibre.info
Posté par: corrector le 27 octobre 2014 à 20:09:08
Citation de: corrector le 27 octobre 2014 à 02:59:28
Les caractéristiques souhaitables d'un protocole de vérification de mdp sont donc :

(clear-pw) aucun mdp ne circule en clair
(pass-ver) l'écoute passive ne révèle pas un vérificateur de mdp
(mitm-ver) une attaque réseau active (MITM) ne révèle pas un vérificateur de mdp
(stor-pw) le serveur ne stocke pas les mdp en clair (ou équivalent clair)
(prot-pw) le serveur n'obtient pas le mdp en clair lors de l'exécution du protocole
(stor-auth) le serveur ne stocke pas un authentifiant
(prot-auth) le serveur n'obtient pas un authentifiant lors de l'exécution du protocole
(slow-verif) l'exécution du vérificateur est lente
(sec-session) le protocole crée une session sécurisée
(no-dos) le serveur ne peut pas être forcé faire des calculs ridiculement lourds (pour éviter le DoS)

La session sécurisée empêche une attaque active une fois que l'authentification a eu lieu : les requêtes sont liées à l'authentification par mdp, si elles sont modifiées elles ne seront plus considérées comme authentifiées.
Citation de: Electrocut le 27 octobre 2014 à 10:02:38
Si j'ai bien compris le mécanisme d'authentification en place sur lafibre.info (et que celui-ci n'a pas changé depuis le premier post de ce topic) :
- celui-ci possède les caractéristiques (clear-pw), (pass-ver), (mitm-ver), (stor-pw), (prot-pw), (sec-session) et (no-dos).
Si tu parles de ce mécanisme au dessus de HTTP, alors non, il ne fournit pas tout ça.
(clear-pw) oui
(pass-ver) non donc (mitm-ver) sans objet
(stor-pw) oui
(prot-pw) oui
(sec-session) non
(no-dos) oui

Citation de: Electrocut le 27 octobre 2014 à 10:02:38
- en revanche, celui-ci ne possède pas les caractéristiques (stor-auth), (prot-auth) et (slow-verif).
Exact.
Titre: DDoS sur un site Web
Posté par: corrector le 27 octobre 2014 à 20:29:12
https://lafibre.info est un serveur TLS qui propose RSA-ECDHE. Les clients légitimes vont faire une seule fois la phase RSA-ECDHE, et ensuite réutiliser le plus possible le secret obtenu.

Un client non légitime pourrait faire des authentifications en boucle, donc des opérations RSA.

Donc au niveau DDoS, tu peux faire faire au serveur des exponentiations en série.

Pour le reste, TLS crée une session sécurisée et authentifiée par certificat; pour attaquer lafibre.info, tu pourrais pirater une autorité afin d'obtenir un certificat "valide" et ensuite faire un MITM.

Et là, tu fais ce que tu veux.
Titre: Sécurité des mdp sur un site Web quelconque
Posté par: corrector le 27 octobre 2014 à 20:52:19
Citation de: Electrocut le 27 octobre 2014 à 10:02:38
Si j'ai bien compris le mécanisme d'authentification en place sur lafibre.info
Mais fondamentalement cette question n'a pas de sens, parce que le mécanisme dont tu espères qu'il n'a pas changé n'est qu'une page HTML.

Citation de: Electrocut le 27 octobre 2014 à 10:02:38
(et que celui-ci n'a pas changé depuis le premier post de ce topic) :
Voilà, tu espères que l'implèmentation n'a pas changé.

Donc le mécanisme affiche un formulaire HTML sur une page, donc rien n'indique à l'utilisateur comment ces données seront traitées. Tout ce que l'utilisateur sait est qu'il a une page Web d'un site donné, d'après l'URL. Il doit avoir confiance dans le serveur.

Tu ne saurais pas si le code avait changé, parce que tu n'as rien installé sur ton PC. Il faudrait faire un plugin!
Titre: Sécurité contre l'écoute lors de la connexion lafibre.info
Posté par: Electrocut le 27 octobre 2014 à 21:49:40
Citation de: corrector le 27 octobre 2014 à 20:09:08
(pass-ver) non donc (mitm-ver) sans objet
Je ne vois pas le "vérificateur de mot de passe" transiter en clair dans les échanges :

Citer
(sec-session) non
Je faisais allusion au fait que nous sommes en HTTPS, mais effectivement, ce n'est pas le mécanisme d'authentification qui assure la session sécurisée. Donc c'est non ... mais pas forcèment gênant ici.

Citation de: corrector le 27 octobre 2014 à 20:52:19
Donc le mécanisme affiche un formulaire HTML sur une page, donc rien n'indique à l'utilisateur comment ces données seront traitées.
Non, mais nous venons de voir plus haut, que si le mécanisme côté client est ce qu'il est (le client reçoit  "sid" et retourne "hash = SHA-1(SHA-1(lower (login) || password) || sid)", alors c'est que "SHA-1(lower (login) || password" est stocké côté serveur. D'où mes remarques sur les propriétés (stor-auth) et (prot-auth) à priori non couvertes.
Titre: Sécurité contre l'écoute lors de la connexion lafibre.info
Posté par: corrector le 27 octobre 2014 à 22:22:11
Citation de: corrector le 27 octobre 2014 à 01:55:28
Le vérificateur est une donnée qui permet de tester si un mdp est correct.
J'aurais dû écrire un vérificateur est une fonction de l'ensemble de mdp autorisés vers les booléens indiquant si un pp (password potentiel) est correct.

Citation de: Electrocut le 27 octobre 2014 à 21:49:40
Je ne vois pas le "vérificateur de mot de passe" transiter en clair dans les échanges :
  • Le serveur envoie "sid" aléatoire
  • Le client retourne hash = SHA-1(SHA-1(lower (login) || password) || sid)
  • Le serveur récalcule hash = SHA-1(hpw || sid), et compare le résultat
En capturant la connexion on peut récupérer :
- login
- sid
- hash = SHA-1(SHA-1(lower (login) || password) || sid)

hash seul n'est pas un vérificateur. Le triplet (login, sid, hash) définit un vérificateur.

Citation de: corrector le 27 octobre 2014 à 01:55:28
La connaissance d'un vérificateur est donc suffisante pour effectuer une attaque par dictionnaire. (Le serveur doit stocker au moins les vérificateurs et pourrait tenter une attaque par dictionnaire.)
En connaissant login et sid, je peux calculer SHA-1(SHA-1(lower (login) || pp) || sid) pour tout pp (password potentiel).

Le vérificateur en fait est la fonction

pp -> ( SHA-1(SHA-1(lower (login) || pp) || sid) == hash )

Ce qui permet de faire une attaque de type dictionnaire ou force brute.
Titre: Sécurité contre l'écoute lors de la connexion lafibre.info
Posté par: Electrocut le 27 octobre 2014 à 22:33:32
Effectivement. Je cherchais un seul élèment vérificateur, mais c'est le trio login + sid + hash qui le compose. Merci pour cet éclaircissement ;)