Waow 42 caractères pour un mot de passe!!!

Ce n'est pas le premier à ne pas vérifier les entrées utilisateur. Ce devrait pourtant être un réflexe.

"Je vais donc sur la page de modification de mot de passe, et ils me disent qu'il y a une limite de 20 caractères. Je mets quand même celui à 42"
CTLP

"et ça fonctionne"
BEDP

1 partout, balle au centre.

"il y a une limite de 20 caractères."
BEDP puissance 1000...

http://xkcd.com/936/

Le mien en fait 53... et pourtant je l'estime encore perfectible.

42 caractères? Petit joueur!

"Je ne tiens pas compte des limites imposées et je m'étonne que ça ne fonctionne pas" : CTLP

Il a pu suivre ses cours avec JVachier.

Le mieux est de mêler les deux règles, enfin, c'est ce que je fais dès qu'un mot de passe protège un accès un peu sensible, avec changement toutes les semaines.

Bon, j'avoue, ça fait des frais de postit et mon clavier ne tient plus droit, mais à part ça :redface:

Non. Je suis certain qu'en PHP on peut faire un joli "> erase all ou truc de ce genre... vu qu'a priori il n'y a aucun test d'entrée utilisateur..

Moi je recopie des versets de la Bible. OK, il me faut un certain temps pour rentrer mon mot de passe, surtout depuis mon téléphone en T9, mais c'est parfait au niveau sécurité.

Vive les gestionnaires de mots de passe! =)

"Je veux juste voir si ce site est, comme bien trop d'autres, sans vérification des entrées utilisateurs, et constate qu'effectivement c'est bien un pifenmoins qui l'a codé avec ses pieds" : BEDP.

Je m'abstiendrai de voter avant d'avoir pu répondre à ces trois questions:
1) Le fait qu'un site de transaction bancaire n'autorise pas des mots de passes de plus de 20 caractères est-il en effet une "faille de sécurité" qui mériterai qu'on vote BEDP ?
2) Le fait que l'auteur ait été clairement averti que la longueur maximale est de 20 caractère et ait pourtant sciemment tenté de dépasser cette limite mérite t'il un vote CTLP ?
3) Dans le cas ou les deux hypothèses s'avèrent exactes, laquelle constitue un acte plus grave que l'autre?

Vous avez 4 heures! Je ne demande qu'à être convaincu.

En fait il s'agit d'un sécurité destinée à ne pas laisser se connecter les psychopathes de la sécurité :-)

J'ai trouvé un autre système plus efficace (et rapide) et surtout sans logiciel.

Hein ? Non, touche pas au clavier !

Tant que Mme Michu peut se connecter avec son mdp en mousse de bois, aucun souci...

1) Non.
2) Oui.
3) BEDCTLP.

1/ Pour moi, le bon mdp est déjà celui qu'on retient bien, on peut avoir des règles pour les faire. Bon, moi, pas vraiment (enfin, j'en ai plusieurs), mais ça me fait mal au derche à chaque fois que je dois me limiter, oui.

2/ <set mauvaise_foi=1> L'auteur n'a jamais spécifié ne pas être un testeur de sécurité de ladite banque </set>

3/ Heu........... Miaou ! (oh qu'il est mignon !)

1) Oui
2) Non
3) 1

On m'a dit que plus il y avait de caractères mieux c'est... alors j'ai choisi "2048 Caractères" comme mot de passe... Si ça c'est pas de la sécurité !
Sinon plus sérieusement, il y a manifestement un problème sur le site au niveau des champs de saisie, mais à mon sens, le plus gros PEBKAC reste celui de l'auteur qui, bien que prévenu à l'avance, tente le diable pour se retrouver dans la situation merdique dans laquelle il est à présent...
Sinon, pour le mot de passe, plutôt que se limiter à penser qu'il a été tronqué de la fin, il a peut être bien été tronqué du début, chaque nouvelle lettre entrée au delà de la vingtième effaçant la première ?

PEBKAC n°xxxx

Un utilisateur me contacte aujourd'hui à la hotline car il ne peut plus accéder à son compte.
Voulant changer son mot de passe, il en a choisi un de plus de 40 caractères, alors qu'il lui a bien été spécifié que le site n'accepte que 20 caractères maximum...
PEBKAC

1/ En ce qui me concerne (en tant que Paranoïaque de base ET par déformation professionnelle), un "Bon mot de passe" est un "Mot de passe que je ne connais pas!" C'est entre autre pour ça que j'aime beaucoup les OTP (One-Time-Password).

Ensuite, j'utilise une application (KeePass2) pour gérer mes mots de passe. J'ai donc "un mot de passe connu" qui me débloque l'accès à tous mes autres mots de passes "non-connus".

2/ <set esprit_de_contradiction=1> L'auteur n'a jamais spécifié être autre chose qu'un simple utilisateur de ladite banque. </set>

3/ 0o Heuu.... Ronron-Ronron-Ronron?

1) Un développement de la réponse serait apprécié.
2) Voir numéro 1
3) Voir numéro 2.

Merci =)

1) oui
2) oui
3) la 1, mais pour la 2, je dis "bien fait pour taggle"

Va chier ?

Pour moi outre vérifier que le champ n'est pas vide, il ne devrait pas y avoir de vérification sur le mot de passe ; en effet, celui-ci devrait être hashé afin de ne pas être connu du site. Les hashs ayant tous la même taille, aucune vérification supplémentaire n'est nécessaire.
Dites-moi si j'ai tord mais je pensais que c'était une pratique basique de sécurité et je suis très étonné de ne pas la voir mise en place sur un site de paiement en ligne...

Ouais, t'as déplacé toutes les touches de ton clavier pour que ton mot de passe soit dans l'ordre, c'est ça ? Ou alors tu as mis du Typex™ sur les touches et numéroté chaque touche dans l'ordre du MdP ? :D

42 caractères, c'est vraiment de la frime...

1) http://xkcd.com/936/
J'ajouterais que l'on ne devrait pas être limité pour la taille et le contenu d'un mot de passe... Même si les mots de passe de plus de 20 caractères sont rares (hélas), ce n'est pas une raison pour les interdire.
2) http://fr.wikipedia.org/wiki/Hacking
"Dans un sens large, le hacking concerne les activités visant à détourner un objet de sa fonction première. Le hacking a pour fonction de résoudre ou d'aider à résoudre des problèmes, et cela dans de nombreux domaines."
Si ça ne te parle pas, ou que tu penses que ça n'a rien à faire là, libres à toi mais alors retiens ça à la place : la base de la programmation de formulaires, c'est de toujours vérifier la saisie de l'utilisateur. PEBKAC pour l'entreprise.
3) Les deux hypothèses ne sont pas vérifiées. Mais 1) est déjà amplement suffisant pour mériter un BEDP.

Et enfin, tu n'as pas précisé nul part que tu voulais des "développements"... Et vu que tout avait déjà été dit dans les autres commentaires... :)

La réponse que j'attends en réalité est un... "argumentaire un peu plus fourni". =)

Si cela peut vous aider, voici ma propre analyse:

1) Le fait qu'un site de transaction bancaire n'autorise pas des mots de passes de plus de 20 caractères est-il en effet une "faille de sécurité" qui mériterai qu'on vote BEDP ?
-Un site, qui plus est "bancaire" se doit d'avoir une "sécurité maximale". A ce titre, j'estime que la limitation du nombre de caractère dans le mot de passe peut constituer une faille de sécurité pour ceux désirant avoir une sécurité accrue grâce à une longueur de mot de passe supérieur.
Réponse 1) Oui.

2) Le fait que l'auteur ait été clairement averti que la longueur maximale est de 20 caractère et ait pourtant sciemment tenté de dépasser cette limite mérite t'il un vote CTLP ?
-Dans la mesure ou l'utilisateur à clairement été averti que la limite est de 20 caractère mais qu'il n'en tient délibérément pas compte, le problème peut être vu comme venant de sa part puisqu'il ne respecte volontairement pas les instructions.
Réponse 2) Oui.

3) Dans le cas ou les deux hypothèses s'avèrent exactes, laquelle constitue un acte plus grave que l'autre?
Là c'est plus complexe... En prenant en compte les deux analyse, je vois des "erreurs" plus ou moins discutables de part et d'autre... Je ne parvient pas à me décider si je dois "sanctionner":
-Le site pour sa politique de sécurité qui, bien que suffisante aux yeux de beaucoup, peut paraitre "trop faible" aux yeux de paranoïaques avertis (même si je ne considère pas le fait d'être paranoïaque comme une tare, que ce soit dans le domaine informatique en générale et plus encore dans les milieux bancaires!).
-L'utilisateur qui, en son âme et conscience décide que la limitation clairement imposée est "à titre indicatif" et qui s'étonne au final de ne plus pouvoir accéder à son compte.
Réponse 3) Dur-dur...

"voit les pouces rouges qui s'accumulent sur son premier messages"
"voit les pouces verts qui s'accumulent sur le deuxième avec le lien"
...les gens, vous réalisez que les deux messages disent basiquement la même choses?

Mince ! Je ne suis donc pas le seul à avoir &é"'(-è_ç comme mot de passe ?

Vous avez 4 heures! Je ne demande qu'à être convaincu.

De mon point de vue, "convaincre" induis une argumentation (et donc "un développement").

Je partage ta vision des choses pour le point numéro 1.

Pour ce qui est du point numéro 2, je suis d'accord sur le fait que l'absence de vérification est problématique... L'utilisateur ne respecte pas les "conditions d'utilisation", c'est vrai, mais effectivement, "rien ne vérifie que les conditions d'utilisations ont été respectés" lors de la validation du formulaire. Bien que l'utilisateur fait "une faute", je n'avais jusqu'alors pas poussé l'analyse sur le fait que l'absence de vérification de la saisis constitue une faute encore plus lourde pour le site.

3) Ce n'était donc pas si difficile de me convaincre pour voter: BEDP. Merci d'avoir pris le temps de développer ta réponse Shin.

moi, oui.
Mais je n'ai mis ni pouce rouge ni pouce vert.

Cela faisait partie de mes deux hypothèse contradictoires qui me retenait de voter... Après l'argumentaire de Shin, je n'ai plus de doute. Cela donnerai donc:

Un utilisateur me contacte aujourd'hui à la hotline car il ne peut plus accéder à son compte.
 Voulant changer son mot de passe, il en a choisi un de plus de 40 caractères, alors que le site dit qu'il n'accepte que 20 caractères maximum. Aucune vérification n'est faite pour s'assurer que l'utilisateur entre un mot de passe qui respecte les conditions indiqués sur le site. Pour le développeur: PEBKAC.

Je te renvoie aux commentaires de Shin pour les raisons qui m'amènent à considérer que le problème se situe plus au niveau du site que de l'utilisateur.

42 n'est pas la réponse universelle des mots de passe ;)
pour moi, 20 caractères sont largement suffisant, l'important c'est le formatage de celui-ci et son hashage (donnée inconnue) car le site peut très bien utiliser un hash qui ne sert à rien au delà de 20 caractères.

le plus gênant sont les sites qui ne permettent pas les accents, pourtant à voir les dictionnaires de password, rien que ça permet d'ajouter un niveau supplémentaire de sécurité.
est-ce que le site l'interdit ? A priori nan...

mettre 42 car. Alors qu'on a été prévenu que ça ne fonctionnerait pas, puis s'étonner que ça ne fonctionne effectivement pas...
CDTLP

Je suis assez d'accord... Avec un mot de passe de 20 caractères aléatoires parmi 96, on arrive déjà à environs 7,9e+124 combinaisons possibles... En bruteforce, y a de la marge...
Pour info (même si les configs utilisées datent de Mathusalem : http://www.lockdown.co.uk/?pg=combi)
Mais bon, le problème reste déjà celui des sites qui ne permettent pas l'utilisation de symboles ou de lettres accentuées et le type de hash utilisé (quand on voit que des clusters de GPU "abordables" sont capables de vérifier quelquechose comme 180 milliards de hash md5 par secondes, et 63 milliards en SHA1)...

1) D'une manière générale, c'est une hérésie de limiter un MDP -> PEBKAC
2) Touche pas, c'est chaud! Aïe, c'est chaud! -> couillon
3) 1 PEBKAC et un couillon, le PEBKAC l'emporte, mais le couillon reste couillon

Mais c'est pas vrai ! Noname, on avait convenu de ne même pas évoquer un morceau de mon pass ! Je suis vraiment mécontent !!!

C'est ce que répond son compilateur.

On peut vérifier côté client (un banal JS sur la page HTML) et le site peut très bien ne jamais connaître le pass de cette manière...

@ Sihn des fois il faut pas chercher la logique des pouces dans les commentaires!

J'ai connu un admin qui utilisait le numéro de série du clavier comme mot de passe de session...
Il a été surpris quand j'ai inversé mon clavier et le sien pendant ses vacances.
C'était une petite blague gentillette, sachant que j'avais son Mdp sous la main, j'aurais tout aussi bien pu lui flinguer sa sessions ou faire d'autres conneries avec son poste.

Puis finalement, une fois son clavier restitué après deux tentatives infructueuses (je suis peut-être un connard, mais je sais aussi m'arrêter), il à opté pour un mot de passe plus "personnel". Ma petite pique n'aura donc pas eu un effet si négatif que cela. =)

Le problème se situe, de mon point de vue, dans l'ordre des réponses.
Sur le premier, tu donne uniquement le résultat, pas le processus de réflexion qui t'as amené à penser cela. Pris "brute de fonderie", ça peut paraître négatif (=pouce rouge).
Le second donne une indication sur "pourquoi" tu pense cela. Une petite image vaut mieux qu'un long discours, elle "développe" le processus de réflexion qui t'amène à la conclusion. Il devient alors difficile de ne plus être en accord avec toi (=pouce vert).

On a souvent tendance à penser que "la réponse est tout ce qui compte", mais à mon sens le processus de réflexion qui amène la réponse est en fait tout aussi (voir plus) intéressant.

Non c'est mieux de faire le hash coté serveur mais il faut que ca soit envoyer en https. Par contre, ce qu'il ne faut absoulument pas faire, c'est le conserver en clair ou d'une manière reversible.

A la réponse de Fox je rajouterais que en plus la banque ne sait pas coder correctement un controle de validation de formulaire, donc ce n'est pas un bon signe pour le reste de la sécurité du site.

Je considère que l'auteur ne peut-être un PEKBAC puisqu'il a *volontairement* essayé de pousser le système à ses limites.

On peut aussi "convaincre" avec un gros marteau... Ou n'importe quelle autre arme contondante / tranchante / perforante / café en capsule.

Et augmenter le délai entre 2 saisies erronées successives de mot de passe pour un même login, n'est-ce pas la méthode la plus efficace ?
Voire blocage après x essais et envoi d'un mail pour prévenir.
ça bloquerai tout de suite la force brute.

Je suis résistant, mais pas incorruptible. On peut très bien "acheter" mon vote avec des bouteilles de Liptonic et des Cookies. Faites vos offres. =)

Je prends aussi les payement en Thé (Blanc de préférence). Et pas les merdes en sachets ou on sent le goût du papier ou les thé aux agrumes qui masquent tout. Rien ne vaut un bon thé qui ne contient que l'essentiel: Les feuilles de thé.

Oh, petite précision: Les payements se font à l'avance.

et si la longueur du mdp dépasse la taille du hash ???

tu peux aussi faire le hash coté client l'envoyer et le re- hasher avec un salt coté serveur

et si la longueur du mdp dépasse la taille du hash ???

What ?

Peut-être que le mot de passe a été tronqué, et que taper les 20 premiers caractères de ton mot de passe fonctionne.

je parlais pour le risque de collision (2 mdp qui ont le même hash) je ne sais pas si c'est important ou négligeable en matière de sécurité optimale surtout sur des mdp très très longs mais bon

1) Une faille de sécurité, je n'irais pas jusque là, et c'est trop "philosophique" pour que je réponde. Par contre, limiter la taille des mots de passe, c'est juste stupide. Ça ne peut que embêter certains utilisateurs
2) Non ! J'ai conciemment mit mon vrai mot de passe pour voir si c'était une vrai limite, ou juste quelque chose pour dissuader des utilisateurs qui ne retrouvent pas leur mot de passe.
Le PEBKAC est en fait qu'ils laissent passer des mots de passe de plus de 20 caractères, qu'on ne peut pas se connecter avec, mais qu'ils connaissent effectivement mon mot de passe, puisque je ne peux pas remettre le même.
3) La 1, bien évidemment. :-)

Ok, je décode 180millions de hash/s, mais faudra que l'on m'explique à quoi cela sert ? Il faut au moins une seconde pour que le système me renvoie un message d'erreur quand je me trompe de compte sur la page web de saisie des identifiants.

J'essaie de voir s'ils ont tronqué mon mot de passe à 20 lettres, au cas où : ça ne marche pas non plus.

Non, Acorah, on ne peut pas convaincre avec un marteau. On peut persuader mais pas convaincre. ;-)

@Aaargh : si tu n'as pas de contrainte technique, pourquoi imposer à l'utilisateur une contrainte sur son mot de passe? Vérifier une taille minimale augmente la sécurité de l'utilisateur mais vérifier une taille maximale n'apporte pas grand chose à ma connaissance.

@glpl : Ce que tu veux dire, c'est "est-ce que mon mot de passe de 42 caractères ne risque pas d'avoir le même hash que 1234 ou abcde ?"

La longueur du mot de passe n'a rien à voir là-dedans... En principe, 2 valeurs d'entrées auront toujours la même probabilité d'avoir le même hash, soit 1/ (16^n) pour un hash de n caractères.

Mais en fait, les algos de hashage sont généralement optimisés pour donner des résultats très différents pour des valeurs d'entrées proches. Faire un salage général (ex: j'ajoute la même chaîne de X caractères au début de chaque valeur) en plus du salage spécifique (ex: j'ajoute l'id de l'utilisateur à la fin du mot de passe) permettrait donc de diminuer les risques de collision (je n'ai jamais eu l'occasion de faire de vrais tests là-dessus, ce qui pourrait être intéressant).

Mais la probabilité de collision existera toujours et sera plus ou moins celle que je cite plus haut. Encore une fois, la longueur n'a rien à voir là-dedans... on peut très bien imaginer un "mauvais" algorithme de hashage qui donnerait le même hash pour tous les nombres de 4 ou 6 chiffres... ils seraient bien baisés sur les sites de banque !

J'imagine qu'il peut y avoir plusieurs raisons de vouloir limiter le password en taille :
- celle évoquée pour éviter l'exploitation d'une faille potentielle de l'algorithme de hashage sur les collisions. En effet avec un mauvais algorithme on pourrait éventuellement générer facilement un mot de passe correspondant un hash donné avec pleins d'octets de bourrages bien choisi (sans pour autant trouver le "vrai" mot de passe de l'uilisateur.
- celle de possibilité de bug dans le mécanisme d'authentification avec un mot de passe vraiment trop grand (avec exploitation potentielle de ce bug).
- celle d'éviter de bouffer trop de resources à calculer des hash sur des mots de passe.

Du coup je pense que limiter le mot de passe à une taille de genre 30-50 caractères est une bonne pratique et ne gênerera pas grand monde à part des paranoïaques.

Pour le salage, c'est surtout pour éviter l'exploitation de rainbow table, ce n'est pas pour réduire le nombre de collision mais pour éviter que la correspondance entre le hash et le mot de passe (faible) de l'utilisateur soit déjà connu.
J'ai commenté ça ici : http://www.pebkac.fr/pebkac/9482/#comment_130182

C'est dans le cas où l'attaquant à réussi à récupérer la table des hash de mots de passes de la base de donnée.
A partir de cette base il peut s'amuser à retrouver les mots de passes des utilisateurs pour ensuite les exploiter (soit directement sur le site même après que l'intrusion est été détectée, soit sur d'autres sites où l'utilisateur a utilisé le même mot de passe).
Ca arrive assez fréquemment même sur des "grands" sites.

J'aurais voulu voter mais t'es à +42