Re: [openplacos-dev] Re: foutus token

[flagos <flagospub@xxxxxxxxx>]

Mais encore lol ? tu n'as meme pas fait de bruit, en tous cas pas sur
ce thread :-)

Le 15 mars 2012 18:12, jay peche <jaypeche@xxxxxxxxx> a écrit :
>
>
> Le 31 janvier 2012 17:33, flagos <flagospub@xxxxxxxxx> a écrit :
>
>> Ca me choque beaucoup moins. C'est comparable au machin qui gueule
>> quand tu te connectes pour la premiere fois en ssh sur une machine: ca
>> gueule, tu met yes. Le jour ou la clé est périmée (format du serveur
>> par ex), ben tu cleanes ton know_hosts et zou.
>>
>> Le 31 janvier 2012 17:11, miaouf kirsh <miaoufkirsh@xxxxxxxxx> a écrit :
>> >> Qu'est ce qui empeche le client de ressortir son token ?
>> >
>> >
>> > j'aurais du préciser, "a chaque fois que le token expire ou est perdu"
>> >
>> > en fait le client secret permet de verifier que l'utilisateur a bien
>> > autorisé le client. (l'autorisation c'est la demande a l'utilisateur de
>> > valider les scopes)
>> > si on ne peut pas faire confiance au client, il faut demander une
>> > autorisation a chaque fois qu'on demande un token.
>> > si le token a une durée de vie infinie, et qu'il est sauvegardé par le
>> > client, alors il me semble que l'autorisation ne sera demandé qu'une
>> > seule
>> > fois
>> >
>> > Le 31 janvier 2012 16:25, flagos <flagospub@xxxxxxxxx> a écrit :
>> >
>> >> Oui non je reviens sur ma derniere considération: effectivement
>> >> quoiqu'il arrive, ca fait que le client_secret peut etre du coup
>> >> usurpé.
>> >>
>> >> Donc la seule piste qui reste est la génération a la volée, charge a
>> >> nous d'automatiser le bousin.
>> >>
>> >> Le 31 janvier 2012 16:16, flagos <flagospub@xxxxxxxxx> a écrit :
>> >> > Bon ben voila, ca repond super bien a la question. Le cas de
>> >> > differents instances d'un serveur d'authentification a été traitée
>> >> > dans la norme, et c'est la premiere solution (dans mon mail) qui est
>> >> > retenue.
>> >> >
>> >> > (Fais chier avec ces machins tout standard, on peut meme plus troller
>> >> > !)
>> >> >
>> >> > Donc en gros, on dédie une api rest a la recupération de tokens,
>> >> > charge a chaque client de se démerder pour stocker ses client_id et
>> >> > client_secret dans un endroit sur.
>> >> >
>> >> > en temps normal on a un truc du genre
>> >> > 1ere utilisation :
>> >> >  user : login
>> >> >  user : autorization du client
>> >> >  autorization ok, je balance un token
>> >> >
>> >> > utilisation ultérieure :
>> >> >  user : login (je suis pas sur)
>> >> >  le client_secret me dit que le client est deja autorisé pour cet
>> >> > utilisateur, je balance un token.
>> >> >
>> >> > comme le client_secret ne peut etre verifié, l'autorisation devra
>> >> > etre
>> >> > demandé a chaque fois, c'est pas terrible comme truc.
>> >> >
>> >> > Qu'est ce qui empeche le client de ressortir son token ?
>> >> >
>> >> > bon je ne commenterais pas ce passage.
>> >> >
>> >> > lol effectivement, c'est pas une bonne idée.
>> >> >
>> >> > En fait, il faudrait que, de la meme maniere qu'on peut
>> >> > l'authentification de l'utilisateur, opuvoir déporter
>> >> > l'authentification du client avec ses client_id et client_secret vers
>> >> > un serveur qu'on hebergerait nous. C'est vraiment ca qui manque dans
>> >> > oauth2 et qui nous oblige a faire des machins générés a la volée.
>> >> >
>> >> > Le 31 janvier 2012 15:13, miaouf kirsh <miaoufkirsh@xxxxxxxxx> a
>> >> > écrit :
>> >> >> justement j'allais repondre un peu la dessus.
>> >> >>
>> >> >> je vais citer quelques bout du draft relatif a la securité dont j'ai
>> >> >> passé
>> >> >> les liens il y a quelques temps.
>> >> >> Ce passage concerne le problème du déploiement d'applications
>> >> >>
>> >> >>
>> >> >> : http://tools.ietf.org/html/draft-ietf-oauth-v2-threatmodel-00#section-5.2.3.4
>> >> >>
>> >> >>  For native applications, things are more complicated because every
>> >> >>
>> >> >>    installation of the app on any device is another deployment..
>> >> >>    Deployment specific secrets will require
>> >> >>
>> >> >>    1.  Either to obtain a client_id and client_secret during
>> >> >> download
>> >> >>        process from the app market, or
>> >> >>
>> >> >>    2.  During installation on the device.
>> >> >>
>> >> >>    Either approach will require an automated mechanism for issuing
>> >> >>    client ids and secrets, which is currently not defined by OAuth.
>> >> >>
>> >> >>    The first approach would allow to achieve a level where the
>> >> >> client
>> >> >> is
>> >> >>    authenticated and identified, whereas the second option only
>> >> >> allows
>> >> >>    to authenticate the client but not to validate properties of the
>> >> >>    client.  But this would at least help to prevent several replay
>> >> >>    attacks.  Moreover, deployment-specific client_id and secret
>> >> >> allow
>> >> >> to
>> >> >>    selectively revoke all refresh tokens of a specific deployment at
>> >> >>    once.
>> >> >>
>> >> >>
>> >> >> donc pour resumer, dans de tel cas il est conseillé d'avoir une
>> >> >> procédure
>> >> >> (non spécifié dans oauth) permettant au client de recuperer un
>> >> >> client-id
>> >> >> plus ou moins automatiquement lors du déploiment. Il me semble que
>> >> >> dans
>> >> >> ce
>> >> >> cas, ca reste plus ou moins valide uniquement si la source du
>> >> >> déploiment est
>> >> >> fiable (genre le market ?) mais je me trompe peu etre.
>> >> >>
>> >> >> un autre passage interessant concerne les clients "qui ne peuvent
>> >> >> garder un
>> >> >> secret"
>> >> >>
>> >> >>
>> >> >> . http://tools.ietf.org/html/draft-ietf-oauth-v2-threatmodel-00#section-5.2.3.2
>> >> >>
>> >> >> The authorization may issue a client id, but only accept
>> >> >>    authorization request, which are approved by the end-user.  This
>> >> >>    measure precludes automatic authorization processes.
>> >> >>
>> >> >>
>> >> >> de ce que je comprend, on ne peut faire confiance un client_secret
>> >> >> pour
>> >> >> valider que c'est bien le bon client, et donc on fait appel a
>> >> >> l'utilisateur
>> >> >> pour valider le truc. il est préciser que ca casse le procéssus
>> >> >> automatique
>> >> >> d'autorisation, j'ai du mal a saisir mais je le vois comme ca, a
>> >> >> chaque
>> >> >> requette necessitant l'envois d'un token, l'utilisateur doit valider
>> >> >> la
>> >> >> demande d'autorisation.
>> >> >> en temps normal on a un truc du genre
>> >> >> 1ere utilisation :
>> >> >>   user : login
>> >> >>   user : autorization du client
>> >> >>   autorization ok, je balance un token
>> >> >>
>> >> >> utilisation ultérieure :
>> >> >>  user : login (je suis pas sur)
>> >> >>  le client_secret me dit que le client est deja autorisé pour cet
>> >> >> utilisateur, je balance un token.
>> >> >>
>> >> >> comme le client_secret ne peut etre verifié, l'autorisation devra
>> >> >> etre
>> >> >> demandé a chaque fois, c'est pas terrible comme truc.
>> >> >>
>> >> >> enfin je colle un dernier passage qui me semble interessant, plus en
>> >> >> relation avec la deuxiemme proposition que tu fait (il me semble) :
>> >> >>
>> >> >>    Authorization servers should not issue secrets to clients, if
>> >> >> these
>> >> >>    cannot sufficiently protect it.  This prevents the server from
>> >> >>    overestimating the value of a sucessful authentication of the
>> >> >> client.
>> >> >>
>> >> >>    For example, it is of limited benefit to create a single client
>> >> >> id
>> >> >>    and secret which is shared by all installations of a native app.
>> >> >>    First of all, this secret must be somehow transmitted from the
>> >> >>    developer via the respective distribution channel, e.g. an app
>> >> >>    market, to all installations of the app on end-user devices..  So
>> >> >> the
>> >> >>    secret is typically burned into the source code of the app or a
>> >> >>    associated resource bundle, which cannot be entirely protected
>> >> >> from
>> >> >>    reverse engineering.  Second, effectively such secrets cannot be
>> >> >>    revoked since this would immediatly put all installations out of
>> >> >>
>> >> >>    work.  Moreover, since the authorization server cannot really
>> >> >> trust
>> >> >>
>> >> >>    on the client's identity, it would be dangerous to indicate to
>> >> >> end-
>> >> >>    users the trustworthiness of the client.
>> >> >>
>> >> >>
>> >> >> bon je ne commenterais pas ce passage.
>> >> >>
>> >> >> par contre j'aimerais rebondir sur ces histoire de token (les vrais,
>> >> >> pas les
>> >> >> client_secret)
>> >> >> il me semble que les token identifient une autorisation, cad un
>> >> >> couple
>> >> >> client/user avec les permission correspondantes.
>> >> >> j'ai encore du mal a voir si on doit sauver les token quelques par
>> >> >> pour
>> >> >> eviter a l'utilisateur de devoir se logger a chaque redemarage
>> >> >> d'appli.
>> >> >>
>> >> >> voila je c pas si ca aporte du grain au moulin, je v relire tes
>> >> >> propositions
>> >> >>
>> >> >> Le 31 janvier 2012 08:24, flagos <flagospub@xxxxxxxxx> a écrit :
>> >> >>
>> >> >>> Je fais un up sur le sujet, faut qu'on avance la dessus aussi
>> >> >>>
>> >> >>> Je reprends le truc depuis le debut:
>> >> >>>
>> >> >>> soit on dit que chaque serveur genere ses propres cles => ce qui
>> >> >>> oblige a faire un protocole pour que les applis demande
>> >> >>> automatiquement une clé. C'est faisable via une api rest par
>> >> >>> exemple.
>> >> >>> Il faut ensuite qu'elle stocke cette clé et qu'elle offre un moyen
>> >> >>> facile pour l'utilisateur de supprimer cette clé (en cas de format
>> >> >>> de
>> >> >>> la machine par exemple). Ca me semble pas infaisable, mais cela
>> >> >>> remonte de la complexité au niveau appli. La sécurité n'est pas
>> >> >>> compromise. Cependant on dévie clairement de oauth2, y va y avoir
>> >> >>> du
>> >> >>> hack autour des libs pour oauth2.
>> >> >>>
>> >> >>> soit on centralise la gestion des clés => ca nous oblige a gerer un
>> >> >>> truc en central pour que les gens qui veulent faire leur applis
>> >> >>> puissent s'incrire (un mail ca suffit) et a faire un wget pour
>> >> >>> aller
>> >> >>> recuperer la derniere version (ou via des machins de migration a
>> >> >>> chaque release d'opos ?). On revient a un fonctionnement classique
>> >> >>> de
>> >> >>> oauth2. Il faut bien faire gaffe a ce qu'on recupere pour pas
>> >> >>> compromettre la sécurité du bouzin. Un avantage aussi est qu'un
>> >> >>> instance d'un client pour fonctionner sur 2 opos differents sans
>> >> >>> avoir
>> >> >>> 15 000 considerations a gerer.
>> >> >>>
>> >> >>> Le 28 janvier 2012 12:28, flagos <flagospub@xxxxxxxxx> a écrit :
>> >> >>> > Yop,
>> >> >>> >
>> >> >>> > Bon j'aimerai faire le point sur ces histoires de tokens pour
>> >> >>> > oauth2.
>> >> >>> > Distinguons plusieurs cas:
>> >> >>> >
>> >> >>> > Les pseudo clients: il s'agit des plugins locaux qui font
>> >> >>> > passerelle,
>> >> >>> > ex: rails, jabber. Ils ont l'avantage d'etre en local, on peut
>> >> >>> > facilement recuperer leurs token en local, suffit de se mettre
>> >> >>> > d'accord sur un petit formalisme.
>> >> >>> >
>> >> >>> > Les clients distants: Il s'agit d'une appli distribué sur le
>> >> >>> > device
>> >> >>> > du
>> >> >>> > client. ex: widget gnome, CLI, appli android. Je ne sais pas
>> >> >>> > quelle
>> >> >>> > confiance on peut accorder a un client-secret distribué de cette
>> >> >>> > maniere.
>> >> >>> >
>> >> >>> > Les autres sites web: ex: rails s'il est intallé sur un serveur
>> >> >>> > central pour mutualiser les ressources. On est en pleins dans
>> >> >>> > oauth2.
>> >> >>> > Le client-secret ne peut pas etre regeneré a chaque fois. =>
>> >> >>> > besoin
>> >> >>> > d'une db distante et centrale pour ceux la, a moins que le site
>> >> >>> > manipule autant de client-secret que de serveurs vers lequel il
>> >> >>> > peut
>> >> >>> > se connecter.
>> >> >>> >
>> >> >>> > --
>> >> >>> > Tapé depuis mon clavier
>> >> >>>
>> >> >>>
>> >> >>>
>> >> >>> --
>> >> >>> Tapé depuis mon clavier
>> >> >>>
>> >> >>>
>> >> >>
>> >> >
>> >> >
>> >> >
>> >> > --
>> >> > Tapé depuis mon clavier
>> >>
>> >>
>> >>
>> >> --
>> >> Tapé depuis mon clavier
>> >>
>> >>
>> >
>>
>>
>>
>> --
>> Tapé depuis mon clavier
>>
>>
> arfff moi je gere gentoo suis sdsl pour le bruit
>



-- 
Tapé depuis mon clavier