0

I'm trying to implement simple password-based authentication for a web application written using the Happstack framework. My user presents an ID and password, which I hash using bcrypt and check against by database. If the hashed password is in the database for that ID, the user is thereby authenticated.

Once I've authenticated the nice user, I would like then to issue a session cookie which marks that user has being logged in for the duration of the session. (I am not trying to implement a "persistent", "remember me" sort of cookie; I am just trying to find out if the user is logged in for the session.)

Is the presence of the session cookie alone sufficient to authenticate the user? If not, what other information is needed? I could store the cookie's (hashed) value in my database, but at this point, I don't see how what I would be doing would be much different from a persistent login cookie.

In short, is it possible for me to use a session cookie to identify an authenticated user, and if so, how should it be done?

(I have been able to learn how and why to mark the session cookie as "secure" and "HTTP only", but I can't figure out what to do with the darn thing!)

Norman Ramsey
  • 198,648
  • 61
  • 360
  • 533

1 Answers1

1

You can use happstack-authenticate for an existing solution to password logins. If you still want to roll your own however you'll want the happstack-clientsession package for session cookies that the user can't read or write. A normal cookie marked "secure" only means it only works over HTTPS, but the user can still both read and write the cookie. With clientsession the cookie will be encrypted with a server-side key. You can use clientsession both for "remember me" and session logins; it simply depends on what you set the sessionCookieLife to. The default if you use mkSessionConf is Session which is what you want.

Dag
  • 682
  • 5
  • 10
  • thanks for your help This will be good eventually, but happstack-authenticate is not yet ready for use with Happstack 7. And happstack-clientsession is overkill for my problem. – Norman Ramsey Aug 22 '12 at 00:50
  • 1
    Actually `happstack-authenticate` is for Happstack 7 and `happstack-clientsession` exists exactly for situations like yours. In the longer run we want to implement server-side sessions as well, but that's harder to scale. If you just want dead-simple server-side sessions you could generate a client ID with the `entropy` package and put it in a normal Session cookie, and then look up that client ID on every request in a database (e.g. acid-state or just an mvar) mapping to authenticated users. Anything more simple is likely to be insecure. – Dag Aug 24 '12 at 02:21
  • OK thanks. Jeremy tells me that happstack-authenticate is not ready for deployment, and it is *way* more complicated than what I need. I am a guy who can barely understand Happstack Lite. Full Happstack leaves me dazed and confused. I was not able to understand the `ClientSession` interface, and the only 'data' I want to store on the client side is a value of type () meaning "I am here." – Norman Ramsey Aug 24 '12 at 15:02
  • The problem is that normal cookies can be trivially forged by clients, so the solution grows in complexity as you need to implement the security layer yourself. – Dag Aug 24 '12 at 23:18
  • To make the cookie I'm pulling bits from /dev/urandom. I think this is proof against forgery (but not theft). It's starting to look to me as if the answer is "Session cookie buys you nothing; use all the precautions you would use with a *persistent* login cookie." Or possibly "treat it as a persistent login cookie except perhaps you needn't worry about expiring it. (Boy, do I hate the war beteween usability and security.) – Norman Ramsey Aug 25 '12 at 01:37
  • Exactly; the only difference with a persistent login is the cookie expiration. – Dag Aug 25 '12 at 05:43