Warning: Can't synchronize with repository "(default)" (Unsupported version control system "svn": No module named svn). Look in the Trac log for more information.

Ticket #2282 (closed defect: fixed)

Opened 10 years ago

Last modified 8 years ago

Authentication and authorization settings should be customizable on deployment

Reported by: kikidonk Owned by: Gustavo
Priority: high Milestone: 2.1rc1
Component: TurboGears Version: trunk
Severity: critical Keywords: auth
Cc:

Description (last modified by Gustavo) (diff)

A TG2 quickstarted project will be setup to use auth_tkt mechanism, and sqlalchemy as backend to fetch users.

The cookie contains an encrypted hash with a secret key that is by default 'secret'. This means that one could change the userid of an exising cookie an recompute a new cookie to be able to be authentified as any user.

The fix for that is to pass 'cookie_secret' option to the repoze.who module.

One way to do this is: self.sa_auth.cookie_secret = "mysecret" in config/app_cfg.py

It seems weird to me to have this key in the python file, since it's more deployment-specific rather than application specific, much like the beaker.session.secret. It might be worth either using the beaker.session.secret key value or be able to define it in the .ini config file.

Like this, there are many things that should be customizable on deployment.

Change History

comment:1 Changed 10 years ago by Gustavo

  • Status changed from new to assigned
  • Description modified (diff)
  • Summary changed from TG2 with auth_tkt authentication uses default secret to Authentication and authorization settings should be customizable on deployment
  • Priority changed from normal to high
  • Keywords auth added
  • Milestone changed from 2.0rc1 to 2.1
  • Owner set to Gustavo
  • Severity changed from major to critical

Agreed. This is one of the issues reported in #2240.

But I'll keep this ticket for auth* settings only.

comment:2 Changed 10 years ago by lszyba1

So currently in cookie is encrypted with "secret"? Isn't this a security problem now? Can I change the secret key on my production website?

Thanks, Lucas

comment:3 Changed 10 years ago by chrisz

The fixed "secret" value is only used in development.ini; the deployment.ini already sets a random value (see #2300). We should probably add some comment in development.ini to make this more clear.

comment:4 Changed 10 years ago by lszyba1

deployment.ini? Was that a replacement for production.ini? If so then I think both these files got removed.

How do you get deployment.ini?

Lucas

comment:5 Changed 10 years ago by lszyba1

ok... the development.ini is using the secret, but deployment.ini is generating proper random passcode.

As soon as #2304 is closed deploying through proper command:

paster make-config myapp production.ini

will generate proper file with random hash.

I'm not sure if anything else needs to be done here?

Thanks, Lucas

comment:6 Changed 10 years ago by kikidonk

I was referring to the AuthTkt? cookie secret, which is not set by anything in turbogears be it in prod or in devel mode.

This means that you can spoof any identity of a website using TG2 if you know a valid username and you use the default 'secret' secret string to compute the hash value.

The fix as i said in the description is to have a line:

self.sa_auth.cookie_secret = "mysecret"

in your app_cfg.py file so that the auth-tkt secret is inited properly

comment:7 Changed 10 years ago by chrisz

Sorry for the confusion. I agree this should be settable in the .ini files and use the beaker secret value by default.

comment:8 Changed 10 years ago by pedersen

beaker.session.secret is set to a random string for production.ini/deployment.ini before today.

As of today, it is also set to a random value in development.ini (see changesets at  http://bitbucket.org/pedersen/tgdevtools-dev/)

Furthermore, the code in tg/configuration.py now looks for this and uses beaker.session.secret as the default value for sa_auth.cookie_secret (see changeset:  http://bitbucket.org/pedersen/tg-dev-fork/changeset/25717e2bd5f8/)

This problem was actually slightly insidious, as storing the cookie secret in app_cfg.py results in a secret that will be common to all installations of a given app, since that file will be viewed as source code by the people who install the application.

We really needed to have it default to using the value stored in the .ini file. The changesets above make sure that the value in the ini file is always random, and ensure that they will be used (unless overridden in app_cfg.py).

The end result is that the developer does not need to do anything extra to benefit from this fix. It just works.

comment:9 Changed 10 years ago by pedersen

  • Status changed from assigned to closed
  • Resolution set to fixed

code has been merged into 2.1 series. Other fixes were put in for 2.0 series. Closing this ticket.

comment:10 Changed 8 years ago by percious

  • Milestone changed from 2.1 to 2.1rc1
Note: See TracTickets for help on using tickets.