Bonjour,

je suis entrain de chercher méthode pour ne pas accepter un champ vide avec le bouton de clavier "espace" lors de l'inscription d'un membre en PHP,

je cherche une solution coté serveur sinon coté client j'ai deja la fonction keydown.

Voici la regex que j'ai utilisé mais ne marche pas

if(preg_match('@[^\w\s]@',$_POST['mdp'])) {

// do somthing
}else{
   $erreur['mdp5'] = "Votre mot de passe ne doit pas contenir un espace vide!";
}

Merci pour votre aide

-
Edité par CyranoDecasa 23 septembre 2021 à 11:29:27

Salut

Si je comprends bien, tu ne veux pas que quelqu'un s'inscrive avec uniquement un espace, mais tu le tolères s'il y a d'autres caractères ? Je pense que tu peux regarder du côté de la fonction trim() qui peut être un peu plus pratique. Tu traites le mot de passe et tu regardes si le résultat du traitement n'est pas vide.

Ymox a écrit:

Salut

Si je comprends bien, tu ne veux pas que quelqu'un s'inscrive avec uniquement un espace, mais tu le tolères s'il y a d'autres caractères ? Je pense que tu peux regarder du côté de la fonction trim() qui peut être un peu plus pratique. Tu traites le mot de passe et tu regardes si le résultat du traitement n'est pas vide.

Merci beaucoup Ymox, 

le lien que tu m as donné m'a vraiment servi pour supprimer les espaces en debut et fin par contre un espace au milieu du password je pense qu'il n y a pas de solution coté PHP.

je crois que c'est suffisant pour moi, Merci encore

Dans l'idéal, un mot de passe ne devrait pas avoir de caractères interdits, et devrait même pouvoir commencer et se terminer par autant d'espaces que souhaité, tant qu'il n'y a pas que des espaces, évidemment. Si certains caractères sont interdits à cause d'un souci de technologie ou d'implémentation (coucou la grosse boîte de sécurité qui tronquait silencieusement les mots de passe dès qu'il y avait un caractère bien précis dedans, même quand ledit mot de passe était généré par leurs soins avec ledit caractère), là on peut imaginer utiliser une regex en plus, ou alors trouver une méthode d'échappement qui permettrait d'éviter le problème.

Donc je me permets de préciser : je vois la chose comme utiliser trim() afin de voir si le résultat n'est pas vide, et si c'est le cas enregistrer le mot de passe tel qu'envoyé, sans que trim() l'ait traité. C'est à la fois plus sûr et plus respectueux du choix de l'utilisateur.

Non, mais, on est d'accord que sur TOUS les sites web du monde, quand on s'inscrit, notre mot de passe est scruté en clair ?

Pour savoir s'il y a des espaces ou quelques caractères que ce soient qui manquent : coucou le fameux : dans votre mot de passe il manque un caractère spéciale. Il faut que le mot de passe soit scruté en clair.

Pour infos, le site de Laposte te confirme ton inscription avec un : votre mot de passe est : motDePasseEnClair.

On parle de sécurité info depuis des années, mais, ça ne chagrine personne.

Pour moi, tout site devrait mettre un disclaimer sur le champs du mot de passe. Et donner quelques conseils mais ne pas les tester. C'est la responsabilité du nouvel utilisateur de choisir un mot de passe suffisamment robuste.

Cependant, j'oubliais, les sites stockent le mot de passe salé et haché, c'est bien, mais, pareil, pour lancer les fonctions idoines, il faut bien avoir le mot de passe en clair comme argument. Est-il possible de saler et hacher dans le navigateur Web côté client et non côté serveur ?

Le mot de passe tu l'envoies (reçois, côté serveur, devrais-je plutôt dire) en clair de toute façon. Mais aujourd'hui, quasiment tous les sites sont en https donc l'intercepter (MITM) est plus difficile.

> Est-il possible de saler et hacher dans le navigateur Web côté client et non côté serveur ?

Certainement, vbulletin le faisait (MD5 ?) mais ce n'est pas plus sécurisé (que le mot de passe soit en clair ou hashé, s'il est intercepté, tu peux le "rejouer" de la même manière) et ça implique de faire confiance au client pour la génération du hash. Ou alors il faudrait passer par des clés publiques/privées pour les parties client et serveur.

> Dans l'idéal, un mot de passe ne devrait pas avoir de caractères interdits

Je suis d'accord, d'ailleurs il y a beaucoup de sites dont ameli qui te cantonne à l'usage de l'ASCII non-étendu, ce que je trouve ridicule parce que :

1. ça facilite énormément les attaques car en limite fortement les possibilités/combinaisons en brute force
2. quel navigateur, aujourd'hui, ne supporte pas Unicode (UTF-8) - le jeu de caractères de la page quoi ? Je pense qu'au contraire, ce serait justement les robots qui tendraient à ne pas le respecter. Bon, ok, à certains égards, on pourrait notamment considérer que les caractères composables puissent être un problème.

C'est probablement pour ça qu'ils te bloquent ton compte au bout de 3 tentatives alors que tu n'y vas quasiment jamais et que tu oublies ton mot de passe d'une fois sur l'autre.

Bref, que l'on veuille interdire un ou des caractères dans un mot de passe, s'il y a une raison technique, d'accord. Sinon non. Mais vous le faites sous la forme d'une validation, JAMAIS par un traitement silencieux comme l'impliquerait l'usage de trim parce que sinon, votre pauvre client, il ne pourra pas utiliser son compte et ne comprendra pas pourquoi son mot de passe ne fonctionne pas.

> C'est la responsabilité du nouvel utilisateur de choisir un mot de passe suffisamment robuste.

Tant qu'on est dans le sujet, à l'inverse, ça me fait tout de même rire un peu jaune que sur des sites qui à tes yeux n'ont strictement aucune importance (le site perso de ton pote Michel ou le site du fabricant de tel produit où tu es obligé de t'inscrire pour accéder à une ressource, etc) on te force à utiliser un mot de passe inutilement fort.

-
Edité par julp 27 septembre 2021 à 0:48:27

Je reprochais un risque de vol de mot de passe par le site Web lui-même. Les sites doivent être énormément réglementés sinon c'est la foire. Ça implique une énorme confiance au tiers (le site) quand même. Et quand on sait que des très gros ont des fuites de données, je comprends les paranos.

Je prends pour exemple que WhatsApp (FB) peut déchiffrer les 5 derniers messages depuis un message signalé par un utilisateur. S'ils peuvent en déchiffrer 5, ils peuvent en déchiffrer N. S'ils peuvent en déchiffrer après signalement, ils peuvent en déchiffrer SANS signalement.

N'oublions pas que 99.99 % de la population est bienveillante mais la majorité d'entre elles n'a pas envie que les employés de FB ou autre sachent ce que j'écris ou non.

PS : je suis certains que chez Signal c'est pas mieux.