Happstack Auth Module

[MightyByte]

I have created a github project for an improved version of the Auth
code that I originally developed in blog posts at
http://softwaresimply.blogspot.com. My vision is that this will make
it dead-simple to add sessions/authentication to any happstack app.
I'm currently using the code in my development, but it has not been
polished and packaged for more general use. After a recent discussion
on #happs I decided that releasing it in this state would be best for
the community since I have limited time to work on it.

So I'm soliciting comments and patches to help turn this into a stable
module. I don't mind it being integrated into the happstack code base
in the future if the community deems that best, but I thought I'd
start with something simple to solve the immediate problem and
generate some interest.

[MightyByte]

And of course I forgot to provide a link.

http://github.com/mightybyte/happstack-auth/tree/master

--
"Banking institutions are more dangerous to our liberties than
standing armies. If the American people ever allow private banks to
control the issue of their currency, first by inflation, then by
deflation, the banks and corporations that will grow up around the
banks will deprive the people of all property until their children
wake-up homeless on the continent their fathers conquered."
--Thomas Jefferson

[jw]

> http://github.com/mightybyte/happstack-auth/tree/master

Hi. This looks useful.
Can you please post the "login.html" that you use?

[MightyByte]

It's there now. I also cleaned things up a bit. Main.hs works
reasonably now. Cabal doesn't build it though. Just go to the demo
directory and compile it with "ghc --make Main.hs" (after the Auth
package is been cabal installed).

[Matthew Elder]

good job!

--
Need somewhere to put your code? http://patch-tag.com
Want to build a webapp? http://happstack.com

[Daniel B Giffin]

sweet.

i've almost finished adding a native implementation of bcrypt[1] to
the crypto package (by adding an "expensive key schedule" setup option
to the existing blowfish code), so that will provide a
possibly-more-imposing (and cost-adaptable) option for hashing
passwords.

[1] http://www.usenix.org/events/usenix99/provos.html

[MightyByte]

Right now it's using iterated SHA512 hashes. I hard-coded it at 512
iterations, but we can certainly change it so the user can adapt the
cost. IANAC, so I don't know the relative merits of bcrypt versus
what I've got now. bcrypt is certainly attractive since it was
designed with precisely this application in mind.

The hash function we use needs to be solidified very soon since
password databases are more difficult to migrate. I suppose we could
avoid the need to pick a hash function by making them pluggable, but
to some extent that undermines the library's goal of letting the user
avoid worrying about the details of hash functions. Anyone have
strong opinions about this issue?

[Daniel B Giffin]

> Right now it's using iterated SHA512 hashes. I hard-coded it at 512
> iterations, but we can certainly change it so the user can adapt the
> cost. IANAC, so I don't know the relative merits of bcrypt versus
> what I've got now. bcrypt is certainly attractive since it was
> designed with precisely this application in mind.

yeah, i think the iterated-hash approach is just fine. (i just walked
down the hall and confirmed this with co-bcrypt-inventor David
Mazières. he agrees that the important thing is to make the cost
parameter adaptable.)

someone might feel that more is known about the possible ways of
optimizing one operation or the other (you wouldn't want to be
seriously naive about the cost), but i haven't heard much about that.

> The hash function we use needs to be solidified very soon since
> password databases are more difficult to migrate. I suppose we could
> avoid the need to pick a hash function by making them pluggable, but
> to some extent that undermines the library's goal of letting the user
> avoid worrying about the details of hash functions. Anyone have
> strong opinions about this issue?

probably we should provide a new datatype for each hashing scheme
(where presently there is just the one SaltedHash type).

if all parameters (like the number of iterations in the current
scheme, or bcrypt's "cost") are stored along with the hash, then users
can choose different schemes and parameters while keeping their stored
user database.

(i.e., something equivalent to the "$..." scheme-and-version
discriminators used in unix password files, and the bcrypt practice of
storing the cost parameter along with the salt and hash.)

as for choosing the scheme, i think it makes sense to provide a
reasonable default that most users won't have to think about (and i
think you're already there), but allow people who care to plug in
their own.