Discussion :

[Ethan 0x21]

Bonjour,


Je développement actuellement un site web qui doit également mettre a disposition de clients une API REST avec un systéme de signature digitale pour l'authentification.

Cependant pour la partie site internet, les pages ont également besoin d'accéder à l'API REST mais je vois pas trés bien comment le mécanisme de signature HMAC pourrais être implémenter en javascript (insécurisé, la clée secréte serai accessible a tout le monde), ainsi je me demande quel serait la meilleurs solution :

1 - Recoder une API uniquement pour l'usage interne au site.
2 - Utiliser l'API actuel en substituant juste la phase authentification avec signature HMAC, par le traditionnel LOGIN + MDP = SESSION PHP.

OU une autre s'il y a une solution plus optimisée.


En vous remerciant par avance

[Ethan 0x21]

Auto réponse,
Bien évidemment respecter le principe de non redondance du code, en adaptant au besoin la couche d'authentification d'accés à l'API : Trés sécurisé (HMAC, etc...) pour les accés externes, et moins (session PHP) pour les accés internes.

Merci quand même pour les réponses en mode "cat reponses > /dev/null 2>&1"

[Angelsafrania]

Tout d'abord désoler du déterrage.

Mais je me pose un peu la même question.
Je développe un site web. Mon API sera en full REST. Donc pas de session (enfin pas sur le serveur web peut être en BDD mais bon c'est plus trop une session).
Je ne pense pas faire comme le indiqué au dessus, c'est à dire un classique login mot de passe pour l'authentification avec une session.

Je pensais faire intégralement par signature.
Je hache le mot de passe en BDD avec un salt et le login pour l'enregistré dans la bdd. (pour avoir un hache qu'on peut pas deviner et des haches différent pour des utilisateurs ayant le même mot de passe).
Le salt est fixe et donnée à l'application web en claire (donc le hackeur peut le voir).
L'uri de ma requête est haché. Je concatène ce hache avec le mot de passe haché (donc avec le salt et le login) et je re-hache => ca me donne la signature.
Je transmet le login de l'utilisateur dans les header avec la signature.
Du coté du serveur je fais la même chose, avec le login de l'utilisateur je récupère le mot de passe haché, je calcule la signature et je compare.

Jusqu'à la c'est cool le mot de passe n'est jamais sur le réseau (enfin juste quand on l'enregistre donc une seule fois).
Le hash du mot de passe ne passe pas non plus sur le réseau il est modifié dans le hache de la signature.
Donc si on intercepte la requête on peut juste renvoyée la même. (sauf si on met un timestamp dans l'uri et qu'on contrôle celui-ci).

Mon problème c'est qu'on va devoir stocker le hash du mot de passe dans l'application web du client (en JS).
Est ce que c'est problématique ?
Je dirais que oui. Si on arrive a accéder au hash, c'est un peu comme si on avait le mot de passe. On fait ce qu'on veux sous l'identité de l'utilisateur.

Donc pour limité la casse. Je mettrais bien un token (un numéro de session quoi ). On enverrait pas le Hash du mot de passe mais un hash du hash du mot de passe et du token .
On stock ça au niveau font et on met un timeout au token niveau serveur.

Ca permet de limité la casse. Mais est ce que vous avez une solution qui permet de supprimé le risque ?

[thelvin]

Il n'y a pas de solution pour supprimer le risque. Quelqu'un peut venir physiquement s'installer à la chaise de l'utilisateur qui a commencé à naviguer sur ton site. À partir de là, il peut reproduire n'importe quel système d'authentification. Au moins, un token est révocable pour n'importe quelle raison, et ne donne pas d'info sur le secret maître qu'est le mot de passe.

Sur le principe, je trouve peu prudent de mêler le mot de passe à ton hachage. Le token est censé être un secret entre ton visiteur et toi (enfin, entre le navigateur de ton visiteur et toi), il n'y a pas besoin d'y mêler un secret encore plus important. Et on sait jamais ce qu'une erreur de codage pourrait révéler.