SHA2 Issues

Hello all,

Thank you in advance for your help with this. I am trying to implement
the user authentication method from Ruby Recipes which calls for the use
of SHA 2. Here is the code for the password:

def password=(pass)
salt = [Array.new(6){rand(256).chr}.join].pack(“m”).chomp
self.password_salt, self.password_hash = salt,
Digest::SHA256.hexdigest(pass + salt)
end

I open a console and can create a user but when I try to add a password
it says that the constant 256 is not initialized. I have changed the
Digest::SHA256 to Digest::SHA2 to no avail. I am using (on Windows -
development only trust me) Ruby 1.8.4 and Rails 1.1.2 with all the
latest updates. Does anyone know what the correct code might be? Thanks
again.

Sincerely,

Robert D.

On 4/14/06, Robert D. [email protected] wrote:

end
Robert D.


Posted via http://www.ruby-forum.com/.


Rails mailing list
[email protected]
http://lists.rubyonrails.org/mailman/listinfo/rails

Did you:

require ‘digest/sha2’

in either your environment.rb or the model where you are using this?

pth

Did you:

require ‘digest/sha2’

in either your environment.rb or the model where you are using this?

pth

No I didn’t. I will insert that and try again. Thank you.

  • Robert D.

I don’t see how adding some random salt makes the website any more
secure. I enter my username and password into a signin_form, and click
signin. The server calls User.password_is?(password+salt). If my
password is n characters long, it should take on the average n/2 guesses
to get it right by typing into the signin_form, no matter what salt is.
If I had the password_hash(how would I get that?) and was trying to
reverse engineer the password, yes–some unknown salt would make that
harder. If I did have the password_hash, why wouldn’t I have the salt,
and anything else I wanted too?

On 4/14/06, Robert D. [email protected] wrote:

Did you:

require ‘digest/sha2’

in either your environment.rb or the model where you are using this?

pth

No I didn’t. I will insert that and try again. Thank you.

Looks like this is indeed required on -some- Ruby installations. It
seems to be hit or miss. The book has been updated to reflect it.

Thanks,


Chad F.
http://chadfowler.com
http://pragmaticprogrammer.com/titles/fr_rr/ (Rails Recipes - In Beta!)
http://pragmaticprogrammer.com/titles/mjwti/ (My Job Went to India,
and All I Got Was This Lousy Book)
http://rubycentral.org
http://rubygarden.org
http://rubygems.rubyforge.org (over three million gems served!)

Anonymous wrote:

I don’t see how adding some random salt makes the website any more
secure. I enter my username and password into a signin_form, and click
signin. The server calls User.password_is?(password+salt). If my
password is n characters long, it should take on the average n/2 guesses
to get it right by typing into the signin_form, no matter what salt is.
If I had the password_hash(how would I get that?) and was trying to
reverse engineer the password, yes–some unknown salt would make that
harder. If I did have the password_hash, why wouldn’t I have the salt,
and anything else I wanted too?

The salt is intended to add protection against dictonary attacks. With
the salt added an attacker is forced to do the hash operation during an
attack, as opposed to pre-constructing a dictionary of common password
hashes.