Discussion :

[StringBuilder]

Bonjour,

J'ai pas fait de site web depuis très longtemps.

Je suis en train de m'y remettre, et j'ai choisi PHP comme langage pour m'autoformer.
Ce que je cherche est cependant plus généraliste : je cherche avant tout une méthode fiable et sécurisée pour authentifier mon utilisateur.

J'ai donc créé un formulaire d'inscription, qui stocke dans la base de données un hash du mot de passe :

Code php :

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

1
2
3
4
5
6
7
8
 
$name = $_POST['name'];
$login = $_POST['login'];
$password = $_POST['password'];
$cost = 10;
$salt = strtr(base64_encode(mcrypt_create_iv(16, MCRYPT_DEV_URANDOM)), '+', '.');
$salt = sprintf("$2y$%02d$", $cost) . $salt;
$hash = crypt($password, $salt);

Maintenant, arrive le moment où l'utilisateur saisi dans un formulaire son login/password pour s'authentifier.

En soit, pas de problème.
Mais ce que je cherche ensuite à faire, c'est de faire en sorte que l'utilisateur reste authentifié sans pour autant utiliser de session.

En effet, il fut une lointaine époque où j'ai usé et abusé des variables de session, et j'ai rapidement compris que leur existence n'était d'une hérésie :
- en termes de performances : objets persistants en mémoire détruits de façon peu fiable
- en termes de sécurité : quelques backspace bien sentis et on peut aisément mettre à mal un code mal goupillé et se faire passer pour ce qu'on n'est pas
- en termes de lisibilité du code (et donc maintenance) : on sait jamais trop quand une variable de session est utilisable ou non

Du coup, jusqu'à présent, je stockais un cookie de session (cookie sans date de fin, détruit au moment de la fermeture du navigateur) qui contenant uniquement login/mot de passe, et à chaque page je vérifiais les autorisations de l'utilisateur.

Mais ça c'était valable à l'époque où le mot de passe n'était pas crypté en base :
- le coût de l'encryption est trop élevé pour se le permettre à chaque chargement de page
- quel est l'intérêt de crypter le mot de passe dans la base (à priori sécurisée) si on ne le crypte pas dans la trame HTTP (je n'utilise pas de SSL)

Du coup je patauge un peu.

Quelle solution élégante permettrait de gérer ça proprement ?

Voici quelques solutions qui me sont venues en tête :
- Calculer un hash simple du login/passe et les utiliser dans le cookie : comme ça pas de mot de passe en claire, mais pas d'encryption lourde à chaque page
- Générer une clé (GUID par exemple) aléatoire du moment de d'authentification et l'utiliser dans le cookie par la suite jusqu'à la prochaine connexion (c'est à peu près le système du sessionid)
- Utiliser côté client un système à clé multiple avec authentification en plusieurs étapes. C'est à dire pour chaque utilisateur, créer une matrice de nombre en fonction du login/passe, et la générer aussi à la volée côté client. Ensuite, à chaque chargement de page, faire en sorte de le serveur demande patte blanche en demandant une valeur de la matrice. Ça me semble un peu lourd, puisque ça demande deux échanges avec le serveur pour chaque chargement de page... Pourtant ça évite qu'un petit malin qui récupère une unique trame HTTP puisse percer la sécurité du site (sauf s'il tombe au bon moment, quand on échange le login/pass).

Une autre idée ?

[Spartacusply]

En effet, il fut une lointaine époque où j'ai usé et abusé des variables de session, et j'ai rapidement compris que leur existence n'était d'une hérésie :

- en termes de performances : objets persistants en mémoire détruits de façon peu fiable

Deux lignes (grand max) suffisent pour détruire n'importe quoi de manière certaine stockée en session.

- en termes de sécurité : quelques backspace bien sentis et on peut aisément mettre à mal un code mal goupillé et se faire passer pour ce qu'on n'est pas

Les variables de session étant stockées côté serveur, elles sont beaucoup plus difficilement manipulables (donc plus sécurisée) que les cookies par exemple, qui eux sont stockés côtés clients.

- en termes de lisibilité du code (et donc maintenance) : on sait jamais trop quand une variable de session est utilisable ou non

Une variable de session est utilisable à partir du moment où elle a été créé et ce jusqu'à la fermeture du navigateur.

Bref, si tu souhaites authentifier de manière sûre ton utilisateur et ce jusqu'à la fermeture du navigateur, l'utilisation d'un flag stocké en session reste la meilleure solution. Si tu souhaites authentifier ton utilisateur au delà de la fermeture du navigateur, c'est là qu'il va falloir te pencher vers d'autres solutions (comme un cookie crypté par exemple, ce qui est à peu près ta première idée).

[ABCIWEB]

Salut,

Comme Spartacusply, je ne trouve pas que ton système soit plus sécurisé que si tu utilisais une session. Au contraire au lieu de n'exposer que l'identifiant de session dans ton cookie, tu expose plus de variables sensibles.

Sinon en absence de ssl, pour éviter que les mots de passe soient transmis en clair lors de l'authentification, tu peux hasher le post côté client, un exemple ici

[Tsilefy]

Bonjour,

Bonjour

Ce que je cherche est cependant plus généraliste : je cherche avant tout une méthode fiable et sécurisée pour authentifier mon utilisateur.

La seule méthode sécurisée (et encore...) c'est l'authentification par 2 facteurs. Autrement, on essaie de faire du mieux qu'on peut.

Code php :

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

1
2
3
4
5
 
$cost = 10;
$salt = strtr(base64_encode(mcrypt_create_iv(16, MCRYPT_DEV_URANDOM)), '+', '.');
$salt = sprintf("$2y$%02d$", $cost) . $salt;
$hash = crypt($password, $salt);

Pourquoi ne pas utiliser directement password_hash(), qui fait tout ça automatiquement, ce qui réduit les possibilités d'erreurs?

En effet, il fut une lointaine époque où j'ai usé et abusé des variables de session, et j'ai rapidement compris que leur existence n'était d'une hérésie :
- en termes de performances : objets persistants en mémoire détruits de façon peu fiable
- en termes de sécurité : quelques backspace bien sentis et on peut aisément mettre à mal un code mal goupillé et se faire passer pour ce qu'on n'est pas
- en termes de lisibilité du code (et donc maintenance) : on sait jamais trop quand une variable de session est utilisable ou non

Là j'avoue que je suis perdu. Peux-tu donner des exemples de chacun de ces cas? À ma connaissance, on peut décider de la durée de vie des sessions, de leur emplacement (pour ne pas les mettre dans un répertoire accessible à tous par exemple, ou les mettre dans une base de données ou dans redis etc...), toutes les saisies utilisateurs doivent être échappées correctement, et en utilisant une bibliothèque comme symfony/httpfoundation (ou d'autres), on peut parfaitement tester l'existence d'une variable de session. Si le code est robuste, le risque le plus sérieux pour les sessions est le vol de l'identifiant stocké dans un cookie. Le cookie est l'élément le plus vulnérable dans la chaîne. Si pour une raison ou pour une autre ton code ne peut pas être suffisamment robuste (ex hébergement sur un mutualisé), dans ce cas oui il y a un problème. Dans tous les cas, il semble que tu te focalises sur la sécurité côté serveur, alors que la sécurité côté client est tout aussi importante.

(je n'utilise pas de SSL)

Et malheureusement, il n'y a pas de sécurité sans SSL. N'importe qui peut voler le cookie de ton visiteur. Malheureusement, je ne vois pas de bonne solution à ton problème. La moins mauvaise c'est tout de même d'utiliser les sessions, puis de stocker l'identifiant dans un cookie (ou dans l'URL, même si cela ne se fait plus).

- Calculer un hash simple du login/passe et les utiliser dans le cookie : comme ça pas de mot de passe en claire, mais pas d'encryption lourde à chaque page

Qui dit hash simple dit facile à casser. La solidité de ta sécurité dépend de la sécurité de ton maillon le plus faible.

- Générer une clé (GUID par exemple) aléatoire du moment de d'authentification et l'utiliser dans le cookie par la suite jusqu'à la prochaine connexion (c'est à peu près le système du sessionid)

Oui, tu réinventes la roue, sans compter qu'il faut vraiment garantir que la génération est réellement aléatoire (ce qui est extrêmement difficile).

- Utiliser côté client un système à clé multiple avec authentification en plusieurs étapes. C'est à dire pour chaque utilisateur, créer une matrice de nombre en fonction du login/passe, et la générer aussi à la volée côté client. Ensuite, à chaque chargement de page, faire en sorte de le serveur demande patte blanche en demandant une valeur de la matrice. Ça me semble un peu lourd, puisque ça demande deux échanges avec le serveur pour chaque chargement de page... Pourtant ça évite qu'un petit malin qui récupère une unique trame HTTP puisse percer la sécurité du site (sauf s'il tombe au bon moment, quand on échange le login/pass).

Je n'ai pas vraiment compris, mais le petit malin ne récupérera pas qu'une trame, il enregistrera toute la session de navigation.

Une autre idée ?

Rien ne remplace les sessions + SSL. Même si tu arrives à développer un système sans faille mais sans SSL, rien n'empêchera le petit malin d'attirer ton utilisateur sur une fausse page pour saisir son mot de passe (ou de capturer son mot de passe sur un wifi public, etc..).

Une solution (sans doute mauvaise, je n'y ai pas suffisamment réflechi et elle a sans doute des failles) consiste à implémenter l'authentification à 2 facteurs du pauvre: à chaque connexion, tu envoies un email contenant un code valable pour la session de navigation à ton utilisateur, et l'utilisateur doit la saisir pour poursuivre. Mais c'est lourd, et ça ne résouds pas ton problème de session. Mais depuis le temps qu'on utilise les sessions (c'est à dire depuis l'invention de http), s'il existait une meilleure alternative, ça se saurait.

[crozet.magenta]

puis de stocker l'identifiant dans un cookie (ou dans l'URL, même si cela ne se fait plus).

le sessionID dans l'URL c'est vraiment pas une bonne idée à mon avis.
combien de fois j'ai vu des gens qui s'échangent des URL (en public ou pas) avec le sessionID dedans.
pour le vol de session, y'a pas mieux.
Le cookie reste le meilleur moyen de gérer les sessions et à mon avis, les sessions sont le meilleur moyen de gérer l'authentification

[grunk]

En effet, il fut une lointaine époque où j'ai usé et abusé des variables de session, et j'ai rapidement compris que leur existence n'était d'une hérésie :
- en termes de performances : objets persistants en mémoire détruits de façon peu fiable
- en termes de sécurité : quelques backspace bien sentis et on peut aisément mettre à mal un code mal goupillé et se faire passer pour ce qu'on n'est pas
- en termes de lisibilité du code (et donc maintenance) : on sait jamais trop quand une variable de session est utilisable ou non

- Peu d'intérêt de persister tout tes objets en mémoire. Souvent il sont directement lié à une bdd , autant refaire 1 ou 2 requêtes à chaque page et qu'il soit à jour tout le temps.
- Des sessions sécurisées c'est tout à fait possible. les coupler avec une bdd est une solution permettant un contrôle très fin et sécurisé.

Bonjour,
Du coup, jusqu'à présent, je stockais un cookie de session (cookie sans date de fin, détruit au moment de la fermeture du navigateur) qui contenant uniquement login/mot de passe, et à chaque page je vérifiais les autorisations de l'utilisateur.

Jamais au grand jamais de mot de passe en clair ou pas dans un cookie

- Calculer un hash simple du login/passe et les utiliser dans le cookie : comme ça pas de mot de passe en claire, mais pas d'encryption lourde à chaque page

C'est cette solution qu'on utilise généralement pour effectuer un auto-login , mais derrière il faut quand même des sessions.

le sessionID dans l'URL c'est vraiment pas une bonne idée à mon avis.
combien de fois j'ai vu des gens qui s'échangent des URL (en public ou pas) avec le sessionID dedans.
pour le vol de session, y'a pas mieux.
Le cookie reste le meilleur moyen de gérer les sessions et à mon avis, les sessions sont le meilleur moyen de gérer l'authentification

Ici il est pas question de la façon d'utiliser les session (il est évident que le session id dans l'url est à bannir) mais si il doit ou non les utiliser.

[StringBuilder]

Deux lignes (grand max) suffisent pour détruire n'importe quoi de manière certaine stockée en session.

Encore faut-il que ces deux lignes soient appelées. La destruction "propre" des variables de session est donc un véritable cauchemar, car si l'utilisateur ne suis pas exactement la cinématique telle que prévue par le développeur, on se retrouve avec des variables de session à moitié remplies, et les risques d'erreur liées à ce contexte bancal sont très importants.

Les variables de session étant stockées côté serveur, elles sont beaucoup plus difficilement manipulables (donc plus sécurisée) que les cookies par exemple, qui eux sont stockés côtés clients.

Les sessions passent avant tout par un cookie "sessionid". Donc il suffit que dans ton navigateur tu forces la valeur du cookie sessionid, et tu peux te faire passer auprès du serveur pour ton voisin. C'est donc assez peu fiable.

Une variable de session est utilisable à partir du moment où elle a été créé et ce jusqu'à la fermeture du navigateur.

C'est bien ça le problème. Si un utilisateur est dans un wizard sur plusieurs écrans, qui alimentent des variables de session avant de faire l'enregistrement en base par exemple, si l'utilisateur décide de repartir dans un autre menu en plein mieux, on se retrouve avec des variables en mémoire inutile, et qui risquent de perturber d'autre traitements. Aussi, la variable n'est pas détruite au moment de la fermeture du navigateur, mais au moment de l'expiration de la variable. Et c'est là qu'on se trouve face à un léger problème de sécurité et de montée en charge : une personne arrive et envoie 1000 sessionid par seconde : elle sature la mémoire du serveur web en quelques secondes.

Bref, si tu souhaites authentifier de manière sûre ton utilisateur et ce jusqu'à la fermeture du navigateur, l'utilisation d'un flag stocké en session reste la meilleure solution. Si tu souhaites authentifier ton utilisateur au delà de la fermeture du navigateur, c'est là qu'il va falloir te pencher vers d'autres solutions (comme un cookie crypté par exemple, ce qui est à peu près ta première idée).

Je souhaite authentifier l'utilisateur seulement pendant la durée de sa "session" (jusqu'à ce qu'il ferme le navigateur). Donc cookie sans date d'expiration.
Seulement, un bête flag n'est pas suffisant, sinon, je vois pas l'intérêt de crypter les mots de passe en base, puisqu'un petit malin peut créer un cookie sur son navigateur pour faire croire qu'il est authentifié alors qu'il ne connaît même pas le mot de passe !

C'est donc là que je suis à la recherche de quelque chose de fiable pour stocker en cookie quelque chose qu'un petit malin ne peut pas inventer de façon triviale.

[StringBuilder]

Je me rend compte que le forum PHP n'était pas forcément le forum le plus adapté pour parler de session, dans la mesure où effectivement, PHP ne sait pas gérer les variables de session directement en mémoire (c'est moins performant, mais au moins effectivement, avant de saturer le disque, y'a de la marge).

Mais bon, la variable de session est une pratique que je n'aime pas. Cela déclenche sur le serveur des mécanismes lourds, que je trouve aussi inutiles que dangereux (c'est pas pour rien qu'aucun langage digne de ce nom n'utilise de variables globales : on doit toujours être sûr et certain d'où viennent les données, et ne pas risquer des problèmes de contexte qui se marchent sur les pieds, si l'utilisateur ouvre plusieurs onglets en même temps par exemple).

Je pense que je vais rester sur la solution d'un "sessionid" custo : un GUID généré à chaque connexion et stockée dans un cookie. Ensuite j'aurai juste à vérifier en base que ce GUID est bien valable et que l'IP correspond bien à la dernière utilisée par exemple. Sorti de l'IP, y'a pas autrechose qui permet d'identifier un navigateur de façon "fiable" ? En effet, par exemple au boulot on a 2 routeurs ADSL + 1 fibre. Et durant la navigation sur internet, on joue à la roulette à chaque page, donc 3 IP différentes utilisée en même temps pour naviguer sur un même site. Donc le test sur l'IP est insuffisant.
Cependant, le sessionid (que ce soit celui natif de PHP ou un custo) n'est pas suffisant. Qu'est-ce que je pourrai utiliser d'autre ?

[crozet.magenta]

Les sessions passent avant tout par un cookie "sessionid". Donc il suffit que dans ton navigateur tu forces la valeur du cookie sessionid, et tu peux te faire passer auprès du serveur pour ton voisin. C'est donc assez peu fiable.

Je pense que je vais rester sur la solution d'un "sessionid" custo : un GUID généré à chaque connexion et stockée dans un cookie

Quelle est la différence avec le session id ? il suffit de voler le cookie avec ton custom id et le probleme est le même, il y a bien un vol de "session"... de plus, la génération d'un session id doit être le plus aléatoire possible et il y a un risque que ta génération le soit moins que celle de PHP.
l'IP d'un utilisateur n'est pas un paramètre très fiable, il est très facile de la modifier via un proxy entre autres

comment comptes tu détruire dans ta BDD le GUID qui authentifie un utilisateur ?
si ton utilisateur se déconnecte le cookie sera détruit mais pas le GUID dans la BDD donc un autre utilisateur qui se connecte avec le même GUID sera authentifié vu que l'ID sera en base de donnee.

[Spartacusply]

Encore faut-il que ces deux lignes soient appelées. La destruction "propre" des variables de session est donc un véritable cauchemar, car si l'utilisateur ne suis pas exactement la cinématique telle que prévue par le développeur, on se retrouve avec des variables de session à moitié remplies, et les risques d'erreur liées à ce contexte bancal sont très importants.

Ce à quoi je te répondrais, que c'est que si ton utilisateur peut faire quelque chose que tu n'as pas prévu, et qu'il n'obtient pas une erreur 500, c'est que tu as foiré ton développement quelque part.

Les sessions passent avant tout par un cookie "sessionid". Donc il suffit que dans ton navigateur tu forces la valeur du cookie sessionid, et tu peux te faire passer auprès du serveur pour ton voisin. C'est donc assez peu fiable.

- Php propose de se protéger un minimum contre ce genre d'attaque (lien vers la doc, en particulier session.use_strict_mode et session.hash-function.
- Tsilefy à raison sur ce point, le SSL sera le seul moyen efficace pour éviter justement que ton voisin te choppe facilement ton identifiant de session.

C'est bien ça le problème. Si un utilisateur est dans un wizard sur plusieurs écrans, qui alimentent des variables de session avant de faire l'enregistrement en base par exemple, si l'utilisateur décide de repartir dans un autre menu en plein mieux, on se retrouve avec des variables en mémoire inutile, et qui risquent de perturber d'autre traitements. Aussi, la variable n'est pas détruite au moment de la fermeture du navigateur, mais au moment de l'expiration de la variable.

Déjà, tu commencent à aller loin et j'ai pas tout compris ("a variable n'est pas détruite au moment de la fermeture du navigateur, mais au moment de l'expiration de la variable." ??), mais il suffit de contrôler ce qu'il y a en session avant de faire quoi que ce soit, pour gérer des problèmes comme ça.

Et c'est là qu'on se trouve face à un léger problème de sécurité et de montée en charge : une personne arrive et envoie 1000 sessionid par seconde : elle sature la mémoire du serveur web en quelques secondes

Ben ça c'est pas nouveau comme problème, ça s'appelle le DDOS et c'est pas du tout lié aux sessionid puisque l'attaquant pourrait envoyer n'importe quoi qu'il pourrait te faire péter ton serveur.

Je souhaite authentifier l'utilisateur seulement pendant la durée de sa "session" (jusqu'à ce qu'il ferme le navigateur).

Ok

Donc cookie sans date d'expiration.

Non, variable de session, elles sont là pour ça !

Seulement, un bête flag n'est pas suffisant, sinon, je vois pas l'intérêt de crypter les mots de passe en base, puisqu'un petit malin peut créer un cookie sur son navigateur pour faire croire qu'il est authentifié alors qu'il ne connaît même pas le mot de passe !

J'ai jamais dit cookie mais session ! Stocké un mot de passe dans un cookie, même crypté, est une aberration niveau sécurité !

Je crois que tu tentes de réinventer la roue, qui plus est exactement la même mais en moins bien (parce que mine de rien les sessions sont un tantinet optimisée), au lieu de te baser sur l'existant et tenter de l'améliorer en augmentant sa sécurité (utilisation du SSL comme suggéré plus haut par exemple, ce qui devrais vraiment être mis en place en premier lieu sur ton site).

[ABCIWEB]

Les sessions passent avant tout par un cookie "sessionid". Donc il suffit que dans ton navigateur tu forces la valeur du cookie sessionid, et tu peux te faire passer auprès du serveur pour ton voisin. C'est donc assez peu fiable.

Oui mais encore faut-il pouvoir pirater le cookie, ce qui limite les possibilités. Et dans ce cas on ne peut profiter de l'authentification que durant la durée de vie de la session, ce qui est beaucoup moins dangereux que de pouvoir récupérer une valeur qui sera valable sans limite de temps. Dans un environnement non crypté la session est donc la meilleure solution, la moins pire.

Pour un environnement plus sécurisé il y a SSL. Tu devras en passer par là si tu veux rendre indéchiffrable les informations confidentielles qui passent sur le réseau. En même temps cela tombe bien c'est conçu pour ça

Entre ces deux niveaux de sécurité (session versus session+ssl), il n'y a rien de vraiment convaincant à ma connaissance.