DISQUS

Actually, the comments claiming that this adds *no* security are wrong. Doubling the username and hashing it does prevent one class of attack that a non-salted (or single-salted site) password database is vulnerable to: rainbow tables. If there's no variability in the inputs to your hashing function (and re-using the same salt for all inputs is basically just defining a new, site-specific hashing function) an attacker can pre-generate hashed versions of easily-guessed passwords, and try an offline attack against your database to see if any of their guesses match an entry in the DB.

However, there is certainly some value to generating a unique nonce for each hashed password, and storing it alongside the password. It doesn't have to be truly *random* though; since it's sitting right there in the record, it's not of the class of value like a private key where both entropy and secrecy matter. You can use the username, or the timestamp for when the password was reset, or any other easily-retrievable datum.

I don't know if I'd call it the *first* successful FailCamp -- the one that preceded RubyFringe was pretty kick-ass, too. Joey deVilla did a great job MC'ing, and there were some pretty damn good stories of FAIL...

This is very similar to a tool I helped build for PDX.rb -- we call the app 'Cat Herder', and it's designed to let anyone in the group propose an event and then make an open invitation for others to participate. I've wanted to rebuild it for a while now, since I think there are a large number of groups that have a similar need to casually toss out event proposals and collect RSVPs.