Recherche:

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



Pas nécessairement.

Un petit pistolet n'est pas sur le même plan qu'un gros machin automatique qui tire...

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

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

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

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

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 ;

...

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



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

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

Bonjour,


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