1 / 16

A Secure Cookie Protocol

A Secure Cookie Protocol. Alex X. Liu Department of Computer Sciences The University of Texas at Austin Co-authors: Jason M. Kovacs (UT), Chin-Tser Huang (Univ. of South Carolina), Mohamed G. Gouda (UT). HTTP is stateless. Request/ response. Web Application is Stateful. Shopping cart. Web

orde
Download Presentation

A Secure Cookie Protocol

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. A Secure Cookie Protocol Alex X. LiuDepartment of Computer SciencesThe University of Texas at AustinCo-authors: Jason M. Kovacs (UT), Chin-Tser Huang (Univ. of South Carolina), Mohamed G. Gouda (UT)

  2. HTTP is stateless Request/ response The University of Texas at Austin

  3. Web Application is Stateful Shopping cart The University of Texas at Austin

  4. Web Authentication The University of Texas at Austin

  5. Cookie • Cookie: data that records state of clients • Cookies need to be secure Browser Server first request(user/password) verify user/password response(cookie) subsequent request(cookie) verify cookie; if necessary, create a new cookie Response(new cookie) … The University of Texas at Austin

  6. Security Requirements of Cookies • Authentication • Login phase: verify client by password • Subsequent-requests phase: verify client by cookie • Confidentiality • Observation: only server need to read cookie content! • Low-level: only server and client can read cookie content • High-level: only server can read cookie content • Integrity • Detect modified cookies • Anti-replay • Detect stolen cookies The University of Texas at Austin

  7. Efficiency Requirements • No database lookup in verifying a cookie The University of Texas at Austin

  8. State of the art • Fu’s cookie scheme:[Fu et al. 2001] • Three security problems: • Lack of confidentiality • Replay attacks • Volume attacks • user name|expiration time|data| • HMAC( user name|expiration time|data, server key ) The University of Texas at Austin

  9. Confidentiality • Lack of high-level confidentiality. • Use server key? • [Xu et al. 2002]: store 1 key/user in database • Database lookup is inefficient • [Park & Sandhu 2000]: store unique key in cookie • Problem: public key cryptography is inefficient • Our solution: use HMAC( user name|expiration time, server key ) as the encryption key • user name|expiration time|data| • HMAC( user name|expiration time|data, server key ) The University of Texas at Austin

  10. Replay attacks • To launch replay attacks • Steal someone’s cookie (using Trojans, worms, etc) • Replay the cookie • Our Solution: make cookie session dependent • user name|expiration time|(data)k| • HMAC( user name|expiration time|data, server key ) • k= HMAC( user name|expiration time, server key ) • user name|expiration time|(data)k| • HMAC( user name|expiration time|data|session key, server key ) • k= HMAC( user name|expiration time, server key ) The University of Texas at Austin

  11. Volume attacks • user name|expiration time|(data)k| • HMAC( user name|expiration time|data|session key, server key ) • k= HMAC( user name|expiration time, server key ) • Same server key for all cookies – not safe • [Fu 2001] suggests to change server keys periodically • For some cookies, we have to verify twice • Our Solution: replace server key by encryption key • user name|expiration time|(data)k| • HMAC( user name|expiration time|data|session key, k ) • k= HMAC( user name|expiration time, server key ) The University of Texas at Austin

  12. Implementation • Keyed-hash msg auth code: HMAC-SHA1 • Encryption: Rijndael-256 algorithm • Server key: 160 bits • HMAC-SHA1 output: 320 bits • Implemented 5 protocols: • Insecure cookie protocol • Fu’s cookie protocol with low-level confidentiality • Our cookie protocol with low-level confidentiality • Fu’s cookie protocol with high-level confidentiality • Our cookie protocol with high-level confidentiality • Fu’s cookie protocol with high-level confidentiality: use the server key to encrypt data The University of Texas at Austin

  13. Setup • Server: medium-load server, 2.4 GHz Celeron, 512MB RAM, Windows server 2003 standard edition, IIS 6.0, PHP 4.3.10, MySQL 2.23 • Client: 2.8 GHz Pentium 4, 512 MB RAM, Red Hat 3.0 • Link: dedicated gigabit link, RRT=0.9ms • Server creates a new cookie for each request • End-to-end latency: • (1) time for transferring request with cookie to server • (2) time for verifying the cookie • (3) time for creating a new cookie • (4) time for transferring response with new cookie to client The University of Texas at Austin

  14. Results: impacts on client The University of Texas at Austin

  15. Results: impacts on server The University of Texas at Austin

  16. Contributions • Discover 3 problems in state-of-art cookie protocol • Propose a cookie protocol that solves those problems • Conduct performance evaluation and comparison • Conclusion: • Security: better • Performance: close The University of Texas at Austin

More Related