Discussion :

[Realc]

Bonjour,

Je souhaite utiliser des token d'authentification, après diverses recherches j'ai trouvé les token JWT et d'autres méthode de génération de token avec md5.

Hors pour diverse raisons je ne souhaite pas utiliser les token JWT et md5 me semble avoir mauvaise réputation.

De ce fait j'ai trouvé une méthode mais je souhaiterais votre avis :

Génération d'un chaîne d'octets : https://www.php.net/manual/fr/function.random-bytes.php
Puis je converti cela en Hexadécimal.
Enfin je concatène cela avec l'id de mon utilisateur et un salage.

J'envoie cela a mon application (android ou web) puis lors d'une requête a mon service je décode le token reçu, et je vais voir le token contenu a l'id caché dans le token.
Ainsi il est plus difficile de trouver le token par brut force ?

A noter que je souhaiterais par le futur rafraîchir ces token mais pour le moment il faudrait qu'i soit émis pour une durée indéterminée.

[fredoche]

tu codes/décodes juste de l’hexadécimal ?

je vois pas ou est la sécurité là ? peux-tu en dire plus ?

[Realc]

Je généré une suite de bits,soit une chaîne d'octets aléatoirement, puis comme ce sont des bits je converti cette chaîne généré aléatoirement en base 16 puis je concaténe l'id de mon utilisateur et une clé secrète, ainsi cela me donne un token unique.
La sécurité réside dans le fait qu'avec 128 bit c'est à dire 16 octets, il y a 3*10^38 combinaison possible, donc au final le token serait très difficile a trouvé par brut force par exemple

[fredoche]

La force brute est une chose, mais l'un des principes pour casser des protocoles de chiffrages, c'est de trouver des régularités. Avec des ordinateurs modernes, c'est à mon avis assez facile et rapide. Et c'est pas le fait de convertir en hexadécimal qui va augmenter la diificulté

Faire son propre protocole, je ne suis pas sur que ce soit une bonne idée, si on ne respecte pas beaucoup de règles qui font toute l'histoire des techniques de chiffrement.
C'est pour cela que des protocoles de chiffrages et de hachage de très haut niveau sont disponibles et en open-source. Ces protocoles représentent des décénnies de travail et de recherche sur le sujet

Pourquoi ne pas les utiliser ?

Pour ce qui est du jeton (token), il vaudrait mieux que tu suives la même recette pour la composition

Génération d'un chaîne d'octets : https://www.php.net/manual/fr/function.random-bytes.php
Puis je converti cela en Hexadécimal. ne sert à rien
Enfin je concatène cela avec l'id de mon utilisateur et un salage.

Puis tu fais un hashage avec un protocole de bon niveau (minimum SHA-256) que tu stockes coté serveur dans une session puisque tu fais du PHP, et que tu envoies à ton appli web ou android.

Le principe des hash est d'être irréversible, on ne peut pas retrouver les informations contenues dans le hash à partir du hash, à moins de disposer de dictionnaires de toutes les combinaisons.

Ensuite il suffit de comparer le jeton présenté par le client avec le le hash stocké coté service et session pour garantir que tu as la bonne personne en face.

[Realc]

Tout d'abord merci pour ton aide fredoche,

En ce qui concerne le l'encodage en base 16 j'avais vu cela sur le premier commentaire de cette page : https://www.php.net/manual/fr/function.random-bytes.php

(Question parallèle ) Aurais-tu des exemples de cryptographie open source, ou du moins pour en apprendre plus sur ce dont tu m'as parlé ?

Pour ta phrase :

Pour ce qui est du jeton (token), il vaudrait mieux que tu suives la même recette pour la composition

Tu veux dire que je fais cet algorithme :
-Génération d'une chaîne d'octets : https://www.php.net/manual/fr/function.random-bytes.php
-Concaténation avec l'id de mon utilisateur et un salage.
-Hachage de ce qu'il y a au dessus en sha-256
-Sauvegarde la clé dans la BDD.
?

Finalement l'utilisation de session me paraît évidant pour une web application, mais pour un application Android cela à un intérêt ?
Car j'avais pensé détecter le terminal utilisé afin d'utiliser les session ou non.

[fredoche]

ici tu as les références des algos des SHA :
https://csrc.nist.gov/publications/fips

et puis par exemple en PHP, c'est implémenté sous forme de fonctions :
https://www.php.net/manual/fr/function.hash.php

Tu veux dire que je fais cet algorithme :
-Génération d'une chaîne d'octets : https://www.php.net/manual/fr/function.random-bytes.php
-Concaténation avec l'id de mon utilisateur et un salage.
-Hachage de ce qu'il y a au dessus en sha-256
-Sauvegarde la clé dans la BDD.
?

Finalement l'utilisation de session me paraît évidant pour une web application, mais pour un application Android cela à un intérêt ?
Car j'avais pensé détecter le terminal utilisé afin d'utiliser les session ou non.

Oui tu sauvegardes où tu veux ensuite.
L'avantage d'une session c'est qu'elle est à durée limitée et que tu n'as pas à gérer cette durée, c'est géré par le moteur PHP dans le cas de PHP
Dans une BDD il suffit de reproduire cette notion de session et de limite

[Realc]

Merci pour les liens,

Par contre je vais devoir tout de même convertir la chaîne d'octets en hexadécimal d'après l'exemple ici : https://www.php.net/manual/fr/function.random-bytes.php
Pour éviter des problème de conversion au moment du hash.

Je dois envoyer quelle partie a mon client ?
Le token non hashé je suppose, mais il sera facile de voir que le token est composé d'une suite aléatoire, de l'id de mon utilisateur et d'un salage ? (ou j’envoie le hash ?)

[fredoche]

cela génère une chaine de caractères, la fonction de hash va te transformer ça en hexadécimal, pas de souci

Et non : tu envoies le hash à ton client, qui sert de token ou jeton-clé si tu préfères, à l'authentification. Celui-ci devra te le présenter à chaque connexion ou requête, et que tu compares avec le hash associé à l'ID, et stocké en session ou BDD. En cas de différence, tu sais qu'il y a tentative d'usurpation.

[Realc]

Merci fredoche pour ton aide !

Je vais faire ce que tu m'a conseillé.

Pour terminer est ce que je peut crée un service qui renvoi un nouveau token si on y accède depuis un token existant, afin d'appeler ce service a chaque lancement de l'application Android ? (pour rafraîchir le token du client)

Mais par ce moyen je pense qu'une personne malveillante ayant réussi a obtenir un token, peut s'amuser a en généré un nouveau depuis un navigateur sans que le token sur l'application sois mis à jour.

[fredoche]

Je ne comprends pas ce que tu demandes, ou je n'en suis pas sur.
Tu as toujours le risque qu'un jeton ou une clef soient compromis. Il faut t'en préserver au mieux. Donc ça veut dire en premier lieu des échanges sur un canal sécurisé (https par exemple).
Mais ce qui se passe sur la machine du client, navigateur ou android, tu ne le sais pas. Donc c'est un risque à prendre en compte

[Realc]

Je compte utiliser un canal HTTPS.

Je voulais dire :
Une session PHP expire au bout d'un certain temps, ainsi si je démarre une session pour un utilisateur, il faut qu'il effectue une action avant l'expiration de session.

Hors sur les application mobile comme leboncoin, facebook ou autre, lorsque nous relançons l'application 10 jours après notre connexion, nous sommes toujours connectés.

Mais s'ils utilisent des session alors je suppose que celles-ci doivent être expirées.

Ainsi je voudrais savoir si le token attribué a l'utilisateur doit être mis à jour, pour conserver la connexion ?

Schéma d'exemple :
Connexion -> token = 123
fermeture de l'application
lancement de l'application sans connexion au compte car détection d'un token existant -> mise a jour du token : token =456

En fait je voudrais transcrire le bouton se souvenir de moi de la version web, pour rester connecter sur l'application comme sur le site.

[Realc]

Excusez moi pour le double post mais il me semble avoir trouvé la solution.

Considérons que je génère un token, je le sauvegarde en base de donnée, je crée une session avec ce token et je l'envoi a mon client.

Puis ce même client tente d'accéder a un de mes services 48h plus tard avec son token sauvegardé en local (dans un cookie ou dans l'application).

Est ce qu'il est préférable de regarder si le token existe dans la session, et s'il n'existe pas de faire une requête en base pour redémarrer la session qui a expirée (par dépassement du temps) ?
Ou de toujours faire une requête vers la base de donnée pour savoir si le token existe (J'entends par cela de faire une requête a ma base pour savoir si le client est bien autorisé, avant de faire les requêtes du dit-service et sans utiliser de session).

La première solution me semble meilleure car elle ne fait une requête uniquement si la session est expirée.

La question est : Le serveur va "saturée" plus rapidement si l'on fait des requêtes multiples vers une base de donnée ou si l'on crée de multiple session ?

Disons que j'ai 1 000 000 d'utilisateur (pour exagéré) connectés simultanément, il font tous une requête a un de mes services au même moment, le serveur supportera mieux la montée en charge de 1 000 000 de comparaison avec les donnée de sessions PHP où de 1 000 000 requêtes a ma base de données ( suivi des requêtes pouvant être effectuées par le dit-service).