On Fri, Mar 1, 2013 at 5:17 AM, Chris Wong <chrisyco+haskell-cafe@gmail.com> wrote:

On Thu, Feb 28, 2013 at 1:26 PM, Brandon Allbery <allbery.b@gmail.com> wrote:
> On Wed, Feb 27, 2013 at 8:37 AM, Corentin Dupont <corentin.dupont@gmail.com>
> wrote:
>> Hi Chris,
>> Thanks!
>> That's true for the user number. What should I do? Encrypt it?
>
> It's not that you have a user number, or even that it's accessible: it's
> that it's the entirety of access control, meaning that if the user changes
> it they can masquerade as another user. The correct solution is that a user
> should authenticate, which creates a session hash that you stash away and
> also send back to the user as a cookie so the browser will present it on
> accesses. Then you check that the presented hash is there and matches the
> session hash. These should expire periodically, requiring the user to log
> back in again.

Brandon pretty much pulled the words out of my mouth, but I have one
last thing to add: no matter how well you encrypt the information, as
long as it's in the URL it's insecure.

Hypothetical situation #1: if there's someone looking over your
shoulder, they can just note down the address -- it is in plain view,
after all.

Even more likely: your friend wants to watch the game, so you send her
the link. Unfortunately, you forget to delete your session information
from the URL. Now your friend (conveniently named Eve) has hijacked
your account and is voting on your behalf.

The Ruby on Rails website has an excellent explanation of common
security holes [1]. The article is Rails-centric, but most of it
applies to Haskell as well.

[1] http://guides.rubyonrails.org/security.html

As for libraries, Happstack has happstack-authenticate [2]. I haven't
used it myself, but it looks good.

[2] http://hackage.haskell.org/package/happstack-authenticate

Chris

> --
> brandon s allbery kf8nh sine nomine associates
> allbery.b@gmail.com ballbery@sinenomine.net
> unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net