Expression régulière (regex) pour tester le format d'un password

Version imprimable

25/02/2016, 11h37
steph68b

Expression régulière (regex) pour tester le format d'un password

Hello,

J'ai énormément de mal avec les regex, ça ne rentre pas dans ma logique (ou vice versa!), je n'y arrive pas, je n'arrive à rien en fait! :mur:

Quelqu'un pourrait-il me monter :hola:une regex permettant de tester le format d'un mot de passe correspondant aux critères suivant:
-> 6 caractères minimum (max = 10, pense suffisant non? d'autant plus que je vais aussi rajouter un salt, avant cryptage SHA512)
-> au moins 1 chiffre
-> au moins 1 majuscule
-> au moins un caractère spécial
(avec les annotations pour comprendre)

Expression que je pourrais ensuite coller dans une fonction renvoyant true/false.

Question subsidiaire: mes critères de password sont-ils assez bons pour vous, ou comment feriez-vous, vous?

Merci.
:ave:
25/02/2016, 12h35
SpaceFrog

pour moi ce n'est pas possible en une seule reg ...
25/02/2016, 12h51
steph68b

pas de solution alors? :(
25/02/2016, 13h07
steph68b
cela dit, s'il faut faire 4 tests imbriqués dans des if(...) else if(...) moi ça me va aussi, pas de souci.

Le tout étant de trouver les 4 règles des 4 test:

1.) pour les chiffres on aurait un truc du genre
Code:

1 2 reg = /[0-9]/; reg.exec(document.inscription.Passwd.value)
-> tu confirmes? :weird:

2.) pour les lettres maj/min on aurait un truc du genre
Code:

1 2 reg = /[a-zA-Z]/; reg.exec(document.inscription.Passwd.value)
-> tu confirmes? :weird:

3.) nb car min(6)/max(10)? 8O
4.) la présence de caractères spéciaux? 8O
-> formule générique possible?
OU
-> indique 1 par 1 ceux que l'on souhaite voir utilisé?

Mais si, mais si voyons! Tout est possible en RegExp!

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
function isValidPassword(password) {
    var charactersTypes = [
            '[A-Z]', // lettre majuscule
            '[0-9]', // chiffre
            '[^\\w]' // caractère non alphanumérique
        ]
    ;
 
    // On fabrique les différences séquences possible: chiffre-majuscule-caractère spécial, majuscule-caractère spécial-chiffre, ... (il y en a 6).
    var possibleSequences = [];
 
    for (var i = 0; i < charactersTypes.length; i++) {
        var possibleSequence = [charactersTypes[i]];
 
        for (var j = 0; j < charactersTypes.length; j++) {
            if (i === j) {
                continue;
            }
 
            possibleSequence.push(charactersTypes[j]);
        }
 
        possibleSequences.push(possibleSequence);
 
        var possibleSequence = [charactersTypes[i]];
 
        for (var j = charactersTypes.length - 1; j >= 0 ; j--) {
            if (i === j) {
                continue;
            }
 
            possibleSequence.push(charactersTypes[j]);
        }
 
        possibleSequences.push(possibleSequence);
    }
 
    // On crée une liste de pattern d'expression régulière vérifiant les différentes séquences.
    var patterns = [];
 
    for (var i = 0; i < possibleSequences.length; i++) {
        var possibleSequence = possibleSequences[i];
 
        // En ES6 (avec les "Littéraux de gabarits" cela donne:
        // + veut dire au moins 1
        // .* entre les différents caractères veut dire n'importe quel caractère 0 ou n fois.
        patterns.push(
            `${possibleSequence[0]}+.*${possibleSequence[1]}+.*${possibleSequence[2]}+`
        );
    }
 
    // On concatène les différentes séquence dans une seule et même expression régulière.
    // | veut dire "ou", ce qui veut dire qu'on va vérifier que le mot de passe vérifie une des séquences.
    var passwordCheck = new RegExp(patterns.join('|'));
 
    // Teste le mot de passe et renvoie true si il match, false sinon.
    return passwordCheck.test(password)
}
 
 
console.log(isValidPassword('abcde'));       // false
console.log(isValidPassword('abCde0'));      // false
console.log(isValidPassword('abCd@e'));      // false
console.log(isValidPassword('ab5de#0'));     // false
console.log(isValidPassword('abC@de0'));     // true
console.log(isValidPassword('a@bezC0ceaz')); // true

La manière programmatique, c'est pour comprendre ce qu'il se passe (l'algorithme peut certainement être bien amélioré!). En abrégé, ça donne:

Code:

1
2
3
function isValidPassword(password) {
    return /[A-Z]+.*[0-9]+.*[^\w]+|[A-Z]+.*[^\w]+.*[0-9]+|[0-9]+.*[A-Z]+.*[^\w]+|[0-9]+.*[^\w]+.*[A-Z]+|[^\w]+.*[A-Z]+.*[0-9]+|[^\w]+.*[0-9]+.*[A-Z]+/.test(password);
}

Après c'est surtout pour la beauté du geste. Pour un soucis de compréhension (et certainement de performance), je le ferais en plusieurs expressions régulières.

PS: je ne limiterais pas la taille maximale (en tout cas pas à 10).
PS2: j'ai triché, je n'ai pas vérifié la taille globale du password dans ma regexp (password.length >= 6).

25/02/2016, 16h18
steph68b

J'allais poster que j'avais trouvé un début de piste avec mon

Code:

var reg = /[a-z]+[A-Z]+[0-9]+/g;

.......... sauf qu'évidement, de cette manière là un mot débutant avec 1 maj/chiffre renverra false, même si tous les critères sont là......... mais pas dans le bon ordre!!

Je cherchais donc comment caser un 'ou' dans ma regexp............

MAIS à voir ta réponse, j'étais encore TRES loin du compte!!
Et j'en étais donc arrivé à vouloir faire une analyse syntaxique manuelle à la place!

Je vais jeter un oeil sur ton code, pour essayer de comprendre, merci.
25/02/2016, 16h25
steph68b

Ok, alors en fait, il faut donner manuellement toutes les combinaisons possibles des 3 critères (maj, min, car spé), séparée à chaque fois par un "ou" (pipe)?
Ok, ok, ok, ok!!!

Aaaaaah la vache, je pensais les regex plus évoluées, pour éviter ça justement!! :koi:
Donc effectivement, je n'étais pas près de trouver!! :pastaper::lefou:

Oui, les regexp ne sont pas forcément adaptées à toutes les sortes de validations de chaîne de caractères. En revanche, on peut, la plupart du temps, décomposer en plusieurs expressions régulières pour y arriver. En l'occurrence, il suffirait de vérifier avec 3 expressions régulières chaque type de charactère que tu souhaites avoir:
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 function isValidPassword(password) { var charactersTypes = [ /[A-Z]/, /[0-9]/, /[^\w]/ ] ; for (var i = 0; i < charactersTypes.length; i++) { if (!charactersTypes[i].test(password)) { return false; } } return password.length >= 6; }
Ce qui simplifie pas mal le code, notamment pour la personne qui passe derrière toi!
A noter que ce code est plus évolutif car tu peux rajouter un nouveau type de caractère sans impliquer un changement de l'algorithme.

25/02/2016, 16h51
SpaceFrog

Autant passer par des indexOf, moins gourmand.
25/02/2016, 16h55
steph68b

C'est ce que pensais quand je parlais d'analyse syntaxique manuelle oui, mais d'un autre coté ça fait aussi un paquet de valeur à tester: 26 (min) + 26 (maj) + ?? (car. spé), donc je trouvais que niveau perf, CT aussi moyen.............

Sinon, ta regexp semble fonctionner, SAUF pour le '_' qui n'est pas considérer comme un car. spé. visiblement... à quel endroit faudrait-il me rajouter?

MAIS SURTOUT, votre avis de pro sur LA meilleur solution à prendre alors pour tester ce format de password?
-> regexp?
-> code complet?
-> indexof avec une liste explicite?

Que conseillerait la "bonne pratique"?
25/02/2016, 16h57
Gnuum

Citation:

Autant passer par des indexOf, moins gourmand.

J'aimerais bien voir ce genre de code avec des indexOf. Vu la quantité que ça nécessiterait, je ne suis pas sûr que ce soit plus performant. ^^
25/02/2016, 20h49
sekaijin

c'est super sympa de donner à tous les hackers les règles de tes mots de passe. ça leur permet de cibler leur attaque.

règle N°1 ne jamais assuré la sécurité par le code sur le poste du client
règle N°2 ne jamais exposer la moindre information qui permettrait à un hacker d'avoir une idée sur la sécurité.

Alors soit tu utilise javascript côté serveur et ta question est pertinente
Soit tu l'utilise côté client et tu donne à tous visiteur anonyme des informations vitale sur la sécurité de ton site.

Alors qu'une requête Ajax pour valider le mod de passe côté serveur et garanti que personne n'aura accès à tes règles de sécurité.

Reste le simple fait d'employer des règles.
une expérience universitaire Anglaise a démontré que les sites sans aucunes règles étaient ceux dans lesquels on trouvait les mots de passe les plus faibles mais aussi les plus fort.
elle a aussi montré que la présence de règles augmentait de façon significative le nombre de mots de passe craqués lors d'une attaque.
la raison est que lorsque l'attaquant parvient à déterminer une partie des règles il a accès à un grand nombre de mots de passes.

la conclusion était que pour assurer une meilleure sécurité il convient de ne pas mettre de règles mais une politique d'auto hacking pour éliminer les mots de passes trop faibles.

si ton code est coté javascript ta solution est la pire. car la plus grosse difficulté est de déterminer les règles sur les mots de passe. et toi tu les donnes en exposant ton code js à tous les anonymes qui visite ton site. reste le plus simple générer des mots de passe conformes au règles.

A+JYT

Essaies ça

Code:

1
2
3
4
5
6
7
8
9
10
11
 
 
/^(?=.*?[A-Z])(?=(.*[a-z]){1,})(?=(.*[\d]){1,})(?=(.*[\W]){1,})(?!.*\s).{5,8}$/g.test(monmotdepasse)
 
//Au moins une majuscule
//Au moins une letttre 
//au moins un chiffre 
// pas d'espace apres
// et suivi de 5 a 8 caracteres 
 
//ce qui fait 6 a 9 carecteres en tout

26/02/2016, 17h48
steph68b

Ok, mais au final, ne vaut-il effectivement pas mieux ne pas indiquer de critères utilisateurs, mais "salter" sévèrement le pass donné par le user? :koi:

Soudainement, un doute m'habite... :yaisse3:
26/02/2016, 18h22
sekaijin

surtout ça exclus des mots de passe très robustes

"Le monde a spécialement été terraformé en un parc de villégiature pour loger les visiteurs de la Coupe Murray"

voila le genre de "mot" de passe que produit l'imagination humaine lorsque il n'y a pas de règles.
facile à retenir et impossible où presque à craquer.

je crois que la plus part des gens serait étonné par les mots de passe que choisissent ceux qui attachent une importance à la sécurité.

A+JYT
26/02/2016, 19h08
Invité

Citation:

Envoyé par sekaijin

je crois que la plus part des gens serait étonné par les mots de passe que choisissent ceux qui attachent une importance à la sécurité.

:plusser:

La plupart se borne(nt) à "0000" ou "1234" :lol:

Mais ceux qui, effectivement, sont conscients de l'importance de protéger leur données, souhaitent "mieux" ;)
26/02/2016, 19h11
steph68b

Oui mais bon, s'il faut passer le champs de la base en TEXT pour les passwords, ça fait lourd ;)
Pense que 30 caractères c'est déjà pas mal............ sachant que les 3/4 ne dépasse même pas 6 ou 8.......... :weird:
26/02/2016, 19h15
Invité
Actuellement, 12 caractères semble être un "bon" critère.

Pour le cryptage en PHP, voir :
- password_hash()
- password_verify()
N.B. Pour info : en base de données, on ne stocke QUE le mot de passe CRYPTE.

Mais compte tenu de la mode "tout connecté" et "tout domotique", un bon hackeur finira par rentrer chez toi sans avoir besoin de fracturer la porte ou la fenêtre...
Et pour récupérer l'assurance: zéro.
Bienvenu dans le monde cybernétique...

Un bon verrou (mécanique) et une batte de baseball : y'a que ça de vrai... ;)

Plus sérieusement, comme le dit sekaijin, "tester" le mot de passe en JavaScript (interceptable facilement) n'est pas une bonne idée...
La longueur, à la rigueur... (xx caractères mini)
26/02/2016, 19h32
Invité

Une astuce (?) :

Passer en Ajax pour vérifier dans un fichier PHP appelé (renvoyant uniquement true/false) la validité du mot de passe.
Encore faut-il protéger ce fichier PHP d'un accès direct...
26/02/2016, 19h33
Gnuum

C'est sûr qu'un bon salt sur une base de données séparée (voire d'un type différent, un dictionnaire type REDIS par exemple) avec un petit cryptage et tu es plus sécurisé que 95% des applications. Si c'est du web, pense à faire du HTTPS pour éviter les risques d'interception.
26/02/2016, 19h54
steph68b

... sachant que le zéro risque et 100% safe n'existe pas: coté serveur ou coté client, si on veut on peut!

ce à quoi je pensais au final:
-> juste restreindre à disons 20 car (min 6) le pass saisi par le user
-> rajouter un bon préfix+suffix en salt
-> reste à savoir où stocker le salt:

* une $variable dans un fichier .php stocké hors www?
* en bdd, mais il transitera aussi?

HTTPS: j'y avais pensé oui, mais ne me suis pas encore penché sur la question, comment faire, etc...

password pas en clair en base: aaaaaaaaaaaaaaah bon????? naaaaaaaaaaaaaaaan!!! on m'aurait menti?????
:mouarf3::mouarf2::mouarf1:
26/02/2016, 20h27
sekaijin

non côté client ou côté serveur ce n'est pas du tout pareil

je vais caricaturer avec des règles débile
^[AB][a-z]{2}$
bref soit A soit B suivit de deux caractères.

avec une règle aussi débile pour attaquer le système qui n'expose rien (tout côté serveur) le hacker part sans aucune connaissance il va donc passer du temps à chercher de mots de passe hors de la règle.

si maintenant je mets ça dans le code js côté client
le hacker lit la règle ^[AB][a-z]{2}$ dans le fichier js.
il sait donc qu'il a 2 X 26 X 26 possibilités il peut donc se concentrer sur celles-ci.

Il y a là une sacré différence.

si tu choisis d'utiliser un logiciel de hack pour valider tes mots de passe. tu va éliminer les mots de passe trop faibles sans pour autant réduire drastiquement le champs des possibles.

si tu fais un appel ajax pour valider le mots de passe il faut que cette url soit libre et tu ouvre donc une porte pour faciliter les attaques.

alors que si tu ne vérifie rien avant l'envoi du formulaire tu peux valider le mot de passe avec une formule connue que du serveur (dico de hack min max par exemple) et quelque soit la raison pour laquelle tu invalide le mot de passe (les deux saisie différentes, trop faible trop court trop long etc.) tu retourne simplement "mot de passe incorrect"

L'utilisateur sera contraint d'en saisir un autre mais tu ne lui dit pas pourquoi. ainsi tu ne le dit pas non plus à un hacker.

et pour arranger la sauce tu peux dès le début avertir ton utilisateur
"Veillez à choisir un mot de passe robuste, vous n'avez droit qu'à 3 tentatives et par mesure de sécurité aucune information ne vous sera fourni en cas d'échec !"

etc.

bref la solution qui consiste à donner au hacker les règles d'écriture des mots de passe est la pire de toutes.

A+JYT
26/02/2016, 21h47
mathspountz

Bonjour à tous,

Je suis un peu hors sujet, mais pourquoi conseillez-vous de stocker le salt et le hash du mot de passe dans deux endroits différents ?

Bien à vous,
27/02/2016, 09h12
Gnuum

Si tu te fais hacker ta base de données utilisateurs et que l'attaquant récupère les mots de passe cryptés + le salt, il peut retrouver l'algorithme de cryptage en faisant du brute force (en gros je concatène salt + azerty) et je teste différents algorithmes jusqu'à ce que j'arrive à décoder un des mots de passe. Ensuite, je peux appliquer la méthode sur les autres pour essayer de les décoder.

C'est là que la dureté intrinsèque du mot de passe entre en jeu. Il est beaucoup plus difficile d'arriver à décoder chaque mot de passe même en ayant le salt (car on utilise la brute force) et plus le mot de passe est compliqué, plus il faut tester de combinaisons. On peut également remarquer que la façon dont est concaténé le salt peut en lui même être une sécurité car l'attaquant a peu de chance de déterminer cette liaison (sauf s'il vole le code en même temps que la base!) si elle est non habituelle (e.g. '@15465' + salt + '#F87pez' + password).

Enfin, si le salt est stocké sur une autre base de données, il faut que l'attaquant arrive à voler les 2 bases de données pour avoir une chance de reconstituer les mots de passe. C'est un peu plus compliqué à mettre en place, c'est sûr. Mais si tu fais le reste c'est déjà bien.

Pour revenir, sur les suggestions de non divigulgation des règles de mot de passe et de vérification AJAX, je me permets de faire remarquer que cela ne sert à rien. Tester le format du mot de passe côté serveur plutôt juste du client est une nécessité car on ne peut se contenter de vérifier un input côté client (javascript du formulaire facilement falsifiable). En revanche, faire une requête AJAX pour cacher les règles n'a aucun intérêt puisqu'on sera bien obligé de me les rappeler si je mets un mot de passe avec un mauvais format de toute façon!
29/02/2016, 19h23
steph68b

Débat très intéressant dites-donc, je ne pensais vraiment pas à certaines choses, au départ... ;)

Par contre, quid de la solution avec une $variable dans un fichier .php stocké hors www?
-> le serveur web, lui, peut y accéder
-> en principe un user lambda non, puisque tu ne peux pas entrer 1 url "hors web", à priori, non?
01/03/2016, 09h52
Gnuum

Citation:

Par contre, quid de la solution avec une $variable dans un fichier .php stocké hors www?

Je ne comprends pas très bien ce que tu veux dire exactement mais, en PHP, une variable ne stocke une valeur que le temps où le script qui l'a produite s'exécute (i.e. une requête). Je ne vois pas trop ce que tu veux/peux en faire donc.

Citation:

-> le serveur web, lui, peut y accéder
-> en principe un user lambda non, puisque tu ne peux pas entrer 1 url "hors web", à priori, non?

Si un utilisateur ne peut accéder à un fichier .php (potentiellement interprété), cela veut dire que le serveur web non plus.
En revanche, un fichier PHP qui n'est pas rendu accessible par le serveur web peut l'être indirectement s'il est inclus par un autre fichier qui lui est rendu accessible par le serveur web.
01/03/2016, 18h59
steph68b
Oui voilà, il me semblait avoir lu un truc comme ça, une fois, dans un bouquin:

toto.php

Code:

require($pathhorsweb+"safe.php");

safe.php
Code:

1 2 3 4 $host = "......"; $user = "..........."; $pass = "............."; $bdd = "..........";
par exemple pour la chaine de connexion à la DB

ou par extension

Code:

define("SALT", "....................");
02/03/2016, 10h01
Gnuum

La différence entre ta chaîne de connexion à la base de données et ton salt, c'est que c'est mieux que ton salt soit unique par utilisateur (pour maximiser la difficulté de décodage pour chaque utilisateur). De plus, ce n'est pas évident de stocker sa chaîne de connexion à la base de données dans la base de données.. ;)
En revanche, comme je disais, ajouter une sorte de "double salt" via une concaténation complexe dans ton code peut être une sécurité supplémentaire.
02/03/2016, 18h11
steph68b

Ok, donc le principe du fichier hors web, utilisé comme ça, n'est pas bidon alors! Cool, faut que je teste ça!

De mémoire, dans le bouquin, pour les data sensibles de ce style, y avait aussi:
-> le php.ini
-> des variables d'environnement
07/03/2016, 15h34
steph68b

laquelle des 3 méthodes serait la plus safe, pour vous? 8-)
09/03/2016, 14h55
steph68b

Pas d'avis sur la question? :chin:
11/03/2016, 14h59
steph68b

Bon, ben tant pis.