Re: [openplacos-dev] Re: foutus token

[flagos <flagospub@xxxxxxxxx>]

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