Journal Les macarons, pour remplacer les cookies

Posté par (page perso) . Licence CC by-sa
21
19
mai
2014

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).

  • # Corrections

    Posté par (page perso) . É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 (page perso) . Évalué à 2.

      Damned, j'avais donc cafouillationné par négligence excessive et paresse ? Merci au chaton pour la correction.

      • [^] # Re: Corrections

        Posté par (page perso) . Évalué à 4.

        Il y a avait un http:// de trop, ce qui faisait http://http:// et qui était interpréter comme une adresse sur http://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 . Évalué à 8. Dernière modification le 19/05/14 à 13:10.

    Un macaron ça ressemble à ça sous forme lisible par un humain:

    location http://mybank/
    identifier we used our secret key
    cid account = 3735928559
    cid time < 2015-01-01T00:00
    cid email = alice@example.org
    signature e42bbb02a9a5a303483cb6295c497ae51ad1d5cb10003cbe548d907e7e62f5e4

    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 . É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 . É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.

  • # Problème complexe

    Posté par . É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 à ceux qui les ont postés. Nous n'en sommes pas responsables.