Salut la communauté.

Un petit débat fait rage ses derniers temps sur la sécurité des mots de passe aux caractères très diversifiés
(genre "O8$@b4Bd3r").

En effet, il paraîtrait que la simple phrase "meilleur boudin du jour" est bien plus résistant à une attaque.

Fidèle à ses habitudes, c'est le webcomic XKCD qui à fait sortir le sujet hors des cercles confidentiels.

Certains ont aussi tendance à penser qu'il suffit d'inclure un caractère euro (€) pour améliorer la sécurité apportée par un mot de passe.

En utilisant un outil online vachement bien fait (http://rumkin.com/tools/password/passchk.php), voici quelques résultats édifiants (le critère essentiel est l'entropie, facilité avec laquelle le mot de passe peut-être deviné):

Mot de passe : O8$@b4Bd3r
Length: 10
Strength: Reasonable - This password is fairly secure cryptographically and skilled hackers may need some good computing power to crack it. (Depends greatly on implementation!)
Entropy: 44.8 bits
Charset Size: 72 characters


Mot de passe : €8$@b4Bd3r
Length: 10
Strength: Reasonable - This password is fairly secure cryptographically and skilled hackers may need some good computing power to crack it. (Depends greatly on implementation!)
Entropy: 55.4 bits
Charset Size: 232 characters


Mot de passe: meilleur boudin du jour
Length: 23
Strength: Strong - This password is typically good enough to safely guard sensitive information like financial records.
Entropy: 88.3 bits
Charset Size: 27 characters

Mot de passe: élève de jour et de nuit
Length: 24
Strength: Very Strong - More often than not, this level of security is overkill.
Entropy: 143.2 bits
Charset Size: 187 characters

Et juste pour le plaisir: meilleur boudin du jour€
Length: 24
Strength: Very Strong - More often than not, this level of security is overkill.
Entropy: 146.4 bits
Charset Size: 187 characters



Conclusion: l'utilisation du symbole € améliore la sécurité d'un mot de passe, mais pas plus que l'emploi de lettre accentuées.
Mais comme on vient de voir, la meilleure garantie de sécurité n'est pas la diversité de caractères utilisés, mais la longueur du mot de passe.
Un mot de passe court et très diversifié est bien moins sécure qu'un mot de passe long ne contenant que des lettres non-accentuées.

Le meilleur reste encore l'emploi de caractères accentués et des mots simples.

Ah j'ai trouvé le mien!:

Jojolapine : sa vie, son œuvre !

Length: 32
Strength: Very Strong - More often than not, this level of security is overkill.
Entropy: 192.4 bits
Charset Size: 243 characters

:-°

Sauf que tout fonctionne pas à base d'entropie, donc l'étude est très incomplète.
D'autres méthodes inverserait la difficulté.

Mais bon, pour ma part je trouve pas très utile d'avoir un mot de passe super costaud.
Les principaux hack et compagnie tournent autour de keylogguer ou trojan pour récupérer les mots de passe, ou bien de dictionnaire (de mots, ou bien de références à l'utilisateur ou son groupe).

Donc le plus sécurisant est de ne pas laisser trainer les saloperies qu'on choppe (pitètre un tous les 6mois pour ma part O.o) et de ne pas utiliser un mot de passe contenu dans un livre, dictionnaire, ou bien en rapport avec votre vie.
Et bien sûr d'avoir un mot de passe d'une certaine longueur pour palier aux brute force.

Chouette, j'ai trouvé le mien :

M€ill€ur qu€ moi tu m€urs ! :-þ

Et bien entendu :

Length: 31
Strength: Very Strong - More often than not, this level of security is overkill.
Entropy: 184.2 bits
Charset Size: 243 characters

Par contre c'est un peu suant à taper, je travaille toujours sur un clavier QWERTY FR-CA et la touche € n'est pas disponible et j'ai jamais trouvé comment la configurer

pffff va falloir que je change le nom du chat :/

Length: 8
Strength: Very Weak - Try making your password longer, including CAPITALS, or adding symbols.
Entropy: 27.4 bits
Charset Size: 26 characters

Et en plus de ça, faudrait aussi éviter absolument d'envoyer des mots de passe en clairs directement dans un post d'authentification, sinon quelque soit leur longueur ils sont vulnérables à tout sniffeur de réseau...

echo substr(base64_encode(openssl_random_pseudo_bytes(24)), 0, 24);

Et en plus de ça, faudrait aussi éviter absolument d'envoyer des mots de passe en clairs directement dans un post d'authentification, sinon quelque soit leur longueur ils sont vulnérables à tout sniffeur de réseau...

donc même genre de chose qu'indique stealth35 mais en JS ?

@+

Et en plus de ça, faudrait aussi éviter absolument d'envoyer des mots de passe en clairs directement dans un post d'authentification, sinon quelque soit leur longueur ils sont vulnérables à tout sniffeur de réseau...

donc même genre de chose qu'indique stealth35 mais en JS ?

@+

c'est pour ça que le https existe , ce qui serait sympa c'est que sur les client web le champ password supporte les hash :

<input type="password" hash="md5" name="pwd" />

c'est pour ça que le https existe , ce qui serait sympa c'est que sur les client web le champ password supporte les hash :

<input type="password" hash="md5" name="pwd" />

L'idée au départ est séduisante, mais à la réflexion, ça n'a pas grand intérêt.

Si c'était indiqué dans le HTML, ce serait donc clairement lisible dans la source et donc le pirate saurait comment s'adapter pour produire ses attaques en hachant ses envois de la même manière. Même un hachage md5 en JavaScript est possible mais présente le même défaut : on indique comment hacher les mots de passe envoyés et donc le pirate peut parfaitement faire la même chose parce que le code JavaScript est également lisible dans les sources coté client. La seule solution valable reste la connexion SSL avec un certificat valide (et non usurpé bien entendu)

Et de toutes les manières, il faudrait quand même être sur qu'on a une machine saine sur laquelle aucun pirate n'a jamais pu installer de KeyLogger sinon quelque soit la technique pour tenter de masquer quoi que ce soit ce serait complètement vain...

Il ne reste donc qu'une seule conclusion à tout ça : blinder autant que possible les système d'identification par l'utilisateur public n'est certes pas inutile, mais il faut également et surtout que le code coté serveur soit parfaitement protégé contre les injections en tous genre, codé avec rigueur et discipline et que les identifiants et mots de passe administrateurs ne soient jamais accessibles par qui que ce soit d'autre que les administrateurs eux-même.

My 2¢

De toutes façons il y a un bug commun à tous les formulaires, c'est l'interface chaise-clavier.
Faut que je poste le bug ou ? Sur le bugtracker de mozilla, php ou de la w3c ?

en fait il faudrait une sorte de langage de script qui serait capable de faire du md5 et qui soit côté serveur, ça réglerait tout ça non?

De toutes façons il y a un bug commun à tous les formulaires, c'est l'interface chaise-clavier.
Faut que je poste le bug ou ? Sur le bugtracker de mozilla, php ou de la w3c ?

Comme aurait dit Nagol pendant un temps : « stoi le bug »

en fait il faudrait une sorte de langage de script qui serait capable de faire du md5 et qui soit côté serveur, ça réglerait tout ça non?

On appelle ça le PHP Et ça ne règlerait rien puisque le problème de départ est la qualité du mot de passe mesurée selon sa complexité. Ajoutons à ça le problème de la transmission en clair sur le réseau de ce même mot de passe entre client et serveur faute d'une connexion SSL et la porte est ouverte au piratage... ou à l'usurpation d'identité selon l'usage que le pirate fera de ce qu'il aura récupéré.

c'est pour ça que le https existe , ce qui serait sympa c'est que sur les client web le champ password supporte les hash :

<input type="password" hash="md5" name="pwd" />

L'idée au départ est séduisante, mais à la réflexion, ça n'a pas grand intérêt.

Si c'était indiqué dans le HTML, ce serait donc clairement lisible dans la source et donc le pirate saurait comment s'adapter pour produire ses attaques en hachant ses envois de la même manière. Même un hachage md5 en JavaScript est possible mais présente le même défaut...

Si si cela a un grand intérêt, car s'il récupère une chaine de caractères haschée, le sniffeur de réseau doit encore faire du travail pour retrouver le mot de passe original. Pour peu que le mot de passe soit concaténé à un grain de sable différent pour chaque envoi de formulaire, le pirate ne récupèrera qu'une chaine qu'il ne saura pas exploiter.

Par contre avec un mot de passe qui transite en clair dans les tuyaux, le sniffer de réseau pourra trouver le mot de passe en clair - directement utilisable - et dans ce cas peu importe sa complexité et ou sa longueur.

Ce que je voulais donc dire c'est que ce débat sur la sécurisation des mots de passe pour les rendre difficiles à attaquer, n'a d'intérêt qu'à partir du moment où le mot de passe ne transite pas en clair, sinon une simple écoute du réseau (technique assez simple pour un pirate expérimenté) rend tout ça caduque

De toutes façons il y a un bug commun à tous les formulaires, c'est l'interface chaise-clavier.
Faut que je poste le bug ou ? Sur le bugtracker de mozilla, php ou de la w3c ?

Comme aurait dit Nagol pendant un temps : « stoi le bug »

squi qui pepcak?

en fait il faudrait une sorte de langage de script qui serait capable de faire du md5 et qui soit côté serveur, ça réglerait tout ça non?

On appelle ça le PHP Et ça ne règlerait rien puisque le problème de départ est la qualité du mot de passe mesurée selon sa complexité. Ajoutons à ça le problème de la transmission en clair sur le réseau de ce même mot de passe entre client et serveur faute d'une connexion SSL et la porte est ouverte au piratage... ou à l'usurpation d'identité selon l'usage que le pirate fera de ce qu'il aura récupéré.

Bon alors sinon on enleve les passwords, ca règle pleins de choses ça aussi!