Aujourd'hui, sur le Web, l'authentification de chaque requête HTTP, une fois passée le "login" initial, se fait presque toujours avec un cookie, une série de bits générée par le serveur et qu'un éventuel attaquant ne pourrait pas deviner. Les cookies ont plusieurs limites, notamment parce qu'ils sont tout ou rien. Si je passe un cookie à un tiers (volontairement ou bien parce que la session n'était pas bien protégée), ce tiers a exactement les mêmes droits que moi. Des chercheurs ont mis au point un système qui est normalement plus souple et permet des politiques de sécurité plus variées : les macarons (non, rien à voir avec ceux de Laurent Chemla).
Journal Les macarons, pour remplacer les cookies
19
mai
2014
# Corrections
Posté par claudex . Évalué à 4.
J'ai corrigé les deux lien qui ne fonctionnaient pas.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Corrections
Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) . Évalué à 2.
Damned, j'avais donc cafouillationné par négligence excessive et paresse ? Merci au chaton pour la correction.
[^] # Re: Corrections
Posté par claudex . Évalué à 4.
Il y a avait un
http://de trop, ce qui faisaithttp://http://et qui était interpréter comme une adresse surhttp://http.com.« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
# Je résume ce que j'ai compris
Posté par ziliss . Évalué à 8. Dernière modification le 19 mai 2014 à 13:10.
Un macaron ça ressemble à ça sous forme lisible par un humain:
Sous forme sérialisée, ça ressemble à une longue chaine ASCII (base64 ?) pseudo-aléatoire.
Dans cet exemple, le macaron permet à l'utilisateur alice@example.org d'accéder au compte 3735928559 sur le site http://mybank/ jusqu'à fin 2014.
C'est donc un ensemble de propriétés avec une signature qui permet de valider ces propriétés. L'algorithme de signature (chained HMAC) permet de rajouter des propriétés, mais pas d'en enlever, ni de les modifier. Cela permet de déléguer des droits restreints à une autre personne en lui passant un macaron modifié.
Alors si j'ai bien compris, c'est sensé remplacer les cookies, mais en fait ce sera quand même stocké dans des cookies… :)
Bon c'est plus puissant que les cookies d'authentification qu'on utilise actuellement et qui contiennent une suite de caractères aléatoires connue seulement du serveur.
Par exemple j'imagine que si on ajoute une propriété adresse IP au macaron, ça peut limiter les risques de fuite d'authentification de la session en cours.
[^] # Re: Je résume ce que j'ai compris
Posté par Yth (Mastodon) . Évalué à 8.
Mais ton cookie classique peut très bien être lié à une adresse IP sur ton serveur, et le serveur n'accepter ce cookie là que depuis l'adresse IP auquel il est lié.
Et l'avantage c'est que cette adresse IP ne transite pas dans un macaron.
Parce que ton appli elle reçoit le cookie mais elle fait quand même son authentification à partir du cookie, il lui suffit de coupler l'authentification à l'adresse IP et victoire.
Yth…
[^] # Re: Je résume ce que j'ai compris
Posté par ziliss . Évalué à 1.
Oui, tout ce qu'un macaron fait peut être fait sur le serveur. Même la délégation: il suffirait que le client dise au serveur à qui il délègue quels droits, jusqu'à quand, etc.
Par contre avec le macaron, le serveur n'aurait plus besoin de stocker toutes ces informations lui-même, une fois la personne authentifiée. Les informations sont directement présentes dans le macaron. Le serveur vérifie la signature et sait que le macaron est valide.
[^] # Re: Je résume ce que j'ai compris
Posté par BohwaZ (site web personnel, Mastodon) . Évalué à 4.
En fait c'est un peu comme ce que fait déjà Ruby et qui est expliqué ici : https://00f.net/2011/01/19/thoughts-on-php-sessions/
Mais en plus évolué.
« Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)
# Problème complexe
Posté par kowalsky . Évalué à 4.
C'est un problème vieux comme les cookies.
Soit on prend un max de paramètres dans la session (User-Agent, IP src, id de session) soit on prend l'ID et pis c'est tout.
En cas "d'attaque" par vole de cookie, le coup de user agent, ça ne résiste pas, l'attaquant obtient souvent l'user agent en même temps que le cookie.
L'IP¨source, c'est trop contraignant pour l'utilisateur, si il est depuis un téléphone, l'ip change souvent, si il est en wifi pareil, etc.
Pour moi, le seul moyen d'être sur est d'identifier le client avec un challenge à la SSL ou le certificat assure de l'identité du client, à une différence prêt, il faudrait que cela authentifie chaque navigateur de façon unique.
J'ai l'impression que c'est ce que propose google , mais je ne suis pas sur du comment ils en arrivent à ce "certificat" client.
Donc pour palier à vrai problème des cookies on va créer un vrai problème de traçabilité des utilisateurs. Sauf si ce "certificat" est régénéré à chaque session.
Je veux dire par la que jusqu'ici, je peux supprimer mon cookie, et je recommence à zéro mon historique sur le net tant que je ne m'authentifie pas. Si je peux supprimer mon macaron, cool, pas de problème. Sinon, mon navigateur est lié "à vie" aux utilisateurs qui l'ont utilisé.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.