Please note IANAC (I am not a cryptographer).

 

If I understand correctly, what you’re looking for here is a cryptographic nonce (number used only once) to prevent the user from registering an account without knowing some sort of “secret” value (the nonce) which is sent through a side-channel (email) that proves the user is indeed legitimate.

 

Nonces are used in all sorts of security contexts, such as to prevent replay attacks in authentication protocols, and to make forgot password links difficult to guess.

 

I think the crucial aspect of the nonce is that it’s difficult to guess. Thus, hashing any value that’s not difficult to guess (the email you signed up with for instance) does no good.

 

Salting is used mainly for passwords, when you need to regenerate and check the hash but want to introduce more entropy into the stored value. In the case of activation, you don’t ever need to regenerate the hash value, you just need to compare it to the user-supplied value.

 

Just a simple random number will do; as always, the more random the better.

 

The code linked below looks OK in the nonce generation:

 

      self.activation_code = Digest::SHA1.hexdigest( Time.now.to_s.split(//).sort_by {rand}.join )

 

The activation code is the hash of a scrambled time string with 46 randomly sorted (mostly) predictable characters, which works out to ~46! combinations (way too big for a rainbow table).

 

Using the built in random number generator (rand) for ruby in the generation algorithm such as shown above seems to be the best bet, although I don’t know of any extensive review of the RNG in ruby, but at least it’s easy to implement and not trivially compromised.

 

Alex


From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chris Abad
Sent: Wednesday, October 11, 2006 3:25 PM
To: [email protected]
Subject: Re: [Sdruby] User authentication strategies

 

I'm jumping pretty late into this, so I don't know if this idea has been dismissed yet. Here's what I do:

 

Start with this:

 

By default this creates a salted one-way password. If you need reversible passwords, you can do this:

 

If you would like to enable user-authentication use this:

 

And this for the email notification:

 

 

On Oct 11, 2006, at 3:11 PM, Patrick Crowley wrote:



Yeah, to clarify, I also have a Notifications model that contains all of my email-related methods, so UserVerification is probably still overkill for my purposes.

 

The SHA-1 key is stored in a field called unverified, so I can do this:

 

if @user.unverified?

# user isn't verified yet

else

# user is verified :)

end

 

I've also added a method that will allow users to resend the verification email, if it fails to show up in a timely fashion.

 

Best,

Patrick

 

_______________________________________________
Sdruby mailing list
[email protected]
http://lists.sdruby.com/mailman/listinfo/sdruby

Reply via email to