Where does Pyramid store the auth_tkt at rest? I'm trying to quantify how many open sessions my site currently has and I'm hoping I'm just blanking on what table it's being stored at.
auth_tkt is the default name of the cookie which is a parameter for Pyramid's AuthTktAuthenticationPolicy, which is stored in the visitor's web browser.
Pyramid has no database, but your app might have one. If so, then you'll need to trace through your application's code to find where you maintain server side sessions.
To extend on Steve's answer: auth_tkt is an authentication method which does not require a server-side session storage. It works by generating a cookie based on username and a server-side secret, so the cookie basically looks like this:
senatork:kuh87h887KHJKJH908uo
The client then sends the cookie and the server is able to validate the "claim" contained in the "ticket" by generating a new signature using the server-side secret and comparing it to the one contained in the cookie. Here's some more details in the documentation of the original Apache mod_auth_tkt (which Pyramid does not use, but it uses the same logic).
If you need a session storage for your app you'll need to implement it separately from auth_tkt authentication.
Related
I have a Django project that will ultimately consist of three apps. Two of which will be "normal" Django apps, the third is a djangorestframework app. I also plan on creating a desktop client for the project at some point.
I want the rest app to be the only entity communicating with the database. Hence I use requests to communicate with the rest endpoints from the views of the "normal" Django apps and I will do the same for the desktop client. I want all apps to be accessible only for authenticated users, so I'm using Django's authentication backend.
My question is how to pass on the authenticated user/session from the pure Django apps to the rest endpoints when using requests in the views.
I managed to authenticate on the rest API using request's HTTPBasicAuth, but that requires me to have the user's password at hand in plain text. Sure, I could create a technical user to do these requests. But that would also mean that each and every request would need to go through authentication first and that doesn't feel like the best approach.
I have tried to extract the session cookie from the request object that is provided to the views and pass it on through requests.get, but did not manage to put it into the requests.get call the right way.
As of now, using requests and the established sessions looks like my best bet, especially since that will be the way the desktop client will do things, too. So I'm currently looking for the right way to provide requests.get with the session cookie, but I'm certainly open for better solutions.
You should use tokens.
Basically any kind of authentication out of your django project should be managed with secure tokens.
And yes, authentication check should happen everytime you send a request. To make it faster, you can store tokens in memory. (You can use redis or maybe even load your db on memory or ... ) but this is the right and common way to it. Even django does this check everytime using it's builtin functions.
DRF docs recommended some few packages to manage these tokens:
DRF: Third party packages
I used knox for many projects and it's pretty good.
Basically to authenticate your users over all of your projects or microservices, you have to take the token from user, set it as header or ... for your request to the main database or authentication project.
Most of the apps use token in headers which you can simply add to all of your requests calls:
Requests docs: Custom Headers
I develop and maintain a python pyramid web page. It is deployed live on a separate machine that I have administrative access to (call this Server). I also host it on my own laptop (call this Test).
Login accounts are hashed with bcrypt, such that I cannot read user passwords from the live instance. I can, however, replicate the SQL (I use sqlite) from the live instance to my own Test machine, and do so regularly for testing. I would then replace all hashed passwords with my own password for ease of testing.
Recently I realized that if I'm logged in as user X on my Test instance and then open my Server instance in another tab of the same browser, the Server instance acts as if I'm logged in as user X there.
Is this a security flaw in my web page design? Could it be used to gain access to accounts on the system without knowing their password? This php question says this is linked to the session name I've used for my cookie (and I guess to the secret as well). What are the best security practices for this situation?
If you are using the same database on each case (determining what goes into the cookie), and you hash the cookies with the same secret (determining what the outcome of hashing a given payload looks like), then your cookies are interchangeable. This can actually be useful sometimes for multiprocess testing. It's not a security flaw per se, it's by design, but you need to have a separate cookie hashing secret for every deployed instance if you want their cookies not to be usable by each other.
Check if you using the same session secret for development and production environments
What exactly is the 'secret' parameter of Pyramid's pyramid.authentication.AuthTktAuthenticationPolicy function? The documentation says that it's "(a string) used for auth_tkt cookie signing. Required." The tutorial says that it's "is a string representing an encryption key used by the 'authentication ticket' machinery represented by this policy".
What is auth_tkt cookie signing? What is this 'authentication ticket' machinery? Is this secret supposed to be something I store as a hash in a database or something? I'm really confused.
A tkt auth cookie is a secure hash of several pieces of information, including the username and optionally a timestamp, but not the user password. Once authenticated, you give such a cookie to the user, and every time the user returns you just extract the username again and know it's the same user.
To keep this cookie secure, you need to have a server-side secret, however. Only a server in possession of that secret can create these cookies; if an attacker ever got hold of it he could generate authentication cookies for arbitrary users without ever needing to know the passwords of these users.
The secret parameter for the policy is that server-side secret; it's like a master password for your server. If you run more than one process for your site (and with WSGI, you usually do), you need to make it consistent across your processes, to make sure each process can verify the cookies. You can specify it in your configuration file, in your source code, or in your database; it depends on how much flexibility you need, your security policies, and whether or not you need to share the secret with other systems.
You can share the secret with other systems in your domain that also need to authenticate your users, using the same standard. Apache has a mod_auth_tkt module for example, Plone uses the same standard, and by sharing the secret you can provide a single sign-on for your users across disparate web applications.
Note that changing the secret means existing sessions become invalid, and users would have to re-authenticate.
In any case, existing cookies can have a limited life-span; the embedded timestamp limits how long it will be accepted as valid, if you configure the timeout parameter on the policy. It's good policy to set a timeout, combined with a reissue time; any user that re-visits your application within the timeout will be re-issued a new cookie with a new timestamp to keep their session fresh. That way your session cookies automatically expire if your users do not return, and their cookie cannot be reused by an attacker at a later time. The reissue parameter lets you control how quickly a new token is issued; revisit your server within reissue seconds would not produce a new token.
The secret parameter as far as I remember is just a string used as a salt for the creation of the cookie. You can put whatever you want. Having it in your config file should be more than enough. Saving it in the database might be overkill though if you want to invalidate anything created, I guess changing the secret will invalidate all cookies and session create before that change.
title might be a bit of a misnomer.
I have two subdomains setup in a web application, one for the application frontend at www. (which is using a loose PHP router coupled with backbone, require, and jquery for UI) and a data tier setup at data. (built entire in python utilizing Werkzeug)
We decided to go to this kind of architecture since at some point mobile app will be integrated into the equation, and they can just as easily send HTTP connections to the data subdomain. The data subdomain renders all its responses in JSON, which the JS frontend expects universally as a response be it a valid query response or an error.
This feels like the most organized arrangement I've ever had on a project, until Facebook connect appeared on the manifesto.
Ideally, I'd like to keep as much of the 'action' of the site behind the scenes on the data subdomain, especially authentication stuff, so that the logic is available to the phones and mobile devices as well down the line if need be. Looking into the facebook docs, it appears however that the browser and its session object are critical components in their OAuth flow.
User authentication and app authorization are handled at the same time
by redirecting the user to our OAuth Dialog. When invoking this
dialog, you must pass in your app id that is generated when you create
your application in our Developer App (the client_id parameter) and
the URL that the user's browser will be redirected back to once app
authorization is completed (the redirect_uri parameter). The
redirect_uri must be in the path of the Site URL you specify in
Website section of the Summary tab in the Developer App. Note, your
redirect_uri can not be a redirector.
I've done this before in PHP and am familiar with the process, and it's a trivial matter of about 3 header redirects when the logic in question has direct access to the browser. My problem is that the way our new app is structured, all the business logic is sequestered on the other subdomain. What are my options to simulate the redirect? can I have the python subdomain send the HTTP data, receiving it from the www domain using CURL like all the other requests? Can I return a json object to the user's browser that instructs on doing the redirects? Will Facebook even accept requests from a data subdomain, whose redirect_uri is at subdomain www? I find that last sentence in the quoted section probably discounts that as a possibility, but I've looked through their docs and it doesn't explicity say that this would be treated as a violation.
Has anyone had any experience setting up something like this with Facebook with a similar architecture? Perhaps I should just fold and put the FB login logic directly into PHP and handle it there.
Thanks!
I noticed that cherrypy session does not require a secret key configuration. On the contrary, Pylons session does: http://docs.pylonsproject.org/projects/pylons_framework/dev/sessions.html
I'm concerned about security issues if I'm using session to remember user authentication.
Any one can explain why cherrypy session does not need a secret key? Or is there any suggestion how should I make it secure to use session to remember user login?
There are basically two different ways of maintaining session state: on the server or on the client.
With the server-side approach, you keep the session data in files, a database, or in memory on the server and assign an id to it. This session id is then sent to the client and usually stored in a cookie (although they can also be embedded in URLs). Then with each request, the client's session id is read and used by the web application to load the session data from wherever it's stored on the server. This way, the client never has access to any of the session data and can't tamper with it, but the downside is that you have to protect against session hijacking through the use of stale session ids by malicious clients. This is the model used by most web frameworks and applications today.
Another approach is to store the session data completely on the client side inside of cookies. The downside to this approach is that the data can be seen and tampered with by the client, so you have to take care to properly sign and encrypt the data to prevent tampering. This is where having a good secret key comes into play. The upside is that you also don't have to worry about session hijacking.
Pylons uses Beaker sessions, which can be configured to store session data completely on the client side. That's why you need a secret key.
CherryPy only stores session data on the server and then sends the user a cookie with the session id, so the client never sees the session data and can't tamper with it. You can configure it to use files or just keep everything in memory. You can even hook into it and use a database to store the session data in.
Personally, I prefer the approach used by CherryPy, since it's the same approach used by the majority of the web. It's easier to secure, and you can easily share session data with other applications running on your server without worrying about encryption or keys.