Premièrement, restons respectueux l’un envers l’autre s’il te plait. Nous avons des avis contradictoires, cela ne nous autorise pas à mépriser l’autre. On peut en discuter tranquillement sans avoir besoin de rabaisser notre interlocuteur.
Désolé si j’ai paru te rabaisser. 
Ce n’était aucunement mon propos, je voulais surtout insister sur le fait que ta position diverge beaucoup de ce qui est considéré actuellement comme les "bonnes pratiques de sécurité", et donc du besoin d’étayer plus sérieusement tes propos.
Nous ne partons pas du tout du même but.
Moi je cherche à tout prix à protéger le secret utilisateur (pour rappel, son mot de passe, qui a un sens, une entropie, une topologie, …). Toi tu cherches à sécuriser en priorité les comptes utilisateurs d’une fuite de hash.
Non, je dois chercher en fait à garantir à mes utilisateurs le meilleur niveau de sécurité possible sur mon service. Et cela passe par l’étude du risque, notamment en prenant compte de la probabilité de chaque type d’attaque, son ampleur potentielle et sa gravité.
Bref, partons du principe que l’on doit protéger le compte utilisateur en priorité. Effectivement, dans le cas où seul les hash stockés coté serveur sont compromis (ce qui dans la pratique ne m’est jamais encore arrivé mais dans des CTFs c’est assez courant). Alors ce que j’ai proposé, même à base de hash + nonce ne suffit pas. Mais il faut que la fuite soit silencieuse sinon il suffit de réagir en réinitialisant les mots de passes par exemple.
Si tu demandes aux utilisateurs de réinitialiser, pas tous le feront. Si tu le fais toi même, ou que tu l’impose en bloquant temporairement les comptes, tu agresses en un sens tes utilisateurs et tu vas sans doute causer d’autres problèmes comme la perte de certains comptes.
L’accès aux données internes d’une boite est classique, et malgré sa gravité, si l’accès aux comptes des utilisateurs est préservé, c’est déjà un moindre mal.
1) Nous ne sommes pas d’accord. Pour pas mal de raisons. La première, c’est qu’il n’est pas possible de demander à l’utilisateur d’utiliser un mot de passe fort. La large majorité des mot de passes sont faibles voire très faibles. Si la sécurité des comptes est ta priorité, tu te dois de prendre en compte cela.
Il est recommandé d’imposer un mot de passe fort aux utilisateurs. Et même si ce n’est pas possible, certaines techniques permettent de minimiser cette faiblesse (blocage des bruteforce en ligne, salage, etc.).
Ensuite dans la même idée, on ne peut pas demander à un utilisateur de retenir une pléthore de mot de passe. Il y a de forte chance que le secret soit partiellement réutilisé dans un autre mot de passe ; que ce soit la topologie du mot de passe, son sens, sa méthode de construction, voir carrément le mot de passe en lui même.
Oui, et c’est un vrai problème en effet. Mais du moins tu n’es pas responsable.
Enfin, ce que je propose est la protection du secret. Ça va plus loins que le simple fait de protéger contre l’utilisation du mot de passe sur un autre site. C’est protégé l’ensemble du sens associé au mot de passe. Si ton mot de passe est "pikachu44". Il a un sens, tu aimes pokémon et tu as un liens avec la région pays de la Loire. "Ilovecatsoulet33" ou "<3christ<3" sont révélateurs de donnés personnelles très importantes (le premier est certainement un adorateur de Saroupille de la région centre et le second un fervant croyant). Tu comprends pourquoi je m’obstine à vouloir protéger le secret de l’utilisateur ?
Non, pas trop. Le fait que le mdp soit une donnée personnelle ne justifie pas de le protéger plus que les autres données (qui elles vont au mieux transiter pas HTTPS).
3) En fait, ça s’appelle un nonce (ce que tu appeles salage dynamique). Et non, justement, jamais le secret(mot de passe) ne quitte le client. C’est justement l’intéret du truc.
Il me semble que l’intérêt d’un nonce, c’est surtout d’éviter une attaque par rejeu des informations transmises. Ce qui n’implique pas forcément que le secret soit divulgué. (mais bon, il me semble que HTTPS protège également contre des attaques de ce type, avec un nonce aléatoire justement.)
Au niveau de l’utilisation de HTTPS. On sait que ce n’est pas infaillible. Bon après tout dépends du niveau de menace que tu veux prévenir. Un état roule tranquillement sur HTTPS (@nohar, si j’ai de bon souvenir, t’as pas des choses à nous dire ? :D). Ton voisin aura un peu plus de difficulté.
Déjà, il faut préciser qu’écouter sur le réseau d’un utilisateur donné n’est pas simple (sauf si tu es le FAI), ce qui minimise pas mal l’ampleur potentielle d’une attaque par interception de mdp.
Mais le principal problème de HTTPS, c’est que ça ne protège en rien le secret utilisateur.
Je ne comprend pas cette phrase: le secret est quand même relativement bien protégé, même en admettant qu’un état puisse outrepasser cette sécurité.
4) Dans la pratique, j’ai souvent connu des serveurs compromis. Ce qui signifie fuite des données clients au minimum (et pas seulement fuite de la colonne "hash" de la BDD) et souvent pire, compromission serveur. Shell sur le serveur ou droit admin. Mais ce n’est que mon point de vue.
Fuite des données (souvent partielles) du client, oui malheureusement. Mais l’accès au compte est généralement bien plus grave. Par exemple, si mes données bancaires fuitent, je suis moins ennuyé que si l’attaquant a eu accès à mon compte en banque. Et dans d’autres cas moins sensibles (pas ou peu d’actions possibles), l’attaquant a généralement moins de données accessibles déjà partir d’une fuite qu’avec un accès complet au compte.
Je prenais DES pour exemple comme j’ai également pris pour exemple le masque jetable. J’ai essayé de prendre deux extrêmes afin d’avoir un argument simple à comprendre. Pour rappel, je disais que le temps mis pas un algo n’est pas propotionel à sa sécurité, et j’ai pris pour exemple deux algos qui allaient dans ce sens. J’ai pris des exemples simples car je ne connais pas la vitesse moyenne des algo de hashage cryptographiquement sûr.
Certains algos de hachage (comme Bcrypt) ont été conçus spécifiquement pour être lents (de façon "réglable"), afin justement de pallier à la puissance de calcul toujours plus importante à disposition des attaquants. Parce que si une base de hash fuit, il y a un risque que l’attaquant retrouve les mdp de tous les comptes (et si les utilisateurs sont peu méticuleux comme c’est le plus souvent le cas, il pourrait même accéder à leurs comptes ailleurs).
5) Alors là par-contre. Non. Le hash d’un mot de passe à autant d’entropie que sa taille. Le mot de passe à autant d’entropie que le mot de passe. Souvent moins que la taille d’un hash. Un hash à la propriété : "Si un bit un entrée change alors chaque bit de sortie à une chance sur deux d’être changé également" ce qui garantie une entropie maximale. L’entropie du hash sachant qu’il est issue de ce mot de passe est effectivement identique à celle du mot de passe. Encore faut-il connaitre le mot de passe à la base.
Non. Si tu sais que tes hash proviennent de mdp usuels, l’espace des hash possibles est considérablement réduit. Par exemple, si tu sais que tous tes hash proviennent de mdp de 7 caractères ascii, le fait que ton hash fasse 128 bits ne sera d’aucun secours, il n’y aura toujours que $26^7$ possibilités…
Alors, oui l’authentification utilisateur, c’est pas simple. Si on veut un truc vraiment bien, c’est long et compliqué. Il n’existe pas qu’une seule solution. Mais il faut se fixer les buts à respecter au début sinon on ne parle pas de la même chose.
Je suis bien d’accord. Mais ton message sur ce fil critique une société qui transmet le mdp en clair par HTTPS à leur serveur, alors que cela respecte parfaitement les objectifs standards de sécurité.
