Quand Numpy vous sauve la vie

Moi non plus :s

Du coup, ben ça marche bien en POST mais ça envoye quand même le mdp et pas un hash. Mais comme c’est de l’HTTPS … Ça reste pas génial surtout pour le comportement différent en fonction de l’User-Agent.

M’enfin bref, ça mérite pas un email quoi.

Merci en tout cas ! Sans toi j’aurais pas remarqué le comportement

C’est normal que ça envoie le mot de passe et non le hash, c’est ce que font tous les sites. C’est comme ça ici aussi.

Si tu calcules le hash côté client, alors le mot de passe n’existe plus : le mot de passe est le hash. En effet, il suffit de connaître le hash (et plus le mot de passe initial) pour faire une requête de connexion sur le site.

L’intérêt, c’est d’envoyer le mot de passe au site, que celui-ci en calcule le hash (avec salage et tout le tralala) et qu’il le compare avec celui stocké en base. Ce n’est pas parce que ton mot de passe est envoyé au site qu’il est ensuite stocké en clair.

Pas d’accord.

Dans tous les cas, le mot de passe est le hash. Avec salage mais ça reste le hash au final.
Mieux vaut que ce soit le hash qui circule que le mot de passe. Le mot de passe est réservé à l’utilisateur. Le hash, c’est pour le site.

Si c’est le mdp qui circule. T’as toutes les infos, tu te fiches du hash. Si c’est le hash qui circule (plus sel). Alors tu n’as simplement rien. Rien de rien. Nada. Tu peux faire une requète sur le site mais c’est rien de plus. Tu n’as pas le secret, juste une info sur celui-ci.

Pas moyen de l’utiliser sur un autre site, pas moyen de déceler un patern ou une information importante. Le secret de l’utilisateur est sain. Son compte un peu moins, mais c’est mieux que si le secret avait été découvert.

Après, là on est sur du HTTPS. J’ai pas lu les specs mais à priori c’est presque sûr. N’empèche qu’on ne devrait pas avoir à faire confiance au site web.

Le mot de passe, c’est la donnée envoyée au serveur pour autoriser la connexion pour un utilisateur. Si seul un hash est communiqué, il suffit de connaître le hash pour se connecter. De plus, le hash serait stocké en clair dans la base de données, donc si cette table fuite, tous les comptes sont corrompus.

Le problème que tu pointes, c’est celui d’utiliser un même mot de passe sur plusieurs sites, mais ça c’est le problème de l’utilisateur. Si tu préfères que ton mot de passe ait la forme d’un hash, libre à toi, mais c’est à toi de choisir ton mot de passe, pas au site.

?

Envoyé le mot de passe en claire au site web ne change rien. Il ne fait pas la comparaison sur le mot de passe. Il fait la comparaison sur le hash. Du coup, c’est le hash le vrai mot de passe.

Je ne comprend pas quand tu dis :

Si seul un hash est communiqué, il suffit de connaître le hash

Oui, c’est exactement ça. Et si la base fuite, c’est que de base, le serveur est compromis. Donc il n’y a déjà plus rien à perdre.

On s’éloigne un peu du sujet et j’avoue ne pas avoir tout lu. Je terminerai donc juste sur ça :

Ce dont je me rappelle, c’est que pour palier le problème d’absence de HTTPS du temps où certains sites étaient contraints à HTTP et qu’il fallait s’authentifier par mot de passe, ils utilisaient une fonction javascript pour hasher le mot de passe avant envoi sur le réseau.

Non, car si tu envoies le hash au site, il te refusera la connexion. Car côté serveur, il hashera ce que tu as envoyé pour comparer avec ce qui est en base. C’est le mot de passe qui est attendu, et le mot de passe qui sert à t’authentifier.

Dans le cas où ta connexion n’est pas sécurisée et que quelqu’un écoute ce qu’il se passe (car c’est de ça dont il est question), il verra de toute manière passer tes identifiants, quelle que soit la forme choisie pour le mot de passe.

@Ache:

Comme l’a dit entwanne, si tu envoies au site le hash et que ce dernier stocke en BDD le hash, alors ce dernier devient le mdp. Si la BDD fuite, il suffit alors de connaître le hash pour se connecter.

Si c’est le site qui calcule le hash à partir du mdp et qu’il stock le hash, alors c’est un peu plus safe car il faut connaître une pré-image du hash. Sinon, tu ne pourras pas te connecter car le site va hasher le hash et la comparaison va échouer.

La propriété cryptographique ici est que trouver une pré-image d’une bonne fonction de hash est un problème très difficile. Dans le premier cas, tu pourrais utiliser n’importe quelle fonction, ça ne changerait strictement rien en fait. Que ton hash soit la fonction $x \to x + 1$ voir même la fonction identité, tu auras la même sécurité.

Dans le second cas, pour avoir une bonne sécurité, il faut qu’étant donné $f$ et $y$, trouvé $x$ tel que $f(x)=y$ soit très difficile ce qui n’est pas le cas des deux fonctions précédentes.

De plus, point de vue sécurité, il vaut mieux que ça soit le serveur qui fasse le travail de hash (sans parler du salage, etc.).

En cas d’attaque bruteforce, si le hash se fait côté client, des milliers de petits robots peuvent hasher et envoyer des mots de passes pour tester. Une simple comparaison en base, c’est "rapide".

Si c’est le serveur qui fait le boulot de hash, c’est plus "lent", et on a plus le temps de détecter une attaque. (Et ça rends moins efficace une attaque avec des milliers de robots).

Et surtout, un hash côté client, ça demande du JS. Et le JS ne devrait pas servir à ce genre de fonctionnalités essentielles. Un site doit être utilisable sans JS.

Après, vu que CodinGame n’est rien sans JS, ils sont pas à ça prêt. Mais bon, c’est pas une raison pour faire n’importe quoi.

Ce que je comprend pas, c’est la logique selon laquel il est plus simple d’obtenir un hash d’un mot de passe qu’un mot de passe en lui même.

@Morlaer, je te rejoins totalement sur ce point. Cependant si on veut quelque chose de sécuriser, il faut bien que le client agisse. On peut imaginé deux niveau de sécurité avec JS et sans JS.

@JuDePom: Non désolé, ça n’augmente pas la sécurité ce que tu décris. Ça augmente seulement la charge CPU du serveur. Cryptographiquement parlant, ce n’est pas plus sûr. Dans la pratique, ça à peut-être une influence cependant, mais peu importe puisque dans la pratique on limite le nombre de tentatives de connection depuis une même IP.

Le problème que je pose n’est pas la sécurité du site mais la protection du secret. Si la base de hash du site fuit, il y a un tout autre problème que simplement celui de la sécurité des mots de passe. Là on parle de compromission serveur. C’est bien pire … Et même dans ce cas là, le secret n’est pas divugué alors que si on envoye le mot de passe, il peut très bien l’être (placé un espion sur un serveur pour écouter les communications, ça peut se faire quand le serveur est compromis).

Non pas vraiment. Tu peux hasher le hash + un token avant de l’envoyer. Comme ça le hash ne circule jamais et n’est pas réutilisable. Mais c’est un autre problème.

Si ! Ça change beaucoup de chose. Avec une bonne fonction de hashage, tu ne peux pas retrouver le secret à partir de l’écoute de la comunication. Alors que si tu transmets le mot de passe, le secret est révélé.

En espérant avoir pu faire passer mon point de vue :s

Ce n’est pas plus difficile que d’obtenir un mot de passe fort, en tout cas.

Si, justement, c’est aussi pour ça que les hash de mots de passe ont leurs algo spécifiques, et qu’on ne fait pas un simple hash md5 ou sha1. L’intérêt c’est d’avoir un algorithme complexe, qui nécessite un certain coût pour s’exécuter, afin d’éviter de tester trop rapidement différentes possibilités ou d’établir des rainbow tables.

Mais si le hash se fait côté client, ton secret est lui aussi découvert si ta communication est écoutée et non sécurisée.

Donc tu génères un token côté serveur lors d’un accès au formulaire de connexion, tu utilises ce token pour calculer un hash’ du hash que tu gardes en mémoire jusqu’à la réponse, communique le token au client et attend que celui-ci te réponde hash’ ?

Ça n’est pas plus simple d’utiliser une connexion sécurisée ?

@entwanne : Le token est utile en cas de connexion non sécurisée effectivement. C’est malheureusement encore d’actualité sur certains sites. Et parfois, quand je vois les mails du boulot de certains experts en sécurité, ce n’est pas forcément une si mauvaise idée même pour des connexions dites "sécurisées".

Mais ce genre de sécurité avec un token, ça doit être mis en place par le serveur. Si celui-ci ne prend pas la peine de passer à HTTPS, pourquoi implémenterait-il un tel système de tokens ?

Haha, ouais. C’est sûr que l’https est le minimum syndical, je n’ai rien dit contre

Ce que je comprend pas, c’est la logique selon laquel il est plus simple d’obtenir un hash d’un mot de passe qu’un mot de passe en lui même.

Ce n’est pas plus difficile que d’obtenir un mot de passe fort, en tout cas.

J’irais même jusqu’à dire le contraire justement. Hash MD5 128 bit, soit 16caractères (comprendre octets), SHA-1 20 caractères. Et encore ce sont des méthodes de hashages dépassées. Sur du SHA-2 on va jusqu’à 64 caractères. C’est bien plus difficile à brut force qu’un simple mot de passe.

@JuDePom: Non désolé, ça n’augmente pas la sécurité ce que tu décris. Ça augmente seulement la charge CPU du serveur. Cryptographiquement parlant, ce n’est pas plus sûr.

Si, justement, c’est aussi pour ça que les hash de mots de passe ont leurs algo spécifiques, et qu’on ne fait pas un simple hash md5 ou sha1. L’intérêt c’est d’avoir un algorithme complexe, qui nécessite un certain coût pour s’exécuter, afin d’éviter de tester trop rapidement différentes possibilités ou d’établir des rainbow tables.

Oui tout à fait, c’est l’algo qui fait la sécurité. Mais ce n’est pas la lenteur de l’algo qui fait qu’il est sécurisé (par exemple, le DES est bien plus lent que l’AES. Ou plus simplement, le masque jetable est le plus rapide des chiffrements). C’est sa résistance aux attaques. En ralentissant,on n’augmente pas la sécurité du schémas.

Oui, c’est un peu lourd effectivement, c’est pour ça que je disais que c’était un autre problème. Certains préfèrent utiliser le timestamp mais ; Bien que plus léger, j’aime pas trop. Trop simple à désynchroniser.

À non mais quand on parle d’authentification, l’HTTPS est obligatoire. Ne serrait-ce que pour l’authentification serveur. Mais on sait que l’HTTPS n’est pas non plus infaillible malheureusement.

Dans ta situation, quel est le secret ? Est-ce vraiment le mot de passe ? Si quelqu’un écoute la communication, il va voir, que le client a envoyé le couple $(id, c)$ au serveur avec en pratique $c=hash(mdp)$. Avec le protocole que tu proposes, si je suis un vilain méchant, et que j’écoute la ligne, je vais observé le couple $(id,c)$ et donc je connaîtrais pas $mdp$ car calculer une pré-image de la fonction de $hash$ c’est compliqué.

Par contre, connaissant le couple $(id,c)$ maintenant, je peux me faire passer pour le client $id$ et envoyer au serveur le couple $(id,c)$ pour me connecter. Comme le serveur stocke $c$ en BDD, alors le serveur y verra que du feu. Autrement dit, le secret n’est plus $mdp$, c’est $hash(mdp)$. Savoir que $c$ a été généré depuis une fonction de hashage (ou pas) ne change rien au problème. Connaître $c$ te permet de te connecter au serveur.

Le secret reste le mot de passe je pense.

Eve peut rejouer le scénario, de l’échange et donc se connecter. Un peu comme si Alice signait un chèque de 50€ et l’envoyait à Bob. Eve intercepte le chèque. Elle est capable de le déposé à la banque. Mais elle n’est pas capable d’utiliser le secret de Alice pour signer un autre chèque. La situation est différente mais dans les deux cas, Alice possède une information que Eve n’a pas, le secret.

Après oui, on peut dire qu’au final le secret est le hash car il permet de se connecter, mais c’est une simplification qui ne retranscrit pas la situation réelle. Dans un autre système, avec 3 personnes (Carole proposant un autre service que Bob) par exemple, ou avec un négociation de la fonction de hashage (situation d’exemple, l’intérêt, bien que non nul est quand même limité), on se rend mieux compte de l’importance de la pré-image.

@ache: Je ne vois pas bien pourquoi tu t’obstines à défendre un point de vue inepte AMHA… Ce que tout le monde te dit ici est notoirement connu, pour peu que l’on s’intéresse à la question (voir ici ou la). Qualifier d’incompétence le respect les pratiques standard est curieux, il me semble que c’est plutôt à toi d’étayer ton point de vue qui diverge des recommandations courantes.

Plusieurs points essentiels :

1. Le fait d’employer le même secret dans de multiples contextes (Bob et Carole) est une erreur de la part de l’utilisateur (et d’ailleurs, des stratégies courantes comme le salage des mdp minimisent justement le problème).
2. Ce que l’on cherche donc à empêcher, c’est l’usage de ton mdp sur le serveur considéré. Parce qu’une fois qu’un attaquant a ton mdp, il peut tout faire avec ton compte sur le serveur en question (signer autant de chèques qu’il veut dans ton analogie). C’est pour cela qu’utiliser le hash comme mdp est mauvais, car cela revient à stocker le mdp en clair, ce qui est une très (très) mauvaise pratique comme chacun sait.
3. Ta méthode consistant à faire hash(hash(mdp)+token) correspond en fait à un salage dynamique coté client, aucun intérêt donc en dehors d’un cas d’interception. Or, afin d’éviter que le véritable secret ne soit intercepté, on utilise justement une méthode de transmission sécurisée (HTTPS par ex.), ce risque est donc quasi nul. En revanche, tu dois toujours stocker le secret coté serveur, ce qui est autrement plus problématique (en cas de fuite notamment).
4. Si les hash stockés par le serveur fuitent, ça ne veut absolument pas dire que le serveur soit irrémédiablement et totalement compromis (ce qui est effectivement un souci bcp plus grave, mais heureusement bcp plus rare aussi). D’où le fait que la puissance de calcul nécessaire à la génération d’un hash (rien à voir avec DES) est importante, car cela empêche l’attaquant de calculer efficacement les pré-images (et donc d’accéder aux secrets de tout le monde par bruteforce) dans ce genre de cas.
5. Le hash d’un mdp n’est pas plus "fort" que ce dernier, quelle que soit sa longueur: l’entropie reste la même.

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.

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.

Pour réunir les deux conditions, nous pouvons utilisé une authentification par HMAC. Mais c’est encore plus complexe que ce que la simple utilisation d’un nonce.

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.

Je vais reprendre point par point tes arguments.

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

   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 ?

2. Ah et du coup. Nan, on a pas les même objectifs. Mais ce que tu dis ce tiens tout à fait. Si on suit ton unique objectif qui est de protéger les comptes de ta base de donné. Effectivement, on peut faire mieux que simplement ce que j’ai proposé car dans le cas d’une fuite de la base de hash (sans signe alertant, et je précise que c’est vraiment ce seul cas qui pose problème) alors effectivement on a un problème à stocker les hash des mots de passe, puisque le hash est devenue le mot de passe en quelque sorte.

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.

   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é. Mais le principal problème de HTTPS, c’est que ça ne protège en rien le secret utilisateur.

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.

   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.

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.

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 m’excuse pour les nombreuses fautes de ce message, il est tard je vais me reposer. Bonne soirée.

Edit: Dans tous les cas, je pense qu’on s’est vraiment égaré du sujet initiale. On peut continuer ici par commodité si ça ne dérange pas trop informaticienzero. Mais dans l’idée on devrait continuer ça sur un sujet à part. Je créerai le sujet moi même si jamais le besoin se fait sentir.

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