Nmap Security Scanner
*Intro
*Ref Guide
*Install Guide
*Download
*Changelog
*Book
*Docs
Security Lists
*Nmap Hackers
*Nmap Dev
*Bugtraq
*Full Disclosure
*Pen Test
*Basics
*More
Security Tools
*Pass crackers
*Sniffers
*Vuln Scanners
*Web scanners
*Wireless
*Exploitation
*Packet crafters
*More
Site News
Site Search:
Exploit World
Advertising
About/Contact
Credits
Sponsors:
edgeos



WebApp Sec: Cryptographically Generated Cookies

Cryptographically Generated Cookies

From: Paul Johnston <paj_at_pajhome.org.uk>
Date: Sun, 09 Dec 2007 15:58:57 +0000

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.

Regards,

Paul

-------------------------------------------------------------------------
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
-------------------------------------------------------------------------
Received on Dec 12 2007

[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]
edgeos