Bonjour,

Je cherche à dire que si ma variable ne contient pas entre 8 et 16 caractères alors il faut inscrire un message d'erreur mais je n'y parviens pas.

Voici mon code :

		if (formSubscribe.password.length < 8 || 16) {
			var numberPass = document.getElementById('number_pass');
			numberPass.innerHTML = "<br>Votre mot de passe doit comporter entre 8 et 16 caractères";
			numberPass.style.color = "red";
		} else {
			return true;
		}

Merci à tous

Regarde bien ta condition je pense que tu peux trouver tout seul.

Ce que tu veux c'est 8 < password.length < 16 mais c'est pas ce que tu as écris.

Merci pour réponse

J'avais essayé ceci mais aucun résultat :

if (formSubscribe.password.length < 8 || > 16)

if (formSubscribe.password.length < 8 || formSubscribe.password.length > 16)

Où avais-je la tête ... Merci.

En revanche je ne comprends pas car ça ne fonctionne pas. Hors la ligne est bonne, les noms employés le sont également.

Ne te satisfais jamais d'un "ça ne fonctionne pas". Regarde la valeur de tes variables, regarde comment tes expressions sont évaluées. Tu as des outils de développement pour ça.

Bon, après, perso je préfère écrire ça

if ( !(8 < formSubscribe.password.length && formSubscribe.password.length < 16))

Merci pour ta réponse tabouretBleu

Non pas que je m'en contente car j'ai effectué pas mal de test avant de répondre bien sur

La encore ma variable comprend bien un nombre inférieur à 8 ou supérieur à 16 et aucun message n'intervient.

Hors formSubscribe est bien déclaré et utilisé dans d'autres conditions et password et bien l'id correspondant.

La réponse est la suivante :

[Log] <input type="password" name="password" id="password" maxlength="16"> (js.js, line 63)

C'est plus une magouille qu'une solution mais elle ne présente pas de désavantage ici si tu peux aussi tester la longueur minimale.

Pense à faire la même vérification côté serveur.

Par contre, juste entre nous, si j'étais un pirate je te remercierais de me donner une indication sur la longueur maximale des mots de passe et de la limiter à 16 caractères.

Personnellement, j'aime bien utiliser des phrases comme "mot de passe", qui sont plus faciles à retenir et plus difficiles à casser.

Si tu as peur qu'il y ait des collisions de hash dans les mots de passe, tu peux choisir un algorithme qui génère des chaînes plus longues.

N'oublie pas non-plus d'ajouter un grain de sel personnalisé aux mots de passe

Côté serveur la vérification est déjà définie mais en quoi c'est un problème de donner une indication sur la longueur maximal des mots de passe ?

Ils sont hachés déjà. Le grain de sel c'est prévu pour la suite sinon, merci pour tes conseils

De la même façon que les gens ont tendance à zoomer à fond quand ils ont un objectif physique sur leur appareil photo, ils ont tendance à choisir des mots de passe qui font tout au plus quelques caractères de plus ou de moins que le nombre de caractères autorisé, si la fourchette est trop étroite, car ils sont limités dans un sens ou dans l'autre et vont simplement corriger légèrement leur première tentative.

Ce genre d'information aide à optimiser des algorithmes d'attaque en commençant par exemple par tester alternativement les combinaisons pour 8, 16, 9, 15, 10, 14, etc. caractères, en plus d'autres optimisations courantes (utilisation de chiffres et de caractères spéciaux à la fin du mot de passe quand ils sont obligatoires, utilisation d'un dictionnaire, etc.)

-
Edité par tabouretBleu 24 mars 2017 à 16:36:41

Jamais de maximum (enfin, dans les faits il y a une limite de 128 caractères pour qu'on ne m’envoie pas des mots de passe arbitrairement longs), mais personne n'écrira un mot de passe aussi longs. Personnellement, je ne dépasse pas 64 et la plupart des gens n'auront pas besoin de plus de 32.

Pareil, certains sites t'imposent de ne pas utiliser d'espaces (!?), d'accents ou de caractères spéciaux, ce qui est doublement débile.

Quant au minimum, je préfère avertir que le mot de passe n'est pas sécurisé s'il a trop peu de caractères (les fameux petits niveaux de sécurité rouge orange vert)

Je mets aussi un bulle d'information en bas du formulaire "comment choisir un bon mot de passe" pointant vers une page qui sensibilise sur le fait de ne pas utiliser le même mot de passe pour plusieurs comptes, etc.

Je préfère informer plutôt que restreindre. Les mesures de restriction, même quand elles sont censées améliorer la sécurité, ne sont pas dans l'intérêt de l'utilisateur.

La plupart des gens forcés d'utiliser un caractère spécial font utiliser le signe @ suivi d'une suite de chiffres (genre 123) ou un point d'exclamation à la fin de la chaîne par exemple. C'est un bon paramètre d'optimisation aussi.

Ces infos vont me servir merci à toi

Je vais chercher comment mettre en place les niveaux de sécurité (vert, orange, rouge), une piste ?

Ce que je comprends moins en revanche, c'est d'indiquer le mini et le maxi car si on utilise un système de hash personne ne peut deviner puisque même moi je ne peux pas les lires en les récupérant, non ?

La technique utilisée est de tester tous les mots de passe possibles en les hachant un à un avec différents algorithmes de hachages et de comparer ces essais avec ta base de données de mots de passe.

Plus un "mot" est long, plus l'algorithme de hachage est récent, et plus le mot sera long à hacher. De plus, il y a davantage de combinaisons possibles de signes à essayer, et en proportion moins de chances de tomber sur des mots de passes véritablement utilisés, donc en général les mots longs sont peu rentables à essayer.

Pour aller plus vite il y a des dictionnaires et des règles de combinaisons de mots basés sur des règles psychologiques comme celles déjà évoquées qui permettent de tester moins de combinaisons possibles pour une efficacité équivalente à l'attaque bête et méchante. Et il y a  ce qu'on appelle des rainbow tables, qui sont des bases de données de mots de passe déjà hachés et qui sont aussi rapides à utiliser qu'une simple requête BDD.

Utiliser un grain de sel différent par utilisateur ne fait pas que rallonger le mot à calculer (ce qui est déjà pas mal), ça oblige à utiliser une attaque par dictionnaire ou par force brute en intégrant ton grain de sel, parce qu'une rainbow table ne contiendra pas le mot de passe utilisateur, mais le mot de passe + le grain de sel, or ce n'est pas ce qu'on cherche, et sera moins intéressant dans tous les cas car si deux personnes utilisent le même mot de passe, la combinaison mot de passe + sel est unique donc il n'y a pas d'effet domino quand tu trouves un mot de passe par cette méthode.

Enfin bref, je suis pas un expert en sécurité mais sachant que des gens comme Yahoo ont mit des années avant de détecter que quelqu'un avait eu accès à leur base de données d'utilisateurs, ça remet en tête qu'une attaque silencieuse peut faire plus de dégâts (espionnage, usurpation d'identité) qu'une attaque qui mets ton serveur à genoux tout de suite. Il ne faut pas repousser la sécurité à plus tard ou se dire que si tout fonctionne c'est que tout va bien.

Je te laisse regarder pour le niveau de sécurité, c'est arbitraire. C'est à toi de décider des critères que tu juges sécurisés. C'est bien de compter le nombre de caractères, mais si tu ne fais que ça tu vas diriger les personnes vers le premier nombre de caractères considéré comme sécurisé et tu auras toi-même introduit un biais. Il faut aussi tenir compte de la présence et de la proportion de caractères spéciaux, capitales, accents, chiffres, de vérifier si des caractères analogues se suivent ou s'ils sont alternés, de vérifier si le mot de passe contient le nom de l'utilisateur ou du site... ça peut être une fonction complexe à écrire.

-
Edité par tabouretBleu 24 mars 2017 à 23:51:09

Complexe oui mais sans forcément être expert en sécurité je pense que m'imposer un gros minimum sera une bonne chose.

Encore merci pour ces infos, discussion intéressante qui me sera très utile