[Twisted-Python] Re: cred and stateless protocols

[Phil Mayers]

> Since I think that the procedure is similar to HTTP session handling, I
> was asking if there is some reusable support for creating "secure"
> session id and if cred has some support for this.

Ok. You're wrong that they're similar, but let me give the short answer 
to the latter question:

No, cred does not provide secure session IDs. Cred is for authenticating 
credentials.

Individual cred checkers may, for a given credentialInterface, choose to 
execute a challenge/response algorithm and establish a secure session, 
but that is specific to the checker, algorithm and wire protocol 
combination.

HTTP does not have spectacularly good authentication support. The 
available mechanisms insecure in one way or another:
  * basic - Credential exposure. No integrity. No privacy
  * digest - No credential exposure. Minimal integrity (request body 
only - request headers, reply body+headers unprotected). No privacy.

...or not standardised e.g. GSS over HTTP.

The only sensible solution to HTTP authentication for important 
applications is to use an HTTPS link, signed server certs and ideally 
client certs as well, or fallback to HTTP digest or basic.

Once you're using HTTPS, other systems can be sensibly and securely 
used. However...

Homegrown systems using cookies and such MAY in fact weaken the overall 
security of the system unless carefully designed, which brings us back 
to Jarrods point that basically no-one should be writing their own auth 
systems these days. They should be re-using one.

Note: there are circumstances where other concerns outweigh purist 
security. For example, the Google gdata API uses an initial HTTPS GET to 
return an auth token, which is then supplied to the server over HTTP in 
an "Authorization: GoogleAuth THETOKEN" header. This provides much 
greater scalability and is similar to MS Passport (which itself is 
similar to Kerberos).

Presumably the token expires. You should note however that the token is 
NOT used for sessioning. HTTP 302 redirects and URL parameters are used 
for that. You might ponder that Google separated out auth and sessions 
even in their engineering compromise.

Note that the above refers to the non-browser API. Presumably the 
browser API will use a passport-alike 302+cookie.

For open source examples, see PubCookie.

> 
> By the way:
> for user tracking in UDP, why not just use the peer address?

Pardon? Are you serious?