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.

Merci pour ta réponse

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

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

Je note

SRP Protocol Design.
...

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.

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?

Et la réponse qui lui a été proposée est ... Secure Remote Password protocol (SRP Protocol)
Voilà qui est rassurant, ça converge avec ta suggestion

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.

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.

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".

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.