API token expiration time
Pierre-Yves Chibon
pingou at pingoured.fr
Tue Jun 18 09:21:46 UTC 2013
On Tue, 2013-06-18 at 11:01 +0200, Miroslav Suchy wrote:
> On 06/18/2013 10:15 AM, Pierre-Yves Chibon wrote:
> > One year seems a lot to me. That's one year when someone can build
> > packages and we have no way of saying whether it is our fellow Fedora
> > contributor or not.
> > I would be better around 3 months, 6 months max.
>
> How is this safer? How this differ from 30 days or even one day?
>
> If user token is compromised then it is his duty to generate new token
> (which will automatically invalid previous token).
>
> Lets assume super idiot user who will generate new token and
> intermediately post in on Facebook. It actually then does not matter if
> expiration period is two days or 30 days or one year.
>
> If one user account is compromised only his repos will be compromised.
> No one should be affected. It will be fault of such users.
Well, the "No one should be affected" is not entirely true. I'm
packaging <super cool game>, use copr to build it, advertise it. My
account is compromised, I don't realize it. Attacker uses the token to
build <super cool game + my own little backdoor>, all the users of the
repo get the update and "my own little backdoor" with it :)
You're gonna say it isn't much different from the current situation w/
the koji certificate.
> Can we rather assume that our users are smart? And instead of bothering
> them to regenerate token every month, provide them with tools to detect
> that they account has been compromised. E.g provide them list of IP
> address which used their account.
> Do you agree?
So yes, it is problaby not much different. It's just that 1 year seems a
lot to me but maybe it's just me :)
The list of IP address used w/ an account can be nice, but as soon as
you start using "public" access point (you build a package in a train,
airport, train station...) then there is a new IP which you probably
won't be able to tell 2 months later if it was you or not. So that might
not help here.
Pierre
More information about the copr-devel
mailing list