
On Thu, Feb 28, 2013 at 1:26 PM, Brandon Allbery
On Wed, Feb 27, 2013 at 8:37 AM, Corentin Dupont
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