Forum: Ruby on Rails sha1 or md5?

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
66b7903817232d9d42357a269ad48043?d=identicon&s=25 Gonzalo Rubio (gonchuki)
on 2006-02-05 23:14
I'm building a site that requires user log-in and i have seen the Agile
book using sha1 for password hashing while R-Forum uses md5.

Is there any compelling argument to use one over the other?
9e36aeb20f1b4a763043d3ce4942b454?d=identicon&s=25 Jonas Elfström (Guest)
on 2006-02-05 23:23
(Received via mailing list)
On 2/5/06, Gonzalo Rubio <gonchuki@gmail.com> wrote:
> I'm building a site that requires user log-in and i have seen the Agile
> book using sha1 for password hashing while R-Forum uses md5.
>
> Is there any compelling argument to use one over the other?

Both have problems, both are fine...
http://www.schneier.com/blog/archives/2005/02/sha1...

--
Jonas
Elfström
7b829a0c4495eb471379bcc786307a95?d=identicon&s=25 Matt Secoske (Guest)
on 2006-02-05 23:26
(Received via mailing list)
MD5 is known to be broken.  Completely and utterly.  SHA1 has been
sucessfully attacked, but not broken.

I would go with SHA1 and a good SALT.
9a5beb2c3d87189f401188395e6c4032?d=identicon&s=25 Juraci Krohling Costa (Guest)
on 2006-02-06 00:11
(Received via mailing list)
MD5 isn't broken. Some guys could make *colisions* w/ strings encrypted
w/ MD5. It just means that somebody can possibly find a string that
corresponds to the MD5 string, originally encripted via another string.
Ex.:
"somestring" = 123abc123abc123abc123abc123abc123abc
"anotherstring" = 123abc123abc123abc123abc123abc123abc

Obviously, its not a trivial task to get a "colision" MD5 string. Its
just easier to find another vulnerability in your app than to get a
colision.

So, both are secure, but *I* prefer SHA1 because it have a variable
length, making colisions even harder.

Regards,
Juca.
7b829a0c4495eb471379bcc786307a95?d=identicon&s=25 Matt Secoske (Guest)
on 2006-02-06 00:44
(Received via mailing list)
On 2/5/06, Juraci Krohling Costa <juca@jkcosta.info> wrote:
>
> MD5 isn't broken. Some guys could make *colisions* w/ strings encrypted
> w/ MD5. It just means that somebody can possibly find a string that
> corresponds to the MD5 string, originally encripted via another string.
> Ex.:
> "somestring" = 123abc123abc123abc123abc123abc123abc
> "anotherstring" = 123abc123abc123abc123abc123abc123abc


This equals broken.  Let me give you a more appropriate example:

"password1" = 123abc123abc123abc123abc123abc123abc
"anotherpassword" = 123abc123abc123abc123abc123abc123abc

Obviously, its not a trivial task to get a "colision" MD5 string. Its
> just easier to find another vulnerability in your app than to get a
> colision.


It is not trivial, but not difficult either.

So, both are secure, but *I* prefer SHA1 because it have a variable
Df040ca3576504b24a73744179903277?d=identicon&s=25 Tobias Luetke (Guest)
on 2006-02-06 03:06
(Received via mailing list)
That does not equal broken for the purposes of login. An attacker
would have to somehow get his hands on the md5 representation which
doesn't leave your db / app space usually.

> > "somestring" = 123abc123abc123abc123abc123abc123abc
> > "anotherstring" = 123abc123abc123abc123abc123abc123abc
>
> This equals broken.  Let me give you a more appropriate example:
>
> "password1" = 123abc123abc123abc123abc123abc123abc
> "anotherpassword" = 123abc123abc123abc123abc123abc123abc

--
Tobi
http://shopify.com       - modern e-commerce software
http://typo.leetsoft.com - Open source weblog engine
http://blog.leetsoft.com - Technical weblog
66b7903817232d9d42357a269ad48043?d=identicon&s=25 Gonzalo Rubio (gonchuki)
on 2006-02-06 04:16
thanks for all the responses folks. I guess i will be using SHA1 then


and as for this:

Tobias Luetke wrote:
> That does not equal broken for the purposes of login. An attacker
> would have to somehow get his hands on the md5 representation which
> doesn't leave your db / app space usually.

my argument is based in the case that there could be more than one admin
on the site so he also has access to the db, and also since i won't be
using SSL or anything like that, the user/password hash could be
sniffed.
I know, i'm a bit paranoid but you know the drill... you are never
overzealous enough when it comes to security.
F0223b1193ecc3a935ce41a1edd72e42?d=identicon&s=25 zdennis (Guest)
on 2006-02-06 10:38
(Received via mailing list)
Gonzalo Rubio wrote:
>
>
> my argument is based in the case that there could be more than one admin
> on the site so he also has access to the db, and also since i won't be
> using SSL or anything like that, the user/password hash could be
> sniffed.
> I know, i'm a bit paranoid but you know the drill... you are never
> overzealous enough when it comes to security.
>

Are you using client side SHA1 library? If not.... and you are using
SSL, how exactly are you
planning on providing security for the administrator's login
credentials?

Zach
119af50160cabfe1fb6f2f05f5018c64?d=identicon&s=25 James Ludlow (Guest)
on 2006-02-06 17:37
(Received via mailing list)
On 2/5/06, Gonzalo Rubio <gonchuki@gmail.com> wrote:
> my argument is based in the case that there could be more than one admin
> on the site so he also has access to the db, and also since i won't be
> using SSL or anything like that, the user/password hash could be
> sniffed.
> I know, i'm a bit paranoid but you know the drill... you are never
> overzealous enough when it comes to security.

If someone you don't trust has access to your database, you have
bigger problems than reverse engineering a user password.

-- James
This topic is locked and can not be replied to.