WebApp Sec mailing list archives
Re: Cryptographically Generated Cookies
From: "Jamie Riden" <jamie.riden () gmail com>
Date: Thu, 13 Dec 2007 08:48:46 +0000
On 09/12/2007, Paul Johnston <paj () pajhome org uk> wrote:
Hi, People have talked a lot about storing data on the client and cryptographically generating cookies. My recommendation for security is to not do either. All you store on the client is a session ID - a 128-bit random number (plus a CSRF token where needed). Any data is stored on the server side, keyed by the session ID. This is the most secure approach, but it needs a lot of database access on the server. Any approach that involves a crypto-generated cookie and such is a design decision to improve efficiency at some cost to security. Whether these security issues justify the performance gains will depend on the application. As a rough guide, I'd say this is unsuitable for anything that handles money, but probably ok for most other systems. In terms of session IDs, you can generate these cryptographically, using a fairly simple formula: (userid, timestamp, hash(userid + timestamp + server_secret)) Think of this as a token saying "user X logged in at time Y, and this number Z proves the server authorised it". And this can be done without any use of a database on the server. This has two problems: 1) You can't have a proper logout function - the only way a token expires is when it times out. 2) If the server_secret is leaked, your website security vanishes. In terms of storing data on the client, in most situations you don't mind the client seeing this data (it's about them anyway) but you would want to stop them tampering with it. As such, protecting it with a MAC (a keyed hash) with the secret kept on the server will work. This doesn't stop replay attacks, although you could potentially include a timestamp as well to partially address this. You could also use encryption to maintain confidentiality of that data.
Yes - in the past I've used AES( userid + timestamp + HMAC-SHA1( userid + timestamp, secret1), secret2) or whatever other data you need in there - source IP address as well in my case. We didn't mind too much about replay attacks, though as you say, a bank would probably be a lot more concerned. (I would just say that where possible, it's better to use trusted constructions such as HMAC.) I'm no crypto expert, but this should prevent against casual snoopers. cheers, Jamie -- Jamie Riden / jamesr () europe com / jamie () honeynet org uk UK Honeynet Project: http://www.ukhoneynet.org/ ------------------------------------------------------------------------- Sponsored by: Watchfire Methodologies & Tools for Web Application Security Assessment With the rapid rise in the number and types of security threats, web application security assessments should be considered a crucial phase in the development of any web application. What methodology should be followed? What tools can accelerate the assessment process? Download this Whitepaper today! https://www.watchfire.com/securearea/whitepapers.aspx?id=70170000000940F -------------------------------------------------------------------------
Current thread:
- Re: Session security with cookies, (continued)
- Re: Session security with cookies Ron (Dec 04)
- Re: Session security with cookies Aaron Katz (Dec 04)
- Re: Session security with cookies Till Elsner (Dec 05)
- Re: Session security with cookies Aaron Katz (Dec 05)
- Re: Session security with cookies Till Elsner (Dec 05)
- Re: Session security with cookies Aaron Katz (Dec 05)
- Re: Session security with cookies Aaron Shelmire (Dec 08)
- Re: Session security with cookies Eduardo Tongson (Dec 08)
- Cryptographically Generated Cookies Paul Johnston (Dec 12)
- Re: Cryptographically Generated Cookies Andy Steingruebl (Dec 14)
- Re: Cryptographically Generated Cookies Jamie Riden (Dec 14)
- Re: Session security with cookies Aaron Katz (Dec 04)
- RE: Session security with cookies Martin O'Neal (Dec 12)
- Re: Session security with cookies Ron (Dec 04)
- Re: Session security with cookies Scott C. Sanchez (Dec 04)
- RE: Session security with cookies Martin O'Neal (Dec 05)