Discussion :

[eracius]

Bonjour,

Nous avons mis en place une politique de mot de passe strict sur une application pour éviter les mots de passe "toto" "coucou" dans le cadre d'accès à des données assez sensibles. Mes clients se plaignent que les mots de passe sont pénibles à retenir et me demandent pourquoi ne pas utiliser des formulaires de saisies "type website bancaire" avec la petite popup faisant apparaître un clavier.

Effectivement, la plupart des banques utilisent ce genre de chose et ne demandent que des mots de passe assez simples entre 4 et 8 chiffres. Par ailleurs, on ne voit ce type d'authentification que sur les sites bancaires et pas autre part. Est-ce qu'il y a une raison ? Outre le fait que ça empêche l'enregistrement du mot de passe ? Peut être aussi l'impossibilité d'"écouter" la saisie clavier ?

Existe-t-il des lib qui gèrent directement ce type de saisie ? (J'ai regardé la sogé par exemple, ça semble être du js/html maison)

Pour ouvrir un peu, quelles sont les bonnes pratiques ou les pièges à éviter pour un bon formulaire de saisie de mot de passe ? Nous avons aussi pensé à de l'OTP mais c'est également une contrainte de plus pour l'utilisateur, à contre balancer avec le gain réel ou non en sécurité.

Merci d'avance pour vos avis et éclaircissements.

[Neckara]

Bonjour,

Par ailleurs, on ne voit ce type d'authentification que sur les sites bancaires et pas autre part. Est-ce qu'il y a une raison ?

Oui, parce qu'en 10 minutes on peut retrouver ton mot de passe par brute force.

Les banques ne doivent stoker ni le mot de passe, ni son hash, mais le recalculer/vérifier à partir d'informations personnels du porteur (?). Pour cela ils utilisent un matériel très spécifique (HSM), qu'il t'es presque impossible d'acquérir si tu n'es pas une banque. Donc je pense que tu peux oublier.

Je pense d'ailleurs que la vraie sécurité, c'est plus l'identifiant utilisateur que le mot de passe en lui-même.

Peut être aussi l'impossibilité d'"écouter" la saisie clavier ?

Mouais. Mais ce n'est pas très réaliste si tu as un vrai mot de passe fort et on peut voir assez facilement ton mot de passe en regardant par-dessus ton épaule.

Outre le fait que ça empêche l'enregistrement du mot de passe ?

Tu sais avec un peu d'imagination et un ordi client corrompu, on peut arriver à tout.


C'est tout de même dingue de voir des utilisateurs se plaindre de la sécurité, "ah j'ai la flemme de chercher mes clefs quand je rentre chez moi parce que ma porte a une serrure."
Qu'ils utilisent un logiciel comme KeePass ou qu'ils attendent que je finisse mon papier.

[ABCIWEB]

Salut,

Il n'y a pas de standard universel pour les authentifications puisque suivant les cas on privilégie la sécurité ou la convivialité, des deux étant difficilement compatibles.

Pour un maximum de sécurité on utilise les popup de saisie virtuels qui sont faits pour se protéger des logiciels espions de type keyloggers au cas où l'ordinateur client serait infesté.

En descendant le niveau de sécurité d'un cran on part sur le principe que l'ordinateur distant est sain, ce qui évite le clavier virtuel.

Pour simplement interdire au navigateur l'option de pouvoir enregistrer les mots de passe il suffit que le formulaire ne comporte pas de bouton de type submit. Mais bon, il faut voir si le niveau de sécurité le justifie, c'est handicapant de devoir re saisir les mots de passe.

Comme déjà dit par Neckara si le nombre de caractères des mots de passe de type bancaire est relativement faible, c'est qu'il complète d'autres données assez confidentielles comme un numéro de compte ou un numéro de client. Tu pourrais faire l'équivalent en créant des comptes clients si besoin.

En tous cas, la longueur du mot de passe n'a pas un rapport direct avec l'existence d'un popup de saisie virtuel aussi je comprends pas trop les remarques de tes clients.

En complément du type de saisie / authentification, il y aussi la transmission du mot de passe qui rentre en jeu pour la sécurité du système. Là c'est plus simple puisque le maximum de sécurité ne se traduit pas par des inconvénients pratiques pour l'utilisateur et on privilégie évidemment les connexions cryptées de type ssl. Sans une connexion cryptée on peut au mieux protéger les mots de passe en les hachant côté client avec un sel mais l'efficacité de la protection est proportionnelle à la longueur du mot de passe. Une connexion de type ssl est donc nécessaire pour se protéger d'un piratage réseau si l'on souhaite utiliser des mots de passe relativement courts.

[Neckara]

Pour simplement interdire au navigateur l'option de pouvoir enregistrer les mots de passe il suffit que le formulaire ne comporte pas de bouton de type submit.

Ou sinon, il faut que la zone de texte type=password, ai l'attribut autocomplete=off (HTML5).

[eracius]

Merci pour vos explications et vos points de vue.

@Neckara

Oui, parce qu'en 10 minutes on peut retrouver ton mot de passe par brute force.

Même avec 8 caractères minimum, majuscule, minuscule, caractères spéciaux etc etc ? Tu as une préconisation de format de mot de passe à partir duquel le brute force devient compliqué ?

Je pense d'ailleurs que la vraie sécurité, c'est plus l'identifiant utilisateur que le mot de passe en lui-même.

Donc éviter un email ou un truc trouvable mais partir sur un couple de clefs ? Deux mots de passe finalement ?

[Neckara]

Même avec 8 caractères minimum, majuscule, minuscule, caractères spéciaux etc etc ?

On recommande maintenant 10 caractères minimums et entre 12 et 16 caractères.

Donc éviter un email ou un truc trouvable mais partir sur un couple de clefs ? Deux mots de passe finalement ?

Disons que dans le cas des banques, tu n'as que 10 000 possibilités.
Sauf que si tu en testes 3 faux sur un même compte, ce dernier risque d'être bloqué.

Mais on peut en tester 1 à 3 sur un compte puis recommencer sur un autre compte.
Donc en connaissant 10 000 identifiants à 3 333, on a de fortes chances d'arriver à trouver le code d'un compte.

L'identifiant est un nombre imbuvable alors qu'il pourrait simplement être prenom.nom pour être retenu plus facilement. Je suppose donc que dans ce cas là, l'identifiant est utilisé un peu comme un "second mot de passe".

Mais dans le cas général, c'est un peu ridicule, il vaut mieux 1 mots de passe de 10 caractères que 2 mots de passes de 5.

[tdutrion]

Je suis étonné que personne n'ai parlé de Two Factor Authentication... Tu peux utiliser Google Authenticator ou autre, voir des Yubikey pour authentifier tes utilisateurs avec un code unique basé sur l'heure.

[Neckara]

Attends, là tu mélanges :

• des authentifications fortes (plusieurs facteurs) ;
• des authentifications "uniques" ;
• et des mots de passes uniques (OTP) basés sur une solution matérielle ;

Alors, déjà que les utilisateurs sont retissant à un simple mot de passe, on va éviter les authentifications fortes qui sont perçu comme encore plus "difficiles"/"coûteuses" par les utilisateurs. Il y a des travaux de recherches pour améliorer cela, notamment par le biais de facteurs implicites, mais ce n'est pas encore disponible sur le marché à ma connaissance.

Pour les solutions matérielles, pas sûr que les clients aient envie d'engager des frais.


Pour les authentifications "uniques", je pense que cela va s'opposer à la volonté de fixer et garantir une sécurité minimale au utilisateurs. En effet, là plus rien n'empêchera un mot de passe du type "123456".
De plus, il faut aussi faire confiance à l'entité qui va permettre d'authentifier le client.

[eracius]

J'avais mentionné l'OTP dans mon premier message mais effectivement, les utilisateurs étant déjà réticents à des mdp complexes, je les vois mal récupérer un mot de passe à usage unique via SMS ou autre... Néanmoins, on y a réfléchi pour des cas spéciaux, par exemple un utilisateur qui change de pays subitement ou même d'IP.

Encore merci pour vos réactions, ça nourrit ma réflexion.

[ABCIWEB]

Tu as une préconisation de format de mot de passe à partir duquel le brute force devient compliqué ?

Cela dépend aussi de comment peut être intercepté le hash. S'il peut être intercepté en piratant le réseau (donc quand on utilise pas de connexion de type ssl), étant donné que les algo de hash compatibles côté client et serveur se limitent la plupart du temps à du sha512 et que ce n'est pas un algo gourmand en ressource, il vaut mieux un mot de passe très long.

Si par contre on utilise une connexion ssl, en dehors des cas de piratage des certificats ssl qui restent exceptionnels, le seul endroit sensible reste la bdd. Dans ce cas on peut utiliser des fonctions de type password_hash qui permettent de définir un coût processeur important pour le hash. Ce qui permet une meilleure résistance et donc d'avoir pour "petits" mots de passe une résistance équivalente à des mots de passe beaucoup plus longs qui n'utiliseraient pas cette technologie.


Concernant l'authentification, pour satisfaire le plus grand nombre, je pense à priori que je mettrais en place un système (cookie...) pour enregistrer la config perso du client qui pourrait choisir si le navigateur doit pouvoir enregistrer le mot de passe ou pas. Pour ceux qui ne veulent pas, cela éviterait d'avoir la proposition du navigateur à chaque connexion, et pour les autres le problème de la longueur du mot de passe ne se poserait plus. Cela peut apporter un plus à peu de frais (facile à faire).

[Neckara]

S'il peut être intercepté en piratant le réseau (donc quand on utilise pas de connexion de type ssl)

Non, dans ce cas là, c'est plus compliqué car il faut aussi se protéger des attaques par rejeux.
On va plus être dans des authentifications du type challenge-response, si possible 0-knowledge.

De plus, il ne faut pas oublier qu'il faut garantir l'intégrité des données envoyée, empêcher les attaques par MITM, bref, il faut établir une connexion sécurisée. À moins, lors de l'authentification, de garantir l'intégrité des messages précédents et d'arrêter la connexion ensuite.

Bref, dans le cas de l'auteur, il faut une connexion sécurisée.

sha512

Il me semble que pour des raisons intrinsèque à l'algorithme, le sha512 est tout aussi sûr que le sha256 (?).

Ce qui permet une meilleure résistance et donc d'avoir pour "petits" mots de passe une résistance équivalente à des mots de passe beaucoup plus longs qui n'utiliseraient pas cette technologie.

Attention, il faut tout de même avoir des mots de passes d'une longueur/force minimale.

À noter aussi qu'en réalité, si on multiplie le coût d'un hash par x, le coût de l'attaque sera bien augmentée, mais ne sera pas multipliée par x.
La principale sécurité reste la force du mot de passe. Le coût de calcul d'un hash, n'est qu'un "ajout" de sécurité permettant l'utilisation de mots de passes un peu moins forts ou de rallonger la durée de vie d'un mot de passe "fort".

Tu peux mettre n'importe quel coût, si ton mot de passe est un PIN à 4 chiffres, bcrypt ne te servira à rien.
De même si le mot de passe est trivial "123456", "abcdef", etc.

Concernant l'authentification, pour satisfaire le plus grand nombre, je pense à priori que je mettrais en place un système (cookie...) pour enregistrer la config perso du client qui pourrait choisir si le navigateur doit pouvoir enregistrer le mot de passe ou pas. Pour ceux qui ne veulent pas, cela éviterait d'avoir la proposition du navigateur à chaque connexion, et pour les autres le problème de la longueur du mot de passe ne se poserait plus. Cela peut apporter un plus à peu de frais (facile à faire).

C'est plutôt une mauvaise idée.

Pour ne plus avoir le message du navigateur, il suffit de dire "je ne veux pas enregistrer le mot de passe" sur la pop-up, donc pas vraiment besoin d'ajouter une telle fonctionnalité.

Ensuite parce que, par défaut, les mots de passes sont enregistrés en clair dans le navigateur. À ce niveau là, il vaut mieux un cookie de session qu'on met si l'utilisateur coche "se rappeler de moi" à l'authentification, lui évitant de devoir se reconnecter par la suite.

Après, si on veut que le client utilise un gestionnaire pour stocker le mot de passe (et donc qu'il a pas besoin de le connaître et de s'en souvenir), il serait peut-être intéressant de regarder s'il ne peut pas enregistrer une clé publique et utiliser sa clé privée pour s'authentifier automatiquement au lieu d'utiliser un mot de passe (?).

[ABCIWEB]

Non, dans ce cas là, c'est plus compliqué car il faut aussi se protéger des attaques par rejeux.
On va plus être dans des authentifications du type challenge-response, si possible 0-knowledge.

De plus, il ne faut pas oublier qu'il faut garantir l'intégrité des données envoyée, empêcher les attaques par MITM, bref, il faut établir une connexion sécurisée. À moins, lors de l'authentification, de garantir l'intégrité des messages précédents et d'arrêter la connexion ensuite.

Bref, dans le cas de l'auteur, il faut une connexion sécurisée.
...
Il me semble que pour des raisons intrinsèque à l'algorithme, le sha512 est tout aussi sûr que le sha256 (?).

J'ai simplement dit que la longueur du mot de passe devait être obligatoirement importante si l'on utilisait pas de connexion ssl car dans ce cas le seul moyen que l'on a de protéger le mot de passe lors de sa transmission est d'utiliser un algo de hashage qui soit compatible côté serveur et côté client. J'ai pris pour exemple le sha512 en disant qu'il n'était pas gourmand en ressource d'où l'intérêt d'avoir des mots de passe le plus long possible pour compenser la moindre résistance contre la force brute. Je n'ai pas fait de comparaison avec le sha256 ni dit quelque part que l'auteur n'avait pas besoin de connexion sécurisée... ? Quel est le rapport avec ta réponse ?

Après pour le gain de sécurité en augmentant le coût du hash, évidemment faut comparer des mots de passe de force comparable.

Sinon, l'idée de gérer les préférences d'enregistrement du mot de passe du navigateur plus facilement depuis le site n'est pas forcément convaincante, je le reconnais (je disais bien "à priori"). D'un autre côté bon nombre d'utilisateurs ne savent pas gérer ces préférences (je parle de modifier des choix déjà enregistrés) donc ce ne serait pas forcément inutile pour tout le monde. Je proposais ça comme une facilité, pas comme une mesure de sécurité supplémentaire.

Ensuite parce que, par défaut, les mots de passes sont enregistrés en clair dans le navigateur.

Non, même si on peut faire afficher les mots de passe en ayant accès à l'ordinateur, pour autant et par défaut le navigateur enregistre les mots de passe chiffrés si je me réfère à la doc mozilla.

[Neckara]

J'ai simplement dit que la longueur du mot de passe devait être obligatoirement importante si l'on utilisait pas de connexion ssl car dans ce cas le seul moyen que l'on a de protéger le mot de passe lors de sa transmission est d'utiliser un algo de hashage qui soit compatible côté serveur et côté client.

On ne peut certes pas retrouver le mot de passe, mais on s'en moque, il suffira de connaître le hash pour s'authentifier.

Il ne faut pas envoyer le mot de passe ou son hash dans ce cas là, mais utiliser des authentifications avec challenge-response 0-knowledge.

Je n'ai pas fait de comparaison avec le sha256

Si le sha512 est aussi sécurisé que le sha256, utiliser le sha512 est inutile/inadapté dans ce contexte.

ni dit quelque part que l'auteur n'avait pas besoin de connexion sécurisée... ?

Si le mot de passe peut être intercepté sur le réseau, ce n'est pas vraiment une connexion sécurisée.

Non, même si on peut faire afficher les mots de passe en ayant accès à l'ordinateur, pour autant et par défaut le navigateur enregistre les mots de passe chiffrés si je me réfère à la doc mozilla.

En effet :

Même si le gestionnaire de mots de passe conserve vos identifiants et mots de passe sur votre disque dur dans un format chiffré, quelqu'un ayant accès à votre ordinateur peut toujours les voir et les utiliser.

Mais bon, même si c'est chiffré, si on peut le déchiffrer sans devoir apporter le moindre secret, il n'y a aucune différence que s'ils étaient stockés en clair.
C'est comme si en BDD tu stockais un mot de passe chiffré avec sa clé de déchiffrement et son sel. Cela revient exactement à le stocker en clair, sauf qu'on aura fait des calculs inutiles. Bref, même si c'est de l'abus de langage, je préfère dire que c'est en clair.

[ABCIWEB]

On ne peut certes pas retrouver le mot de passe, mais on s'en moque, il suffira de connaître le hash pour s'authentifier.

Non on ne s'en moque pas ! Pirater une session utilisateur n'a pas souvent le même impact que pirater un mot de passe. Parfois oui, mais souvent non. C'est quand même dommage de faire un amalgame quand on parle de problèmes de sécurité où le principe est justement de savoir faire des distinctions

Si le sha512 est aussi sécurisé que le sha256, utiliser le sha512 est inutile/inadapté dans ce contexte.
Si le mot de passe peut être intercepté sur le réseau, ce n'est pas vraiment une connexion sécurisée.

Je vois toujours pas à quelle question tu réponds, ou ce que tu as cru comprendre pour faire ces réponses.

Mais bon, même si c'est chiffré, si on peut le déchiffrer sans devoir apporter le moindre secret, il n'y a aucune différence que s'ils étaient stockés en clair.

Dans le pire des cas il n'y a aucune différence, mais globalement cela rend le piratage plus difficile. A te lire on pourrait croire que dans tous les cas le chiffrement n'offre aucun avantage. Là encore l'amalgame est imprudent, il est important de faire des distinctions

[Neckara]

Non on ne s'en moque pas !

Bien sûr que si on s'en moque ! L'attaquant se moque de trouver ton mot de passe, il en a pas besoin !
Il peut sniffer la connexion, il n'a donc aucun problème à récupérer le hash qui circule en clair et ainsi pouvoir s'authentifier à ta place sans aucun soucis !
L'attaquant n'a pas uniquement accès à ta session courante, mais à la totalité de ton compte !


Alors oui, il ne connaîtra pas le mot de passe et ne pourra pas s'authentifier sur les autres comptes du même utilisateur utilisant le même mot de passe (déconseillé), mais il s'en moque, son but était d'attaquer un compte, et il a totalement réussi, c'est fini, il a gagné.

Dans le pire des cas il n'y a aucune différence, mais globalement cela rend le piratage plus difficile.

Dans le cas où tu as un chiffré et sa clé à côté, c'est exactement la même sécurité que de l'avoir en clair.

La sécurité d'un système dépend de son maillon le plus faible. Mettre une porte blindée ne sert à rien si la fenêtre est ouverte ou si tu laisses la clé sous le paillasson.

A te lire on pourrait croire que dans tous les cas le chiffrement n'offre aucun avantage. Là encore l'amalgame est imprudent, il est important de faire des distinctions

Là, c'est toi qui fait un amalgame.


EDIT : Désolé, je m'emporte un peu quand on parle de sécurité.

[ABCIWEB]

Bien sûr que si on s'en moque ! L'attaquant se moque de trouver ton mot de passe, il en a pas besoin !
Il peut sniffer la connexion, il n'a donc aucun problème à récupérer le hash qui circule en clair et ainsi pouvoir s'authentifier à ta place sans aucun soucis !
L'attaquant n'a pas uniquement accès à ta session courante, mais à la totalité de ton compte !

Alors oui, il ne connaîtra pas le mot de passe et ne pourra pas s'authentifier sur les autres comptes du même utilisateur utilisant le même mot de passe (déconseillé), mais il s'en moque, son but était d'attaquer un compte, et il a totalement réussi, c'est fini, il a gagné.

C'est toi qui le dit qu'il s'en moque ! Mais qu'en sais tu ? Et si son objectif était simplement de récupérer le mot de passe ? Tu prends beaucoup de risques en limitant les possibilités du pirate à un comportement stéréotypé. En plus comme tu connais déjà le sujet je ne comprends pas bien pourquoi tu insiste

Dans le cas où tu as un chiffré et sa clé à côté, c'est exactement la même sécurité que de l'avoir en clair.

La sécurité d'un système dépend de son maillon le plus faible. Mettre une porte blindée ne sert à rien si la fenêtre est ouverte ou si tu laisses la clé sous le paillasson.
...
Là, c'est toi qui fait un amalgame.

Effectivement ma dernière remarque peut prêter à confusion. Je la reformule donc plus précisément :
A te lire on pourrait croire que dans tous les cas le chiffrement des mots de passe enregistrés par le navigateur n'offre aucun avantage. Dans le pire des cas il n'y a aucune différence, mais globalement cela rend le piratage plus difficile.
Et même remarque que plus haut, je ne comprends pas bien pourquoi tu insiste en laissant supposer le contraire

EDIT : Désolé, je m'emporte un peu quand on parle de sécurité.

Là on est d'accord
J'ai d'ailleurs bien l'impression que ton élan non maîtrisé (je parle pas de tes connaissances mais de la structuration de tes remarques) pourrait te pousser à te prendre les pieds dans le tapis tout seul comme un grand (comme on dit). Ce qui est assez croustillant quand on parle de sécurité Je taquine

[Neckara]

Tu prends beaucoup de risques en limitant les possibilités du pirate à un comportement stéréotypé.

Au contraire, je dis simplement qu'à partir où tu ne te protèges pas des attaques par rejeux, tu as perdu, c'est tout.
Tu prends des risques quand tu ne te protège pas des attaques par rejeux, pas l'inverse.

C'est comme la différence entre être tué ou être tué ainsi que 50 inconnus.
Le deuxième est pire que le premier. Mais on s'en moque, on est mort de toute façon. C'est fini, game over.

C'est comme si ton niveau de sécurité c'est 0. Tu doubles ton niveau de sécurité, 0 x 2 = 0.

Qu'un attaquant récupère les mots de passes ou n'importe quoi d'autre qui lui permet de s'authentifier par rejeux, c'est fini. Sur une attaque à grande échelle, l'entreprise a des chances de mettre la clé sous la porte.
Les conséquences d'un manquement en sécurité ne sont pas anodines, donc protégez-vous au maximum de ce qui est possible.

A te lire on pourrait croire que dans tous les cas le chiffrement des mots de passe enregistrés par le navigateur n'offre aucun avantage.

Attention, je parle bien du comportement par défaut où l'utilisateur n'a pas besoin de saisir un mot de passe pour pouvoir lire les mots de passes. S'il n'y a apport d'aucun secret, c'est que tous les secrets nécessaires sont déjà disponibles sur l'ordinateur client.

Avec firefox, en 2 minutes je sais où sont stockés les chiffrés de mes mots de passes, j'ai même le type d'algorithme utilisé. Et en 5 minutes j'ai trouvé ceci : http://www.nirsoft.net/utils/passwordfox.html

C'est bon j'ai gagné.
Bon au pire, j'aurais pu lire les sources ou la documentation développeur et m'en inspirer pour construire ma propre solution. Mais il suffit d'une seule personne motivée pendant à peine quelques jours pour que son travail soit disponible à tous.

Dans le pire des cas il n'y a aucune différence, mais globalement cela rend le piratage plus difficile.

En gros il faut juste récupérer le profil de l'utilisateur à attaquer (idem pour des mots de passes en clair).
Puis lancer un logiciel pour récupérer un mot de passe (idem pour des mots de passes en clair, à moins de vouloir les rechercher à la main).
En quoi est-ce plus difficile ? C'est juste une recherche sur Google.

J'ai d'ailleurs bien l'impression que ton élan non maîtrisé (je parle pas de tes connaissances mais de la structuration de tes remarques) pourrait te pousser à te prendre les pieds dans le tapis tout seul comme un grand (comme on dit).

Surtout que comme je n'ai pas beaucoup de temps, je dois m'obliger à répondre très vite.

[ABCIWEB]

Au contraire, je dis simplement qu'à partir où tu ne te protèges pas des attaques par rejeux, tu as perdu, c'est tout.
Tu prends des risques quand tu ne te protège pas des attaques par rejeux, pas l'inverse.

Quand ai-je dis qu'il ne fallait pas se protéger des attaques par rejeux ?

C'est comme la différence entre être tué ou être tué ainsi que 50 inconnus.
Le deuxième est pire que le premier. Mais on s'en moque, on est mort de toute façon. C'est fini, game over.

C'est comme si ton niveau de sécurité c'est 0. Tu doubles ton niveau de sécurité, 0 x 2 = 0.

C'est ce genre de remarque qui me fait dire que tu te prends les pieds dans le tapis. Pour mémoire le début de la confusion à commencé ici

On ne peut certes pas retrouver le mot de passe, mais on s'en moque, il suffira de connaître le hash pour s'authentifier.

La bonne réponse eut été :

On ne peut certes pas retrouver le mot de passe, cependant il suffira de connaître le hash pour s'authentifier.

Parce que en disant "on s'en moque" tu mets sur le même plan un vol de mot de passe et un vol d'authentification. Je ne t'apprends rien en disant que les attaques ne sont pas toujours frontales et qu'on peut tenter de récupérer un mot de passe pour essayer de l'utiliser ailleurs.
Dans le contexte d'une connexion non sécurisée et d'une écoute réseau, le hashage du mot de passe côté client répond à la problématique de la protection du MOT DE PASSE.
Toutefois cela ne répond pas à la problématique de la protection des privilèges donnés par l'AUTHENTIFICATION depuis le formulaire, puisqu'en récupérant le hash on pourra s'authentifier. Il faut donc aussi se protéger des attaques par rejeu. On est d'accord. Il faut répondre aux deux problèmes. Mais le premier n'est pas à négliger et même si tu peux établir une hiérarchie il ne vaudra jamais 0 puisqu'il répond à un problème SPECIFIQUE.

Après bon c'est certain que la démocratisation des connexions ssl permet de traiter efficacement ces deux problèmes et qu'il faut surtout éviter de s'en priver si l'on a besoin d'accès public sécurisé. On y a gagne beaucoup en efficacité et en prise de tête. Ouf

Pour le reste une chose est de connaître l'adresse d'un fichier, une autre est de pouvoir le récupérer et l'exploiter.
Dans tous les cas il faudra infecter l'ordinateur cible. Déjà à ce niveau on peut se demander s'il ne serait pas plus rentable/facile pour le pirate d'utiliser un keylogger plutôt qu'une attaque frontale du fichier des mots de passe. Au passage je ferais le même type d'approximation que toi plus haut si je disais que la protection des mots de passe ne sert à rien tant que le formulaire d'authentification n'utilise pas un clavier virtuel ou système permettant d'éviter les keyloggers ou autres joyeusetés du même genre. On empile des systèmes de sécurités pour répondre à des problématiques différentes. On en néglige pas un, parce qu'un autre, même éventuellement plus important, peut exister.

Et pour terminer mes taquineries sur la structuration de tes remarques, plutôt que de t'étendre sur le fait que tu peux pirater tout et n'importe quoi en moins de cinq minutes (j'exagère exprès ), n'aurait-il pas été plus judicieux d'insister sur la conclusion qui aurait pu être simplement :

Pour aller jusqu'au bout du processus de protection des mots de passe enregistrés par les navigateurs, il faut utiliser un mot de passe global qui protégera l'accès

enfin un truc dans le genre...
Je sais bien que tu as dit grosso modo la même chose, mais j'ai l'impression que pour bien te comprendre il faut te lire en creux. Mais bon si tu n'a pas le temps... c'est vrai qu'il n'est pas facile d'écrire en relief quand on est pressé

[Neckara]

Quand ai-je dis qu'il ne fallait pas se protéger des attaques par rejeux ?

Tu parlais d'envoyer un hash du mot de passe sur un canal non sécurisé.

Parce que en disant "on s'en moque" tu mets sur le même plan un vol de mot de passe et un vol d'authentification.

Pas nécessairement.

Un petit pistolet n'est pas sur le même plan qu'un gros machin automatique qui tire je-ne-sais-combien à la seconde.
Que ton adversaire ai l'un ou l'autre, tu t'en moques de toute façon, tu es mort !

Dans le contexte d'une connexion non sécurisée et d'une écoute réseau, le hashage du mot de passe côté client répond à la problématique de la protection du MOT DE PASSE.

Mais le secret n'est plus le mot de passe, mais le hash, le hash est le nouveau mot de passe.

Mais le premier n'est pas à négliger

Je n'ai jamais dit le contraire, j'ai même parlé de challenge-response 0-knowledge.

et même si tu peux établir une hiérarchie il ne vaudra jamais 0 puisqu'il répond à un problème SPECIFIQUE.

Non, tu doubles la sécurité d'un système qui a une sécurité de 0.

Mais la question ne se pose même pas, on ne laisse pas de telles failles de sécurités béante dans un système. Ne serait-ce que d'envisager ou de sous-entendre qu'on puisse se contenter de hasher le mot de passe avant de l'envoyer sur un canal non sécurisé est une hérésie.

Après bon c'est certain que la démocratisation des connexions ssl permet de traiter efficacement ces deux problèmes et qu'il faut surtout éviter de s'en priver si l'on a besoin d'accès public sécurisé. On y a gagne beaucoup en efficacité et en prise de tête. Ouf

Oui, surtout qu'on a aussi des certificats gratuit distribué par la fondation Mozilla.
Et pour les petits systèmes pour qui SSL est trop lourd, on a aussi des protocoles qui permettent de protéger tout cela.

Pour le reste une chose est de connaître l'adresse d'un fichier, une autre est de pouvoir le récupérer et l'exploiter.

Tu es en train de partir en HS, on parle de stocker les mot de passe en clair vs les stocker chiffrés avec la clé de déchiffrement à côté.

si je disais que la protection des mots de passe ne sert à rien tant que le formulaire d'authentification n'utilise pas un clavier virtuel ou système permettant d'éviter les keyloggers ou autres joyeusetés du même genre.

Le clavier virtuel n'est pas une solution pour des vrais mots de passe, tu baisseras ta sécurité pour avoir un petit gain ailleurs.
Pour le moment, les protections c'est éviter d'avoir des virus et restreindre l'accès physique aux ordinateurs. C'est une tâche qui incombe au client, pas au fournisseur de service. La responsabilité n'est pas celle du fournisseur mais du client.

Il existe bien des solutions, mais qui sont encore qu'au stade de la recherche.

On en néglige pas un, parce qu'un autre, même éventuellement plus important, peut exister.

Je n'ai jamais dit le contraire, mais on s'en moque d'avoir une forteresse si la porte est ouverte.

n'aurait-il pas été plus judicieux d'insister sur la conclusion qui aurait pu être simplement : enfin un truc dans le genre...

Pour aller jusqu'au bout du processus de protection des mots de passe enregistrés par les navigateurs, il faut utiliser un mot de passe global qui protégera l'accès

En fait, il vaut mieux utiliser un gestionnaire de mot de passe externe au navigateur (c'est toujours un petit plus).
Mais c'est vrai que ce n'est pas une solution parfaite. Mais on a rien de mieux pour le moment.

Je sais bien que tu as dit grosso modo la même chose, mais j'ai l'impression que pour bien te comprendre il faut te lire en creux. Mais bon si tu n'a pas le temps... c'est vrai qu'il n'est pas facile d'écrire en relief quand on est pressé

Oui, puis surtout il y a la manière de dire, formuler les propos pour ne pas paraître trop agressif, etc.
Mais il me faudrait des heures pour un seul message

[ABCIWEB]

Mais la question ne se pose même pas, on ne laisse pas de telles failles de sécurités béante dans un système. Ne serait-ce que d'envisager ou de sous-entendre qu'on puisse se contenter de hasher le mot de passe avant de l'envoyer sur un canal non sécurisé est une hérésie.

Encore une fois, ce sous-entendu est juste dans ta tête, tu l'a fabriqué de toutes pièces. Si tu avais fait une réponse complémentaire (comme expliqué dans mon précédent message) plutôt qu'une réponse péremptoire en opposition et qui brouille complétement mon message initial, on en serait pas là

Dès ma première réponse j'ai essayé de t'expliquer le malentendu, et tu me réponds des histoires de révolvers, mitrailleuses, forteresses, ou des rappels de calculs élémentaires comme quoi 2x0 font 0. Très instructif en effet. Au passage cela rappellent beaucoup les techniques d'enfumage employées par les vendeurs ou hommes politiques etc qui vont toujours essayer de fourguer des évidences à deux balles dans leur discours pour tenter de renforcer leur crédibilité... A mon tour je pourrais en tirer des conclusions hâtives en disant que tu es donc à court d'arguments réels, en mode "bluff/enfumage"

Oui, puis surtout il y a la manière de dire, formuler les propos pour ne pas paraître trop agressif, etc.

Très bon diagnostic. Aussi ce n'est pas parce que tu connais bien le sujet qu'il faut penser à prioiri que les autres ne savent pas de quoi ils parlent. Ne pas sous-estimer les autres est la première règle à appliquer quand on parle de sécurité, quelque soit son niveau