Ethical Hacking Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package. | Computer Forensics Training at InfoSec Institute Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors. |

| Subject: | Re: Cryptographically Generated Cookies |
|---|---|
| Date: | Wed, 12 Dec 2007 19:07:24 -0800 |
On Dec 9, 2007 7:58 AM, 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.
Barring other types of attacks the work-factor to attack these two is roughly identical. 1. Brute force the key used to encrypt the cookie vs. 2. Brute force the session-id Now, admittedly #1 can be done offline while #2 can only be done online. That said, its roughly the same number of operations. On a site that has a large number of active sessions, you might get lucky and come up with a valid session. Or, you might get lucky and brute force the key used to encrypt the cookie. An ideal scheme to protect the cookie then might rely on a per-user key, or at least a key that rotates relatively frequently so that it isn't valid for a lot more time than the cookie itself. If you also do an HMAC for the cookie and use a different key (good practice) then even a successful brute force on the encryption key doesn't necessarily buy you a lot since you can't tamper with the data. For large sites that are geographically distributed, a shared-nothing approach with the client maintaining most/all of the state can be quite preferable and can be achieved reasonably securely. -- Andy Steingruebl steingra@gmail.com ------------------------------------------------------------------------- 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 -------------------------------------------------------------------------
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: blocking CSRF attacks, Jan Heisterkamp |
|---|---|
| Next by Date: | Re: Defining scope of web application pentest (now scope of an annual medical exam), Andy Steingruebl |
| Previous by Thread: | Cryptographically Generated Cookies, Paul Johnston |
| Next by Thread: | Re: Cryptographically Generated Cookies, Jamie Riden |
| Indexes: | [Date] [Thread] [Top] [All Lists] |