Discussion :

[Invité]

Bonjour,

Je développe actuellement un cms et par conséquent un système de gestion d'utilisateur avec formulaire login/mot de passe (logique ).

J'utilise le même système pour gérer mon site web de présentation de ce cms.

Je me suis rendu compte aujourd'hui que quelqu'un avait eu accés à ma partie privé donc a soit contourner mon système de login, soit il a trouvé mon mot de passe.

Comment je gère mes utilisateurs:
Sur chaque page à accés restreint je fais un test pour vois si un utilisateur est loggué, si non il est redirigé sur la page de login.
Quand l'utilisateur submit le formulaire je cherche le username en base de données, si le mot de passe correspond avec l'utilisateur je mets en variable session le username et l'id de cet utilisateur.
Donc à chaque fois que l'utilisateur accède ensuite à une page je fais un check que le couple id/username existe bien en bdd, sinon retour à la case login.

Ma question est donc: selon vous est ce un bon système de login? Sinon je crois que je suis bon à changer de mot de passe .

Merci

[FirePrawn]

Bonjour,

Tu as vérifié dans ta base que ton mot de passe et/ou login n'avait pas changé ?
Ca pourrait venir d'une injection SQL.

[Invité]

Pas d'injection puisque je peux encore me loggué sur ma session.

De plus l'injection sql n'est normalement pas possible puisque je n'ai pas prévu de code php pour changer mon mot de passe.

[grunk]

Pas d'injection puisque je peux encore me loggué sur ma session.

De plus l'injection sql n'est normalement pas possible puisque je n'ai pas prévu de code php pour changer mon mot de passe.

Aucun rapport.

Il y'a risque d'injection à partir du moment où tu as communication avec la bdd et utilisation de variables modifiable par l'utilisateur. Donc un formulaire de login est par exemple sujet au injection.

Une injection ne consiste pas forcément en une modification de données , on peut l'utiliser pour outrepasser une identification sans pour autant changer les identifiants

[Invité]

C'est pas faux ^^

Mais normalement le fait d'utiliser pdo est censé bloquer les injections si je ne me trompe pas.

Pour clarifier la gestion username/password:
Mon mot de passe est un hash md5 de mon username + un salt + mon password.
Quand le formulaire est submit je récupère le user en fonction du username submité et ensuite je refais le hash en md5 et je le compare à celui récupéré depuis la bdd.

Donc normalement je ne vois pas où pourrait ce glissé une injection pour validé le formulaire. Sinon je veux bien qu'on m'explique comment

[grunk]

Mais normalement le fait d'utiliser pdo est censé bloquer les injections si je ne me trompe pas.

Si tu utilises des requêtes préparées , oui. Sinon ça protège rien du tout

[Invité]

J'utilise les bindParam en effet donc normalement je suis protégé.

Donc je suis bon pour changer de mot de passe si je comprend bien.

[ascito]

Une bonne solution est de mettre les connexions actives dans une table journal

tu as une table user ( idUtil , nom , email , mdp )

au log tu vérifie par exemple email et mdp => 0K

tu insères dans une table journal un token ( une clé unique ) que tu attributs à la session de l'utilisateur

par exemple

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
table journal ( $id ,  $idUtil , $token ,$date ,$action , $detail );
 
$id = autoincrement;
$idUtil = 122;
 
$time = md5(time());
$token = str_shuffle($token);
$token= time().'_'.$time;
 
$date = time();
 
$action = 'connexion';
$detail = 'quelques detail comme ip de la personne etc si tu veux faire des verifs suplémentaires, date et heure de connexion,etc';

Comme cela sur la session ,tu ne transit que le token et tu limite le risque d'usurpation de session, donc tu vérifie un token actif et non une paire (id,nom)

tu peu limiter la session active ( par exemple 1 heure ), avec le champs date :
si champs date du token > time() + 3600 ==> reset token : deconnexion

tu peu vérifier d'autre détails avec detail

le journal te permettra d'avoir un suivi de toutes les actions "critiques" effectuées sur le cms ( c vraiment important de le faire de mon point de vue )

[Invité]

Le système avec le token est une bonne idée, je vais y réfléchir. Par contre le fait de juste trimbaler le token implique de récupérer l'id de l'utilisateur depuis la bdd à chaque chargement de page vu que j'en ai besoin pour créer un objet utilisateur, au lieu de simplement le prendre depuis la variable session.

Après pour le suivi des actions j'ai une table activity ou je log une grande partie (si c'est pas la quasi totalité) des actions faites par les utilisateurs avec la date de l'action.

[ascito]

Tout dépend vraiment du niveau de sécurité que tu veux mettre, pour moi pas d'infos perso dans une session, donc comme tu le dit cela implique une connexion à la bdd pour créer l'obj user.

tu peux cela dit imaginer le mettre en cookies sur le poste du client ( bon je l'ai jamais fais), mais d'un autre coté comme tu vérifie un token unique et renouvelé à chaque connexion( créer au log login+mdp) et non une partie des données persos (souvent statiques) tu peu tout à fait transporter l'objet user sans presque jamais rendre possible l'usurpation.

En même temps avec le token, imagine que c'est toi qui te connecte, et en même temps une personne essai de se connecter soit avec ton login+mdp, soit avec ton token ( s'il a réussi a le sniffer), tu peux à ce moment le rejeter puisque le token ne correspond pas à l'ip de la machine qui à créer le token, et si tu pense que l'ip te ta machine peu changer régulièrement (cad pendant que le token est valide), tu reviens a la création d'un cookie sur la machine qui contient le numéro du token. Donc le mec se connecte, le token existe mais il n'a pas la copie sur son pc donc rejeté

enfin je pense que l'on peu pousser assez loin en sécurité avec ce système tout en gardant une notion de performance

[Invité]

En effet la question est de savoir le dosage entre sécurité et lourdeur, en sachant que mon cms est orienté sur un nombre d'utilisateur assez restreint.