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.


More information about the copr-devel mailing list