On Jan 10, 2008 8:26 AM, Ron <ronlists_at_skullsecurity.com> wrote:
> Somebody here is developing a Web application that requires user logins,
> but that is unable to store session information on the server (don't ask
> me why, it's a long story). So here's what they propose: to take the
> username, hash of the password, and date the user logged in, encrypt
> them with a strong encryption algorithm, and store them in a cookie
> (along with a hash to ensure integrity).
>
> My question is, assuming a proper encryption algorithm/eky are chosen,
> can anybody think of a problem that this will create that sessions don't
> already have (namely, replay attacks)?
>
> I've thought about this for over a day, and I can't think of any obvious
> problems, but I could be missing something.
You'll want to consider adding some extra data.
1. How they were authenticated along with some sort of scoring or
priority mechanism.
2. Where (what service, etc) they were authenticated
3. Optional - lifetime of the session
You'll want that data if you ever need to authenticate people for one
service but not others, if you want to force a lifetime of a session
based on which service created it rather than allowing each consumer
service to make the decision itself.
I also wouldn't store the hash of the password in the session, why do
you need it?
--
Andy Steingruebl
steingra_at_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
-------------------------------------------------------------------------
Received on Jan 10 2008
Intro
