Rails - Nov 2005 - Yet another reason to use salted passwords

The Register has a good article on some entrepreneurs making 500GB tables
available for cracking six types of hash, including MD5 and SHA-1.
http://www.theregister.co.uk/2005/11/10/password_hashes/

It makes the good point that crackers already have access to these kinds of
tables, and the use of salts makes this kind of approach more unmanageable.
Since using salts is relatively easy, it doesn''t make sense to skip the
extra step.


_______________________________________________
Rails mailing list
Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
http://lists.rubyonrails.org/mailman/listinfo/rails

Never even heard of this before. Good article... and thanks Bill !

On 11/10/05, Bill Katz <billkatz-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
>
> The Register has a good article on some entrepreneurs making 500GB tables
> available for cracking six types of hash, including MD5 and SHA-1.
> http://www.theregister.co.uk/2005/11/10/password_hashes/
>
> It makes the good point that crackers already have access to these kinds
> of tables, and the use of salts makes this kind of approach more
> unmanageable. Since using salts is relatively easy, it doesn''t
make sense to
> skip the extra step.
>
> _______________________________________________
> Rails mailing list
> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>
>
>

_______________________________________________
Rails mailing list
Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
http://lists.rubyonrails.org/mailman/listinfo/rails

On 11/10/05, Bill Katz <billkatz-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
> The Register has a good article on some entrepreneurs making 500GB tables
> available for cracking six types of hash, including MD5 and SHA-1.
>  http://www.theregister.co.uk/2005/11/10/password_hashes/
>
>  It makes the good point that crackers already have access to these kinds
of
> tables, and the use of salts makes this kind of approach more unmanageable.
> Since using salts is relatively easy, it doesn''t make sense to
skip the
> extra step.
Interesting.  I looked at the salted login gem and there seemed to be
a lot of steps that required a bunch of i18n stuff to be installed. 
Is there a simple way to get salted logins without requiring a lot of
dependencies to be also installed?

2005/11/10, Joe Van Dyk <joevandyk@gmail.com>:
> Interesting.  I looked at the salted login gem and there seemed to be
> a lot of steps that required a bunch of i18n stuff to be installed.
> Is there a simple way to get salted logins without requiring a lot of
> dependencies to be also installed?
If you don't mind the new dependencies, LoginEngine installs in two steps:
svn export http://opensvn.csie.org/rails_engines/plugins/engines
vendor/plugins/engines
svn export http://opensvn.csie.org/rails_engines/plugins/login_engine
vendor/plugins/login_engine

Then, read the docs in login_engine (which boil down to):
cd vendor/plugins/login_engine
rake import_login_engine_schema

Edit application.rb, application_helper.rb as required, add a line to
application.rhtml, then you're done !

Hope that helps !
--
François Beausoleil
http://blog.teksol.info/

_______________________________________________
Rails mailing list
Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
http://lists.rubyonrails.org/mailman/listinfo/rails

The normal login generator is actually salted too.

On 11/10/05, Joe Van Dyk
<joevandyk-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
> On 11/10/05, Bill Katz
<billkatz-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > The Register has a good article on some entrepreneurs making 500GB
tables
> > available for cracking six types of hash, including MD5 and SHA-1.
> >  http://www.theregister.co.uk/2005/11/10/password_hashes/
> >
> >  It makes the good point that crackers already have access to these
kinds of
> > tables, and the use of salts makes this kind of approach more
unmanageable.
> > Since using salts is relatively easy, it doesn''t make sense
to skip the
> > extra step.
>
> Interesting.  I looked at the salted login gem and there seemed to be
> a lot of steps that required a bunch of i18n stuff to be installed.
> Is there a simple way to get salted logins without requiring a lot of
> dependencies to be also installed?
> _______________________________________________
> Rails mailing list
> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>

On 11/10/05, Joe Van Dyk
<joevandyk-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
> On 11/10/05, Bill Katz
<billkatz-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > The Register has a good article on some entrepreneurs making 500GB
tables
> > available for cracking six types of hash, including MD5 and SHA-1.
> >  http://www.theregister.co.uk/2005/11/10/password_hashes/
> >
> >  It makes the good point that crackers already have access to these
kinds of
> > tables, and the use of salts makes this kind of approach more
unmanageable.
> > Since using salts is relatively easy, it doesn''t make sense
to skip the
> > extra step.
>
> Interesting.  I looked at the salted login gem and there seemed to be
> a lot of steps that required a bunch of i18n stuff to be installed.
> Is there a simple way to get salted logins without requiring a lot of
> dependencies to be also installed?
> _______________________________________________
> Rails mailing list
> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>
You can use the LoginEngine [1], which according to the docs is the
SHLG rolled into an engine, but with the localization requirements
removed.

Pat

[1] http://rails-engines.rubyforge.org/wiki/wiki.pl?LoginEngine

On 11/10/05, Kyle Maxwell <kyle-FOSOgQihYpQjo0HpFSRKWA@public.gmane.org>
wrote:
> The normal login generator is actually salted too.
Honestly, I don''t know too much about encryption stuff.  But the salt
for the normal login generator is stored inside the application code. 
So, if an attacker is able to get a copy of the database and the code,
he then has the salt.

But, he''s not able to use any pregenerated data to compare the
encrypted database contents against, right?

Does the salted login generator provide any extra protection than the
normal login generator?
> On 11/10/05, Joe Van Dyk
<joevandyk-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > On 11/10/05, Bill Katz
<billkatz-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > > The Register has a good article on some entrepreneurs making
500GB tables
> > > available for cracking six types of hash, including MD5 and
SHA-1.
> > >  http://www.theregister.co.uk/2005/11/10/password_hashes/
> > >
> > >  It makes the good point that crackers already have access to
these kinds of
> > > tables, and the use of salts makes this kind of approach more
unmanageable.
> > > Since using salts is relatively easy, it doesn''t make
sense to skip the
> > > extra step.
> >
> > Interesting.  I looked at the salted login gem and there seemed to be
> > a lot of steps that required a bunch of i18n stuff to be installed.
> > Is there a simple way to get salted logins without requiring a lot of
> > dependencies to be also installed?
> > _______________________________________________
> > Rails mailing list
> > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> > http://lists.rubyonrails.org/mailman/listinfo/rails
> >
> _______________________________________________
> Rails mailing list
> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>

On 11/10/05, Joe Van Dyk
<joevandyk-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
> On 11/10/05, Kyle Maxwell
<kyle-FOSOgQihYpQjo0HpFSRKWA@public.gmane.org> wrote:
> > The normal login generator is actually salted too.
>
> Honestly, I don''t know too much about encryption stuff.  But the
salt
> for the normal login generator is stored inside the application code.
> So, if an attacker is able to get a copy of the database and the code,
> he then has the salt.
>
> But, he''s not able to use any pregenerated data to compare the
> encrypted database contents against, right?
>
> Does the salted login generator provide any extra protection than the
> normal login generator?

The salted login generator creates a random salt for each account,
then hashes the password against that salt.

Pat

Well, you have to have the salt somewhere accessible from the
application.  The application has to read it to work.  I guess you
could design the system so that part of it is behind an additional
layer of security (i.e. make the hashing happen on another, extremely
locked down server via RPC), but that''s making your life difficult for
perhaps a marginal gain.

The only thing that concerns me is that someone would look over my
shoulder at my salt, or that they would look on my computer while I''m
in the bathroom or something.  I''ve been meaning to push it into
another file and require it, so that way i don''t have to see it as
often

On 11/10/05, Joe Van Dyk
<joevandyk-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
> On 11/10/05, Kyle Maxwell
<kyle-FOSOgQihYpQjo0HpFSRKWA@public.gmane.org> wrote:
> > The normal login generator is actually salted too.
>
> Honestly, I don''t know too much about encryption stuff.  But the
salt
> for the normal login generator is stored inside the application code.
> So, if an attacker is able to get a copy of the database and the code,
> he then has the salt.
>
> But, he''s not able to use any pregenerated data to compare the
> encrypted database contents against, right?
>
> Does the salted login generator provide any extra protection than the
> normal login generator?
>
> > On 11/10/05, Joe Van Dyk
<joevandyk-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > > On 11/10/05, Bill Katz
<billkatz-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > > > The Register has a good article on some entrepreneurs making
500GB tables
> > > > available for cracking six types of hash, including MD5 and
SHA-1.
> > > >  http://www.theregister.co.uk/2005/11/10/password_hashes/
> > > >
> > > >  It makes the good point that crackers already have access
to these kinds of
> > > > tables, and the use of salts makes this kind of approach
more unmanageable.
> > > > Since using salts is relatively easy, it doesn''t
make sense to skip the
> > > > extra step.
> > >
> > > Interesting.  I looked at the salted login gem and there seemed
to be
> > > a lot of steps that required a bunch of i18n stuff to be
installed.
> > > Is there a simple way to get salted logins without requiring a
lot of
> > > dependencies to be also installed?
> > > _______________________________________________
> > > Rails mailing list
> > > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> > > http://lists.rubyonrails.org/mailman/listinfo/rails
> > >
> > _______________________________________________
> > Rails mailing list
> > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> > http://lists.rubyonrails.org/mailman/listinfo/rails
> >
> _______________________________________________
> Rails mailing list
> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>

On 11/10/05, Pat Maddox <pergesu-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
> On 11/10/05, Joe Van Dyk
<joevandyk-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > On 11/10/05, Kyle Maxwell
<kyle-FOSOgQihYpQjo0HpFSRKWA@public.gmane.org> wrote:
> > > The normal login generator is actually salted too.
> >
> > Honestly, I don''t know too much about encryption stuff.  But
the salt
> > for the normal login generator is stored inside the application code.
> > So, if an attacker is able to get a copy of the database and the code,
> > he then has the salt.
> >
> > But, he''s not able to use any pregenerated data to compare
the
> > encrypted database contents against, right?
> >
> > Does the salted login generator provide any extra protection than the
> > normal login generator?
Is each generated salt also stored in the database?

On 11/10/05, Joe Van Dyk
<joevandyk-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
> On 11/10/05, Pat Maddox
<pergesu-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > On 11/10/05, Joe Van Dyk
<joevandyk-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > > On 11/10/05, Kyle Maxwell
<kyle-FOSOgQihYpQjo0HpFSRKWA@public.gmane.org> wrote:
> > > > The normal login generator is actually salted too.
> > >
> > > Honestly, I don''t know too much about encryption stuff. 
But the salt
> > > for the normal login generator is stored inside the application
code.
> > > So, if an attacker is able to get a copy of the database and the
code,
> > > he then has the salt.
> > >
> > > But, he''s not able to use any pregenerated data to
compare the
> > > encrypted database contents against, right?
> > >
> > > Does the salted login generator provide any extra protection than
the
> > > normal login generator?
>
> Is each generated salt also stored in the database?
yep

On 11/10/05, Pat Maddox <pergesu-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
> On 11/10/05, Joe Van Dyk
<joevandyk-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > Is each generated salt also stored in the database?
>
> yep
Maybe I''m just being dense here (not an encryption expert by any
means), but I fail to see what all this gains you.

Assuming the point of the salt value is to make the password more
difficult to decrypt and that in order to decrypt the password I would
need access to the encrypted string:

a) If I have access to the database in order to get the encrypted
version of the password, doesn''t that mean I probably don''t
need to
worry about decrypting passwords at that point since I already have
the rest of the data that was being protected? (Perhaps you should
store login information in a seperate database from everything else,
but I''ll bet this isn''t the case for the vast majority of
applications.)

b) regardless of "a", if the salt value is stored right there next to
the encrypted password, doesn''t that defeat the purpose of having the
salt?

--
Regards,
John Wilger
http://johnwilger.com

-----------
Alice came to a fork in the road. "Which road do I take?" she asked.
"Where do you want to go?" responded the Cheshire cat.
"I don''t know," Alice answered.
"Then," said the cat, "it doesn''t matter."
- Lewis Carrol, Alice in Wonderland

On 11/10/05, John Wilger
<johnwilger-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
> On 11/10/05, Pat Maddox
<pergesu-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > On 11/10/05, Joe Van Dyk
<joevandyk-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > > Is each generated salt also stored in the database?
> >
> > yep
>
> Maybe I''m just being dense here (not an encryption expert by any
> means), but I fail to see what all this gains you.
>
> Assuming the point of the salt value is to make the password more
> difficult to decrypt and that in order to decrypt the password I would
> need access to the encrypted string:
>
> a) If I have access to the database in order to get the encrypted
> version of the password, doesn''t that mean I probably
don''t need to
> worry about decrypting passwords at that point since I already have
> the rest of the data that was being protected? (Perhaps you should
> store login information in a seperate database from everything else,
> but I''ll bet this isn''t the case for the vast majority of
> applications.)
I''m not a security expert (or even at all knowledgeable) by any means.
 I just know how the SHLG works...it creates a random salt and stores
it in the db, then hashes the password against it.  So you''re right,
if you have access to that then you probably have access to all the
other data you want.  I think.


> b) regardless of "a", if the salt value is stored right there
next to
> the encrypted password, doesn''t that defeat the purpose of having
the
> salt?
Again, not a security expert, but that seems pretty valid to me.  I
suppose the advantage is that all the salts are different, so you
can''t just brute force hash your dictionary and get all the passwords.
 You''d have to brute force the dictionary for each salt, if you want
to get all the passwords in the DB.

Honestly, I don''t know the advantages of how the SHLG is implemented. 
I just have a superficial understanding of how it''s implemented.

Pat

Why store the salt in the database?
>From what we''ve read today, a good database of hashed passwords is
500GB.
If you add a single byte salt to that, then the size of the database needed
to crack those passwords is 256 times the 500GB.  Typically, salts are
fairly long, 16 bytes is a good place to start.  In addition to the
password, this would need a database of 500GB * 2 ^ 128 (16 bytes is 128
bits).  This is more data storage than atoms in the universe (a really big
number), and therefore not feasible.

Perhaps we can generate the set of passwords needed.  Well, for each
password we need to generate the equivalent of the same amount of data, but
we don''t need to store it.  Calculating a hash is a non trivial amount
of
work when done at scale, so it become computationally time consuming to
break a password.

Why have a salt per account?  If I can use one of the previous techniques to
break one password, that would tell me what the salt value is too.  If I use
the same salt, I can then use that knowledge to add that salt to every other
password attack, and I''m back at only needing a single 500GB database
to
break every other password in the DB.  Storing the salt means I need to
generate my individual 500GB database that only helps me crack *this*
password.  For, say, 100,000 passwords, this is impractical.

In summary:

1. Salts significantly increase the size of the DB needed for an attack to
the point where it''s impractical to use one at all
2. Generating password hashes on the fly is too intensive to be practical.
3. Individual salts make it so that each password attack must be treated as
a separate attack, and cracking one doesn''t help you crack the next.

Given enough time and importance (i.e. if this was Bill Gates'' bank
account,
it might be worth it, but for my To Do list, no-one''s going to do
this),
this system can be broken, but the salt makes it really hard.

As computation speeds increase, there will be a time where a single password
with salt can be cracked in a reasonable amount of time, but we''re not
there
yet.


-----Original Message-----
From: Pat Maddox [mailto:pergesu-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org] 
Sent: Thursday, November 10, 2005 8:16 PM
To: rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
Subject: Re: [Rails] Yet another reason to use salted passwords

On 11/10/05, John Wilger
<johnwilger-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
> On 11/10/05, Pat Maddox
<pergesu-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > On 11/10/05, Joe Van Dyk
<joevandyk-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > > Is each generated salt also stored in the database?
> >
> > yep
>
> Maybe I''m just being dense here (not an encryption expert by any
> means), but I fail to see what all this gains you.
>
> Assuming the point of the salt value is to make the password more
> difficult to decrypt and that in order to decrypt the password I would
> need access to the encrypted string:
>
> a) If I have access to the database in order to get the encrypted
> version of the password, doesn''t that mean I probably
don''t need to
> worry about decrypting passwords at that point since I already have
> the rest of the data that was being protected? (Perhaps you should
> store login information in a seperate database from everything else,
> but I''ll bet this isn''t the case for the vast majority of
> applications.)
I''m not a security expert (or even at all knowledgeable) by any means.
 I just know how the SHLG works...it creates a random salt and stores
it in the db, then hashes the password against it.  So you''re right,
if you have access to that then you probably have access to all the
other data you want.  I think.


> b) regardless of "a", if the salt value is stored right there
next to
> the encrypted password, doesn''t that defeat the purpose of having
the
> salt?
Again, not a security expert, but that seems pretty valid to me.  I
suppose the advantage is that all the salts are different, so you
can''t just brute force hash your dictionary and get all the passwords.
 You''d have to brute force the dictionary for each salt, if you want
to get all the passwords in the DB.

Honestly, I don''t know the advantages of how the SHLG is implemented. 
I just have a superficial understanding of how it''s implemented.

Pat
_______________________________________________
Rails mailing list
Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
http://lists.rubyonrails.org/mailman/listinfo/rails

On 11/10/05, Tom Fakes <tom-3mLyhfhPcFMAvxtiuMwx3w@public.gmane.org>
wrote:
>
> Why store the salt in the database?
>
> >From what we''ve read today, a good database of hashed
passwords is 500GB.
> If you add a single byte salt to that, then the size of the database
> needed
> to crack those passwords is 256 times the 500GB. Typically, salts are
> fairly long, 16 bytes is a good place to start. In addition to the
> password, this would need a database of 500GB * 2 ^ 128 (16 bytes is 128
> bits). This is more data storage than atoms in the universe (a really big
> number), and therefore not feasible.
>
>
Tom,
If we have a known salt -- let''s say we hacked a system, see the
login_generator code and the stored salt -- then we create a table where
each entry = hash ( known-salt + this-password-guess). I would think
changing the salt size has no impact on the table size.

If we have no idea what the salt might be, then the table size definitely
gets huge because you''ll have to make guesses at a randomly generated
salt.
But I''m looking at it from the standpoint of a compromised database.
-Bill


_______________________________________________
Rails mailing list
Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
http://lists.rubyonrails.org/mailman/listinfo/rails

You are correct, changing the salt size has no impact on the size of the
table to cover every single possible entry.  The 500GB database is a subset
of the possible entries, but these are the hashes for the most likely
entries, words like ''password'' and ''secret''
etc.  The larger the salt you
use, the more you get out of the set of likely entries, up to a certain
point.

 

Even knowing the salt, you have to do the hard work of calculating all of
the likely entries for that salt.  And for the next password you must do it
again, because the salt is different. 

 

Even when the password database is compromised, the attacker must attack
each password individually rather than all passwords at once.

 

The combination of needing to *calculate* (rather than using the
pre-calculated set) the entire likely set for each password and that you
have to do each password individually, just makes an attack a lot harder to
do in a reasonable amount of time.

 

 

 

  _____  

From: Bill Katz [mailto:billkatz-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org] 
Sent: Thursday, November 10, 2005 10:18 PM
To: rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
Subject: Re: [Rails] Yet another reason to use salted passwords

 

On 11/10/05, Tom Fakes <tom-3mLyhfhPcFMAvxtiuMwx3w@public.gmane.org>
wrote:

Why store the salt in the database?
>From what we''ve read today, a good database of hashed passwords is
500GB.
If you add a single byte salt to that, then the size of the database needed
to crack those passwords is 256 times the 500GB.  Typically, salts are 
fairly long, 16 bytes is a good place to start.  In addition to the
password, this would need a database of 500GB * 2 ^ 128 (16 bytes is 128
bits).  This is more data storage than atoms in the universe (a really big 
number), and therefore not feasible.


Tom,
If we have a known salt -- let''s say we hacked a system, see the
login_generator code and the stored salt -- then we create a table where
each entry = hash ( known-salt + this-password-guess). I would think
changing the salt size has no impact on the table size.

If we have no idea what the salt might be, then the table size definitely
gets huge because you''ll have to make guesses at a randomly generated
salt.
But I''m looking at it from the standpoint of a compromised database.
-Bill



_______________________________________________
Rails mailing list
Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
http://lists.rubyonrails.org/mailman/listinfo/rails

I''m not a security expert either, but I have stayed in a Holiday Inn so
I''ll
take a crack at an answer

On 11/10/05, Pat Maddox <pergesu-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
>
> On 11/10/05, John Wilger
<johnwilger-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > a) If I have access to the database in order to get the encrypted
> > version of the password, doesn''t that mean I probably
don''t need to
> > worry about decrypting passwords at that point since I already have
> > the rest of the data that was being protected? (Perhaps you should
> > store login information in a seperate database from everything else,
> > but I''ll bet this isn''t the case for the vast
majority of
> > applications.)
>
> I''m not a security expert (or even at all knowledgeable) by any
means.
> I just know how the SHLG works...it creates a random salt and stores
> it in the db, then hashes the password against it. So you''re
right,
> if you have access to that then you probably have access to all the
> other data you want. I think.

You also have to consider compromise of other systems. Most users don''t
have
separate passwords for every single account they own. If a cracker gets John
Doe''s password on foo.com <http://foo.com>, he''s like to
have the password
for John Doe''s account on Amazon and maybe his bank. It''s also
possible that
the password data is separated from other databases of value that are stored
in uncompromised systems.
> b) regardless of "a", if the salt value is stored right there
next to
> > the encrypted password, doesn''t that defeat the purpose of
having the
> > salt?
>
> Again, not a security expert, but that seems pretty valid to me. I
> suppose the advantage is that all the salts are different, so you
> can''t just brute force hash your dictionary and get all the
passwords.
> You''d have to brute force the dictionary for each salt, if you
want
> to get all the passwords in the DB.

Look at it from the cracker''s viewpoint.

Case 1: No Salt

Without a salt, you generate possible passwords, hash them, and store them
into a massive table. If you have a list of likely passwords, like a
dictionary, it substantially reduces the size of the generated table. If you
limit the presumed length of passwords, you can reduce the number of
possible passwords. Depending on the size of your table, you might not get a
hit on some of the really long and complicated passwords. If you have to
worry about someone using a 15 character long password, the size of your
table goes up significantly even if you restrict possible passwords to
combinations of dictionary words.

Case 2: Fixed Salt

The password scheme has a single hash that''s reused, which is how the
login_generator works. We can''t use the tables we generated for
cracking
foobar.com <http://foobar.com>, because the salt is different. So we have
to
regenerate the table by prepending the known salt to the list of likely
passwords.The table generation doesn''t take an insignificant of time,
so the
cracker is having to spend his valuable time on your measly system.

Case 3: Varying Salt

Now we move to the salted_login_generator system that uses different salts.
We have the same problem as the static salt case, but it''s magnifed by
every
single password we want to decrypt. The salted_login_generator also hashes
the starting password, combines that hashed password with a salt, and then
hashes the salt+hashed-password again. Does this extra hash step slow us
down? Well, it adds an extra SHA-1 computation for each possible password
calculation.

Case 4: We have no clue about the possible passwords

Each letter in our password could be one of the 26 letters, either lower or
upper case, and the numerals (and maybe punctuation symbols). So each letter
in our password could take at least 26 + 26 + 10 = 62 possibilities,
disregarding other symbols for now.

To cover passwords with length of 1, we generate 62 guesses.
To cover passwords with length of 2, we generate 62 * 62 guesses.
To cover passwords with length of n, we generate 62^n guesses.

For some perspective, 62^8 = 218,340,105,584,896 according to my irb.

Take a look at the completed rainbow table for SHA-1:
http://www.rainbowcrack-online.com/?x=sha1

They use a "mixalpha-numeric" character set, which is the 62
characters I
have above. Limiting the password (plaintext) length range to 1-7
characters, it took 8 months and 47 days to generate the 30.52 Gb table with
a Pentium 4 2GHz and 512 MB RAM. And you''d get about 99.33% success
rate.

Has anyone used the Javascript SHA-1 scripts to compute the hash
client-side? I believe Yahoo mail used the code from
http://pajhome.org.uk/crypt/md5/

-Bill


_______________________________________________
Rails mailing list
Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
http://lists.rubyonrails.org/mailman/listinfo/rails

On Nov 10, 2005, at 7:30 PM, Francois Beausoleil wrote:
> If you don''t mind the new dependencies, LoginEngine installs in
two
> steps:
Personally, I more mind the fact that engines are an approach not  
sanctioned by the core team. (note that no announcement of engines  
ever took place on the ror weblog)

-- 
_Deirdre                                             http://deirdre.net

Hi,

I can''t speak for the core team but my impression is that a plugin 
(which Engines is) is a ''sanctioned'' way to distribute
extensions to
rails without having to pester the core team to include your extensions 
in rails itself.

As an example, I don''t recall seeing the asset_timestamping plugin 
announced on the ROR weblog but I *do* recall seeing an email from 
Jamis saying he intended on using it...

Regards,
Trevor

On 11-Nov-05, at 2:27 AM, Deirdre Saoirse Moen wrote:
> On Nov 10, 2005, at 7:30 PM, Francois Beausoleil wrote:
>
>> If you don''t mind the new dependencies, LoginEngine installs
in two
>> steps:
>
> Personally, I more mind the fact that engines are an approach not 
> sanctioned by the core team. (note that no announcement of engines 
> ever took place on the ror weblog)
>
> -- 
> _Deirdre                                             http://deirdre.net
>
>
> _______________________________________________
> Rails mailing list
> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>
--
Trevor Squires
http://somethinglearned.com

I''ve talked this over with DHH in IRC, therefore I''m pretty
sure I
understand his perspective.

In short, plugins and generators are sanctioned, engines are not.

On Nov 11, 2005, at 3:17 AM, Trevor Squires wrote:
> I can''t speak for the core team but my impression is that a plugin
> (which Engines is) is a ''sanctioned'' way to distribute
extensions
> to rails without having to pester the core team to include your  
> extensions in rails itself.
>
> As an example, I don''t recall seeing the asset_timestamping plugin
> announced on the ROR weblog but I *do* recall seeing an email from  
> Jamis saying he intended on using it...
>
> Regards,
> Trevor
>
> On 11-Nov-05, at 2:27 AM, Deirdre Saoirse Moen wrote:
>
>> On Nov 10, 2005, at 7:30 PM, Francois Beausoleil wrote:
>>
>>> If you don''t mind the new dependencies, LoginEngine
installs in
>>> two steps:
>>
>> Personally, I more mind the fact that engines are an approach not  
>> sanctioned by the core team. (note that no announcement of engines  
>> ever took place on the ror weblog)
-- 
_Deirdre                                             http://deirdre.net

Where they are sanctioned or not, they are useful and serve a very valid
purpose.

How else can I as a developer extend rails in a manner that includes a view?
There simply is no other way without creating an engine. A
"sanctioned"
plugin is for module and class extensions only, but doesn''t handle
anything
such as controllers or views.

It is an EXTREMELY powerful concept to have the potential to build an entire
application based off engines. Wouldn''t you say?

- Nathan

--------------------------------------------------------------
Nathaniel S. H. Brown                 Toll Free 1.877.4.INIMIT
Inimit Innovations                        Phone   604.724.6624
www.inimit.com                              Fax   604.444.9942
 
> -----Original Message-----
> From: rails-bounces-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org 
> [mailto:rails-bounces-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org] On
Behalf Of
> Deirdre Saoirse Moen
> Sent: November 11, 2005 4:04 AM
> To: rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> Subject: Re: [Rails] Yet another reason to use salted passwords
> 
> I''ve talked this over with DHH in IRC, therefore I''m
pretty
> sure I understand his perspective.
> 
> In short, plugins and generators are sanctioned, engines are not.
> 
> On Nov 11, 2005, at 3:17 AM, Trevor Squires wrote:
> 
> > I can''t speak for the core team but my impression is that a
plugin
> > (which Engines is) is a ''sanctioned'' way to
distribute
> extensions to 
> > rails without having to pester the core team to include your 
> > extensions in rails itself.
> >
> > As an example, I don''t recall seeing the asset_timestamping
plugin
> > announced on the ROR weblog but I *do* recall seeing an email from 
> > Jamis saying he intended on using it...
> >
> > Regards,
> > Trevor
> >
> > On 11-Nov-05, at 2:27 AM, Deirdre Saoirse Moen wrote:
> >
> >> On Nov 10, 2005, at 7:30 PM, Francois Beausoleil wrote:
> >>
> >>> If you don''t mind the new dependencies, LoginEngine 
> installs in two 
> >>> steps:
> >>
> >> Personally, I more mind the fact that engines are an approach not 
> >> sanctioned by the core team. (note that no announcement of engines
> >> ever took place on the ror weblog)
> 
> -- 
> _Deirdre                                             
> http://deirdre.net
> 
> 
> _______________________________________________
> Rails mailing list
> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>

a note on logins: in my opinion, this is a crucial subject going beyond 
this very specific issue. one of the main problems of PHP right now is, 
that everyone is developing stuff for themselves (based on their 
requirements). in the course of time, noone is able to overlock all 
these different possibilities (leading to confused users, complex 
documentation and overall frustration). so, why not focus on ONE (or 
maybe two) way(s) to create logins and work TOGETHER on this.

patrick


Am 11.11.2005 um 13:04 schrieb Deirdre Saoirse Moen:
> I''ve talked this over with DHH in IRC, therefore I''m
pretty sure I
> understand his perspective.
>
> In short, plugins and generators are sanctioned, engines are not.
>
> On Nov 11, 2005, at 3:17 AM, Trevor Squires wrote:
>
>> I can''t speak for the core team but my impression is that a
plugin
>> (which Engines is) is a ''sanctioned'' way to
distribute extensions to
>> rails without having to pester the core team to include your 
>> extensions in rails itself.
>>
>> As an example, I don''t recall seeing the asset_timestamping
plugin
>> announced on the ROR weblog but I *do* recall seeing an email from 
>> Jamis saying he intended on using it...
>>
>> Regards,
>> Trevor
>>
>> On 11-Nov-05, at 2:27 AM, Deirdre Saoirse Moen wrote:
>>
>>> On Nov 10, 2005, at 7:30 PM, Francois Beausoleil wrote:
>>>
>>>> If you don''t mind the new dependencies, LoginEngine
installs in two
>>>> steps:
>>>
>>> Personally, I more mind the fact that engines are an approach not 
>>> sanctioned by the core team. (note that no announcement of engines 
>>> ever took place on the ror weblog)
>
> -- 
> _Deirdre                                             http://deirdre.net
>
>
> _______________________________________________
> Rails mailing list
> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>

On Nov 11, 2005, at 4:11 AM, Nathaniel S. H. Brown wrote:
> How else can I as a developer extend rails in a manner that  
> includes a view?
Generators.

Or did you miss the part where script/generate scaffold Foo foo  
creates views?

-- 
_Deirdre                                             http://deirdre.net

On Nov 11, 2005, at 4:17 AM, patrick kranzlmüller wrote:
> a note on logins: in my opinion, this is a crucial subject going  
> beyond this very specific issue. one of the main problems of PHP  
> right now is, that everyone is developing stuff for themselves  
> (based on their requirements). in the course of time, noone is able  
> to overlock all these different possibilities (leading to confused  
> users, complex documentation and overall frustration). so, why not  
> focus on ONE (or maybe two) way(s) to create logins and work  
> TOGETHER on this.
Harking back to my talk with DHH, one of the very problems with the  
One True Way of handling logins is, quite simply, that there is no  
wrench that fits all needs.

For example, I''ve recently worked on (or am working on, or have done  
a small part of and have shelved for a while) a total of 9 rails  
apps, of which 8 had login systems. Of those, they used 5 different  
schemas for user tables.

As examples:

1) Basic user, had no user roles.
2) Had only one user role possible (didn''t even need a lookup table  
for this one).
3) Had many possible user roles, needed habtm.
4) Needed custom data about each user.
5) Needed different custom data about each user, plus man user roles.

That''s just MY apps.

Sure, a generator would have gotten me 90% there, but there is no  
real way of getting 100% there.

If you want to work TOGETHER, then don''t do it as an engine.
That''s
all I''m saying.

Technoweenie''s stuff is much better.

-- 
_Deirdre                                             http://deirdre.net

On 11/11/05, Deirdre Saoirse Moen
<deirdre-mzk6fgDMp2XR7s880joybQ@public.gmane.org>
wrote:
> On Nov 11, 2005, at 4:11 AM, Nathaniel S. H. Brown wrote:
>
> > How else can I as a developer extend rails in a manner that
> > includes a view?
>
> Generators.
>
> Or did you miss the part where script/generate scaffold Foo foo
> creates views?
Generators, I''ve found, kind of suck.  I want to be able to have a
drop-in slice of functionality that allows me to override views and
the functionality itself.  I''d like to be able to use the same slices
in multiple applications, and would like to make updates to the
functionality without breaking the custom changes I''ve made in each
app.  Generators don''t make this impossible, but they sure
don''t make
this easy.  Engines seem to fit the bill nicely.

I''m interested in knowing what objections DHH raised in your convo.  I
understand there are privacy concerns, so feel free to share as much
or as little as you''re comfortable with.

Pat

On Nov 11, 2005, at 4:52 AM, Pat Maddox wrote:
> On 11/11/05, Deirdre Saoirse Moen
<deirdre-mzk6fgDMp2XR7s880joybQ@public.gmane.org> wrote:
>> On Nov 11, 2005, at 4:11 AM, Nathaniel S. H. Brown wrote:
>>
>>> How else can I as a developer extend rails in a manner that
>>> includes a view?
>>
>> Generators.
>>
>> Or did you miss the part where script/generate scaffold Foo foo
>> creates views?
>
> I''m interested in knowing what objections DHH raised in your
convo.  I
> understand there are privacy concerns, so feel free to share as much
> or as little as you''re comfortable with.
This blog entry was mentioned:
http://www.loudthinking.com/arc/000335.html

-- 
_Deirdre                                             http://deirdre.net

Engines fill a fairly specific need that we (my team) have, which is
the development of multiple distinct Rails applications which share
common components (authentication, reporting, importing data from
hellish Excel), and ensuring that a means to apply patches & bug fixes
across each of these applications, including models, controllers and
views with the *minimum* of developer time spend on managing those
updates. Need to roll-back to a previous version of the Reporting
system? Just change the SVN external and *everything* within the
Engine goes back to the way it was. With generators (less so with
those that come with plugins, but this still holds true), the code
would have to be regenerated back into the /app directory.

As far as I''m aware, the only means for producing a common set of
views across a number of rails applications at the moment is by using
a generator (either a normal one, or one that comes within a plugin).
If such generators existed and were so impeccably tailored to our (my
team''s) present and future needs, obviously we would never need to
think about updating the generated code and the whole issue would
disappear. Of course, this isn''t the case. Plugins with piggy-back
generators go a HUGE way towards resolving this issue, but they still
betray their generator colours by their inherently painful upgrade
cycle:

GeneratorDeveloper: ''New version! Many bugs killed dead! Everybody
LEVEL UP!!''
CoderDude: ''Crap, I''m going to have to merge my views &
other stuff
with this latest new version of ''SuperPlugin+Generator to get these
fixes, but then I did make my own patch for some of them.. I hope that
none of their bug fixes squash the behaviour that I expect from my own
modified system.... OK here goes.... OK these are the files that might
change.... [a few hours later].... right, I think I''ve merged all my
customisations.... [runs the server] Oh Crap! Something didn''t go
right there. I better hope I remembered to commit all my changes to
SVN, or I''m a-gunna be screeewed!''

Not to mention that CoderDude has blue-chip clients breathing down his
neck for deadlines.

Put simply and bluntly: We <3 Rails, but generators just don''t cut
the
mustard for our some of our (my team''s) more "quasi
enterprise"
development needs. Hence Engines. Most Rails developers, teams and
projects might not be in the same situation as us, and for the Lone
Code, generators are undoubtedly fine. But that''s life, you choose the
tools most appropriate for your needs, and if the tools don''t exist
yet, you write them yourself.

Engines have not recieved the blessing of the RoR core team, and I
wouldn''t expect any different, because it would be madness to include
them in the core Rails. It''s a mechanism far too easily [ab]used for
things it''s not actually suitable for. I did speak to Jamis
(cc''d to
DHH) about them quite some time ago, before plugins existed in a
released form. Their advice was to reimplement our mechanism as a
plugin, and if anything we were doing could not be achieved in this
way, they would re-examine their plugin mechanism to see what could be
adapted.

As it turns out, we can do everything we need within their plugins
architecture, so we have a happy coexistance - Rails stays clean, but
is flexibly enough to support our (hopefully not too outlandish)
needs. It''s not like we''re forking the project or taking
digging our
heels in and taking a stand against anything.

What was this thread about again? My head feels a bit dizzy...



On 11/11/05, Deirdre Saoirse Moen
<deirdre-mzk6fgDMp2XR7s880joybQ@public.gmane.org>
wrote:
> I''ve talked this over with DHH in IRC, therefore I''m
pretty sure I
> understand his perspective.
>
> In short, plugins and generators are sanctioned, engines are not.
>
> On Nov 11, 2005, at 3:17 AM, Trevor Squires wrote:
>
> > I can''t speak for the core team but my impression is that a
plugin
> > (which Engines is) is a ''sanctioned'' way to
distribute extensions
> > to rails without having to pester the core team to include your
> > extensions in rails itself.
> >
> > As an example, I don''t recall seeing the asset_timestamping
plugin
> > announced on the ROR weblog but I *do* recall seeing an email from
> > Jamis saying he intended on using it...
> >
> > Regards,
> > Trevor
> >
> > On 11-Nov-05, at 2:27 AM, Deirdre Saoirse Moen wrote:
> >
> >> On Nov 10, 2005, at 7:30 PM, Francois Beausoleil wrote:
> >>
> >>> If you don''t mind the new dependencies, LoginEngine
installs in
> >>> two steps:
> >>
> >> Personally, I more mind the fact that engines are an approach not
> >> sanctioned by the core team. (note that no announcement of engines
> >> ever took place on the ror weblog)
>
> --
> _Deirdre                                             http://deirdre.net
>
>
> _______________________________________________
> Rails mailing list
> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>

On 11/11/05, Deirdre Saoirse Moen
<deirdre-mzk6fgDMp2XR7s880joybQ@public.gmane.org>
wrote:
>
> I''ve talked this over with DHH in IRC, therefore I''m
pretty sure I
> understand his perspective.
>
> In short, plugins and generators are sanctioned, engines are not.
>
> On Nov 11, 2005, at 3:17 AM, Trevor Squires wrote:

Can someone give me a quick understanding of the difference between a plugin
and an Engine?


_______________________________________________
Rails mailing list
Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
http://lists.rubyonrails.org/mailman/listinfo/rails

On 11/11/05, Ken Barker
<ken.barker-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
>
> On 11/11/05, Deirdre Saoirse Moen
<deirdre-mzk6fgDMp2XR7s880joybQ@public.gmane.org> wrote:
> >
> > I''ve talked this over with DHH in IRC, therefore I''m
pretty sure I
> > understand his perspective.
> >
> > In short, plugins and generators are sanctioned, engines are not.
> >
> > On Nov 11, 2005, at 3:17 AM, Trevor Squires wrote:
>
>
> Can someone give me a quick understanding of the difference between a
> plugin and an Engine?
>
Another question that pertains to what I want to accomplish...

I am building a site that requires login and blogging functionality. I would
like to keep the code for these functions separated from my core
application...

It is best then to use a login plugin and a blogging plugin.

Or do build and store them in the components directory?

Simply haveing a separate directory for these three functions of the site is
my main goal.

Any advice?

Thanks.

Ken


_______________________________________________
Rails mailing list
Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
http://lists.rubyonrails.org/mailman/listinfo/rails

An Engine is a plugin, but one that can have self-contained
views/partials as well as controllers, helpers and other code. You
also get some bonus features, which are all outlined at the rubyforge
site:

http://rails-engines.rubyforge.org/

- james

On 11/11/05, Ken Barker
<ken.barker-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
> On 11/11/05, Deirdre Saoirse Moen
<deirdre-mzk6fgDMp2XR7s880joybQ@public.gmane.org> wrote:
> > I''ve talked this over with DHH in IRC, therefore I''m
pretty sure I
> > understand his perspective.
> >
> > In short, plugins and generators are sanctioned, engines are not.
> >
> > On Nov 11, 2005, at 3:17 AM, Trevor Squires wrote:
>
>  Can someone give me a quick understanding of the difference between a
> plugin and an Engine?
>
>
> _______________________________________________
> Rails mailing list
> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>
>
>

I think we should separate the user authentication from the authorization
portion. Looking at my code and some of the stuff I''ve seen floating
out
there (login_generator, salted_login_generator, ActiveRBAC), it would be
nice to agree on using a very trimmed-down User model that handles
authentication in a flexible manner for simple hash-based login systems. The
User model could have timestamps for logins, a salt field (?), but no
"profile" information (city/state, website URL,...) and maybe not even
first
and last name. We could establish a convention that there''s some class
that
handles those tidbits outside the User. Call it Profile or Member -- the
class name can be overriden. Then whatever authorization you need -- ad-hoc
or role-based authorization system -- can be bolted on from there. Duck
typing is our friend as long as we agree on some conventions. Plug-ins can
check if profiles are available and hook into user information.

To me, a real strength of Rails is the group of best-practices-based
conventions that have come from on high, but there''s a void where we
deal
with user handling: authentication, authorization, and profiles. Make it
easy for simple cases but extensable for folks with enterprise-level needs.
There''s no reason to stop our conventions at the core Rails level.

On 11/11/05, Deirdre Saoirse Moen
<deirdre-mzk6fgDMp2XR7s880joybQ@public.gmane.org>
wrote:
>
> On Nov 11, 2005, at 4:17 AM, patrick kranzlmüller wrote:
>
> > a note on logins: in my opinion, this is a crucial subject going
> > beyond this very specific issue. one of the main problems of PHP
> > right now is, that everyone is developing stuff for themselves
> > (based on their requirements). in the course of time, noone is able
> > to overlock all these different possibilities (leading to confused
> > users, complex documentation and overall frustration). so, why not
> > focus on ONE (or maybe two) way(s) to create logins and work
> > TOGETHER on this.
>
> Harking back to my talk with DHH, one of the very problems with the
> One True Way of handling logins is, quite simply, that there is no
> wrench that fits all needs.
>
> For example, I''ve recently worked on (or am working on, or have
done
> a small part of and have shelved for a while) a total of 9 rails
> apps, of which 8 had login systems. Of those, they used 5 different
> schemas for user tables.
>
> As examples:
>
> 1) Basic user, had no user roles.
> 2) Had only one user role possible (didn''t even need a lookup
table
> for this one).
> 3) Had many possible user roles, needed habtm.
> 4) Needed custom data about each user.
> 5) Needed different custom data about each user, plus man user roles.
>
>

_______________________________________________
Rails mailing list
Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
http://lists.rubyonrails.org/mailman/listinfo/rails

I agree here -- I ended up pulling the SHLG and heavily modifying it.  I
can''t really wait for a mature plugin and don''t have anywhere
near enough
experience to contribute to it.
 
I have Accounts and AccountGroups.  An Account has one AccountGroup.
Depending on how you want to do it, you could define one or many accounts to
each accountgroup.  I didn''t like having the "roles"
attribute associated
with the user.  Instead, I have an AccountGroup with boolean columns for
each role: "can_manage_users", "can_create_widgets",
"can_edit_widgets" and
so on.  I had seen bit-mapped fields in other login systems and didn''t
like
the loss in flexibility there.
 
Now, in my controllers, I use filters to do things like:
   before_filter  :logged_in
   before_filter  :has_permission_to_create_widgets, :only => [ :create ]
   before_filter  :has_permission_to_edit_widgets, :except => [ :view,
:list, :create ]
 
The authentication is handled in the first filter.  The authorization in
subsequent filters.  I didn''t like the way the SHLG threw this stuff
together.  I kind of wanted to see exactly what was going on in each
controller.
 
I''m not sure if this is the best way to handle things, but it seems
pretty
good to me.  I definitely like the separation between authentication and
authorization.
 
   Jake
 

  _____  

From: Bill Katz [mailto:billkatz-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org] 
Sent: Friday, November 11, 2005 12:14 PM
To: rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
Subject: Re: [Rails] Yet another reason to use salted passwords


I think we should separate the user authentication from the authorization
portion. Looking at my code and some of the stuff I''ve seen floating
out
there (login_generator, salted_login_generator, ActiveRBAC), it would be
nice to agree on using a very trimmed-down User model that handles
authentication in a flexible manner for simple hash-based login systems. The
User model could have timestamps for logins, a salt field (?), but no
"profile" information (city/state, website URL,...) and maybe not even
first
and last name. We could establish a convention  that there''s some class
that
handles those tidbits outside the User. Call it Profile or Member -- the
class name can be overriden. Then whatever authorization you need -- ad-hoc
or role-based authorization system -- can be bolted on from there. Duck
typing is our friend as long as we agree on some conventions. Plug-ins can
check if profiles are available and hook into user information.

To me, a real strength of Rails is the group of best-practices-based
conventions that have come from on high, but there''s a void where we
deal
with user handling: authentication, authorization, and profiles. Make it
easy for simple cases but extensable for folks with enterprise-level needs.
There''s no reason to stop our conventions at the core Rails level.


On 11/11/05, Deirdre Saoirse Moen
<deirdre-mzk6fgDMp2XR7s880joybQ@public.gmane.org> wrote:

On Nov 11, 2005, at 4:17 AM, patrick kranzlmüller wrote:
> a note on logins: in my opinion, this is a crucial subject going
> beyond this very specific issue. one of the main problems of PHP
> right now is, that everyone is developing stuff for themselves 
> (based on their requirements). in the course of time, noone is able
> to overlock all these different possibilities (leading to confused
> users, complex documentation and overall frustration). so, why not 
> focus on ONE (or maybe two) way(s) to create logins and work
> TOGETHER on this.
Harking back to my talk with DHH, one of the very problems with the
One True Way of handling logins is, quite simply, that there is no 
wrench that fits all needs.

For example, I''ve recently worked on (or am working on, or have done
a small part of and have shelved for a while) a total of 9 rails
apps, of which 8 had login systems. Of those, they used 5 different 
schemas for user tables.

As examples:

1) Basic user, had no user roles.
2) Had only one user role possible (didn''t even need a lookup table
for this one).
3) Had many possible user roles, needed habtm. 
4) Needed custom data about each user.
5) Needed different custom data about each user, plus man user roles.






_______________________________________________
Rails mailing list
Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
http://lists.rubyonrails.org/mailman/listinfo/rails

Looking at the use of the rainbow table mentioned below, assuming the salt
value is known by the Bad Guy:

 

Case 1: No Salt

 

Rainbow table works great.  

*All* passwords get cracked in 35 minutes.

 

Case 2: Fixed Salt

 

Pre-purchased Rainbow table won''t work.  I need to generate one for
this
particular salt, but once I have that, all passwords are cracked.  

*All* passwords are cracked in 8 months + 35 minutes

 

Case 3: Varying salt:

 

Pre-purchased Rainbow table won''t work.  I need to generate a unique
rainbow
table for each of my passwords.  

*Each* password is cracked in 8 months + 35 minutes.

 

Case 4 is Case 1 - alpha numeric passwords, no salt.

 

 

The key here is that the salt values make the pre-calculated rainbow tables
fail, and the Bad Guy needs to do more work to get what he wants.

 

One interesting case of the Fixed Salt is if you have some hardware
acceleration that you can use to hash your passwords.  The salt can be
fixed, but locked in the hardware such that no-one can read it (you send in
some text and it comes back hashed with the salt).  This makes it so the Bad
Guy has to search the entire hash range (or steal the hardware), which for a
40 byte hash is 256^40, or this many possible entries:

 

2,135,987,035,920,910,082,395,021,706,169,552,114,602,704,522,356,652,769,94
7,041,607,822,219,725,780,640,550,022,962,086,936,576

 

  _____  

From: Bill Katz [mailto:billkatz-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org] 
Sent: Thursday, November 10, 2005 11:13 PM
To: rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
Subject: Re: [Rails] Yet another reason to use salted passwords

 

I''m not a security expert either, but I have stayed in a Holiday Inn so
I''ll
take a crack at an answer

On 11/10/05, Pat Maddox <pergesu-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:

On 11/10/05, John Wilger
<johnwilger-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
> a) If I have access to the database in order to get the encrypted
> version of the password, doesn''t that mean I probably
don''t need to
> worry about decrypting passwords at that point since I already have
> the rest of the data that was being protected? (Perhaps you should
> store login information in a seperate database from everything else, 
> but I''ll bet this isn''t the case for the vast majority of
> applications.)
I''m not a security expert (or even at all knowledgeable) by any means.
I just know how the SHLG works...it creates a random salt and stores 
it in the db, then hashes the password against it.  So you''re right,
if you have access to that then you probably have access to all the
other data you want.  I think.


You also have to consider compromise of other systems. Most users don''t
have
separate passwords for every single account they own. If a cracker gets John
Doe''s password on foo.com, he''s like to have the password for
John Doe''s
account on Amazon and maybe his bank. It''s also possible that the
password
data is separated from other databases of value that are stored in
uncompromised systems.
 

 
> b) regardless of "a", if the salt value is stored right there
next to
> the encrypted password, doesn''t that defeat the purpose of having
the
> salt?
Again, not a security expert, but that seems pretty valid to me.  I
suppose the advantage is that all the salts are different, so you 
can''t just brute force hash your dictionary and get all the passwords.
You''d have to brute force the dictionary for each salt, if you want
to get all the passwords in the DB.


Look at it from the cracker''s viewpoint. 

Case 1: No Salt

Without a salt, you generate possible passwords, hash them, and store them
into a massive table. If you have a list of likely passwords, like a
dictionary, it substantially reduces the size of the generated table. If you
limit the presumed length of passwords, you can reduce the number of
possible passwords. Depending on the size of your table, you might not get a
hit on some of the really long and complicated passwords. If you have to
worry about someone using a 15 character long password, the size of your
table goes up significantly even if you restrict possible passwords to
combinations of dictionary words.

Case 2: Fixed Salt

The password scheme has a single hash that''s reused, which is how the
login_generator works. We can''t use the tables we generated for
cracking
foobar.com, because the salt is different. So we have to regenerate the
table by prepending the known salt to the list of likely passwords.The table
generation doesn''t take an insignificant of time, so the cracker is
having
to spend his valuable time on your measly system.

Case 3: Varying Salt

Now we move to the salted_login_generator system that uses different salts.
We have the same problem as the static salt case, but it''s magnifed by
every
single password we want to decrypt. The salted_login_generator also hashes
the starting password, combines that hashed password with a salt, and then
hashes the salt+hashed-password again. Does this extra hash step slow us
down? Well, it adds an extra SHA-1 computation for each possible password
calculation.

Case 4: We have no clue about the possible passwords

Each letter in our password could be one of the 26 letters, either lower or
upper case, and the numerals (and maybe punctuation symbols). So each letter
in our password could take at least 26 + 26 + 10 = 62 possibilities,
disregarding other symbols for now.

To cover passwords with length of 1, we generate 62 guesses.
To cover passwords with length of 2, we generate 62 * 62 guesses.
To cover passwords with length of n, we generate 62^n guesses.

For some perspective, 62^8 = 218,340,105,584,896 according to my irb.

Take a look at the completed rainbow table for SHA-1:
http://www.rainbowcrack-online.com/?x=sha1

They use a "mixalpha-numeric" character set, which is the 62
characters I
have above. Limiting the password (plaintext) length range to 1-7
characters, it took 8 months and 47 days to generate the 30.52 Gb table with
a Pentium 4 2GHz and 512 MB RAM. And you''d get about 99.33% success
rate.

Has anyone used the Javascript SHA-1 scripts to compute the hash
client-side? I believe Yahoo mail used the code from
http://pajhome.org.uk/crypt/md5/

-Bill



_______________________________________________
Rails mailing list
Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
http://lists.rubyonrails.org/mailman/listinfo/rails

On Nov 11, 2005, at 4:56 AM, James Adam wrote:
> Engines fill a fairly specific need that we (my team) have,
...which is cool.

I was simply making the point about sanctioned vs. not.

-- 
_Deirdre                                             http://deirdre.net

You''re correct, but in a sense this discussion misses the point.  By 
adding *any* salt at all, you''ve made the attacker look for a different
week point - or a rather, a different attack vector.  As soon as they 
see that a dictionary attack won''t work, they''ll move on and
try
something else, because you can guarantee that there will be a way to do 
what they want to do that is easier than beating a salted system.

This, of course, depends on the assumption that the difficulty added by 
the salt is not countered by the fact that you''ve just given the bad
guy
a partial plaintext into the stored password hash.  My google-fu has 
temporarily escaped me, but I *think* this is true for SHA1, for a long 
enough salt.

-- 
Alex

Tom Fakes wrote:
> Looking at the use of the rainbow table mentioned below, assuming the 
> salt value is known by the Bad Guy:
> 
>  
> 
> Case 1: No Salt
> 
>  
> 
> Rainbow table works great. 
> 
> **All** passwords get cracked in 35 minutes.
> 
>  
> 
> Case 2: Fixed Salt
> 
>  
> 
> Pre-purchased Rainbow table won’t work.  I need to generate one for this 
> particular salt, but once I have that, all passwords are cracked. 
> 
> **All** passwords are cracked in 8 months + 35 minutes
> 
>  
> 
> Case 3: Varying salt:
> 
>  
> 
> Pre-purchased Rainbow table won’t work.  I need to generate a unique 
> rainbow table for each of my passwords. 
> 
> **Each** password is cracked in 8 months + 35 minutes.
> 
>  
> 
> Case 4 is Case 1 – alpha numeric passwords, no salt.
> 
>  
> 
>  
> 
> The key here is that the salt values make the pre-calculated rainbow 
> tables fail, and the Bad Guy needs to do more work to get what he wants.
> 
>  
> 
> One interesting case of the Fixed Salt is if you have some hardware 
> acceleration that you can use to hash your passwords.  The salt can be 
> fixed, but locked in the hardware such that no-one can read it (you send 
> in some text and it comes back hashed with the salt).  This makes it so 
> the Bad Guy has to search the entire hash range (or steal the hardware), 
> which for a 40 byte hash is 256^40, or this many possible entries:
> 
>  
> 
>
2,135,987,035,920,910,082,395,021,706,169,552,114,602,704,522,356,652,769,947,041,607,822,219,725,780,640,550,022,962,086,936,576
> 
>  
> 
> ------------------------------------------------------------------------
> 
> *From:* Bill Katz [mailto:billkatz-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org]
> *Sent:* Thursday, November 10, 2005 11:13 PM
> *To:* rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> *Subject:* Re: [Rails] Yet another reason to use salted passwords
> 
>  
> 
> I''m not a security expert either, but I have stayed in a Holiday
Inn so
> I''ll take a crack at an answer
> 
> On 11/10/05, *Pat Maddox*
<pergesu-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
<mailto:pergesu-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>>
> wrote:
> 
> On 11/10/05, John Wilger
<johnwilger-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
> <mailto:johnwilger-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>>
wrote:
>>  a) If I have access to the database in order to get the encrypted
>>  version of the password, doesn''t that mean I probably
don''t need to
>>  worry about decrypting passwords at that point since I already have
>>  the rest of the data that was being protected? (Perhaps you should
>>  store login information in a seperate database from everything else,
>>  but I''ll bet this isn''t the case for the vast
majority of
>>  applications.)
> 
> I''m not a security expert (or even at all knowledgeable) by any
means.
> I just know how the SHLG works...it creates a random salt and stores
> it in the db, then hashes the password against it.  So you''re
right,
> if you have access to that then you probably have access to all the
> other data you want.  I think.
> 
> 
> You also have to consider compromise of other systems. Most users
don''t
> have separate passwords for every single account they own. If a cracker 
> gets John Doe''s password on foo.com <http://foo.com>,
he''s like to have
> the password for John Doe''s account on Amazon and maybe his bank.
It''s
> also possible that the password data is separated from other databases 
> of value that are stored in uncompromised systems.
>  
> 
>      
> 
>>  b) regardless of "a", if the salt value is stored right
there next to
>>  the encrypted password, doesn''t that defeat the purpose of
having the
>>  salt?
> 
>     Again, not a security expert, but that seems pretty valid to me.  I
>     suppose the advantage is that all the salts are different, so you
>     can''t just brute force hash your dictionary and get all the
passwords.
>     You''d have to brute force the dictionary for each salt, if you
want
>     to get all the passwords in the DB.
> 
> 
> Look at it from the cracker''s viewpoint.
> 
> Case 1: No Salt
> 
> Without a salt, you generate possible passwords, hash them, and store 
> them into a massive table. If you have a list of likely passwords, like 
> a dictionary, it substantially reduces the size of the generated table. 
> If you limit the presumed length of passwords, you can reduce the number 
> of possible passwords. Depending on the size of your table, you might 
> not get a hit on some of the really long and complicated passwords. If 
> you have to worry about someone using a 15 character long password, the 
> size of your table goes up significantly even if you restrict possible 
> passwords to combinations of dictionary words.
> 
> Case 2: Fixed Salt
> 
> The password scheme has a single hash that''s reused, which is how
the
> login_generator works. We can''t use the tables we generated for
cracking
> foobar.com <http://foobar.com>, because the salt is different. So we 
> have to regenerate the table by prepending the known salt to the list of 
> likely passwords.The table generation doesn''t take an
insignificant of
> time, so the cracker is having to spend his valuable time on your measly 
> system.
> 
> Case 3: Varying Salt
> 
> Now we move to the salted_login_generator system that uses different 
> salts. We have the same problem as the static salt case, but it''s 
> magnifed by every single password we want to decrypt. The 
> salted_login_generator also hashes the starting password, combines that 
> hashed password with a salt, and then hashes the salt+hashed-password 
> again. Does this extra hash step slow us down? Well, it adds an extra 
> SHA-1 computation for each possible password calculation.
> 
> Case 4: We have no clue about the possible passwords
> 
> Each letter in our password could be one of the 26 letters, either lower 
> or upper case, and the numerals (and maybe punctuation symbols). So each 
> letter in our password could take at least 26 + 26 + 10 = 62 
> possibilities, disregarding other symbols for now.
> 
> To cover passwords with length of 1, we generate 62 guesses.
> To cover passwords with length of 2, we generate 62 * 62 guesses.
> To cover passwords with length of n, we generate 62^n guesses.
> 
> For some perspective, 62^8 = 218,340,105,584,896 according to my irb.
> 
> Take a look at the completed rainbow table for SHA-1:
> http://www.rainbowcrack-online.com/?x=sha1
> 
> They use a "mixalpha-numeric" character set, which is the 62
characters
> I have above. Limiting the password (plaintext) length range to 1-7 
> characters, it took 8 months and 47 days to generate the 30.52 Gb table 
> with a Pentium 4 2GHz and 512 MB RAM. And you''d get about 99.33%
success
> rate.
> 
> Has anyone used the Javascript SHA-1 scripts to compute the hash 
> client-side? I believe Yahoo mail used the code from 
> http://pajhome.org.uk/crypt/md5/
> 
> -Bill
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Rails mailing list
> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> http://lists.rubyonrails.org/mailman/listinfo/rails

A note on this: if you follow the principle of least privilege and  
keep your auth in a separate table with a specific and restricted db  
user, you lower the potential of revealing all your data when a  
single system account is compromised.

When not using Rails, I end up with many db user accounts. Select- 
only, auth-select, auth-mod, data-CRUD, etc, often for different  
parts of an application. By using an account with only the necessary  
permissions for a given operation, I limit the damage that can be  
done if that user (or a query run by that user) is exploited.

I''d be very interested in working with someone on a plugin/whatever  
to allow PLP in Rails. I''ve looked at doing it on my own, but AR is  
hard to get my head around in the little chunks of free time I end up  
with.



On Nov 10, 2005, at 11:16 PM, Pat Maddox wrote:
> I''m not a security expert (or even at all knowledgeable) by any
means.
>  I just know how the SHLG works...it creates a random salt and stores
> it in the db, then hashes the password against it.  So you''re
right,
> if you have access to that then you probably have access to all the
> other data you want.  I think.

Toby Boudreaux wrote:
> A note on this: if you follow the principle of least privilege and  keep 
> your auth in a separate table with a specific and restricted db  user, 
> you lower the potential of revealing all your data when a  single system 
> account is compromised.
> 
> When not using Rails, I end up with many db user accounts. Select- only, 
> auth-select, auth-mod, data-CRUD, etc, often for different  parts of an 
> application. By using an account with only the necessary  permissions 
> for a given operation, I limit the damage that can be  done if that user 
> (or a query run by that user) is exploited.
> 
> I''d be very interested in working with someone on a
plugin/whatever  to
> allow PLP in Rails. I''ve looked at doing it on my own, but AR is 
hard
> to get my head around in the little chunks of free time I end up  with.
> 
I''ve had a few thoughts about separation of concern, and login systems,
and how difficult a one-size-fits-nobody approach is, and I came to the 
conclusions that:

a) Plugins aren''t general enough
b) Generators are outdated, although they have their place
c) Engines aren''t standard enough
d) Namespaces make everything tricky

So, I thought, why not make a dedicated Rails application just to handle 
authentication?  That way, you can layer whatever login functionality 
you need in your own tablespace, and rely on the separate application to 
be able to handle groups, ACLs, usernames, password complexity 
enforcement, and whatever else you might think of without having to 
contaminate your application with the details behind what should, in 
principle, be a yes or no answer to specific questions.  The separate 
application would export as complex an api as necessary using the web 
services portion of Rails, which would make it fairly trivial to tie 
into any site that used it.  This has two knock-on benefits: single 
sign-on to all the sites that use this single back-end site, and the 
possibility to shield your authentication systems from the outside world 
that little bit more.

All the customisation bits and pieces to handle corner cases can be 
knocked up as plugins, generators, engines, or whatever in this separate 
application without forcing an unnecessary degree of complexity on what 
could otherwise be a very simple front-end application.

Am I barking up a dead tree here?  As far as I can tell, this approach 
would seem to fill a rather significant niche, even though it seems to 
go against the Holy Wisdom of DHH :-)

-- 
Alex

Alex - you have a good idea there for, as you say, yes and no auth  
systems, and the approach (separate apps) has been advocated as a way  
to separate roles for destructive data handling when building Rails  
apps.

Principle of least privilege is still ideal for destructive data  
handling, though, and keeps us from having (at its most absurd) a  
separate application for every operation that would require a  
distinct role. The fate of a database that is compromised with a CRUD  
account is still dark, and using a CRUD user for every operation is  
dangerous.

That being said, I wonder about merging the two ideas: a PLP  
implementation in Rails and a separate (firewalled or localhost-only)  
auth app. If AR could ask for a role by key and have account keys/ 
UNAPs/etc returned, it *might* make it easier to build PLP into AR?

As I said, I''ve not had time to tear into AR as much as I''d
like, but
there is a real need for this and I''m happy to put in some hours on  
it if someone else can partner.

-toby




On Nov 13, 2005, at 11:58 AM, Alex Young wrote:
> Toby Boudreaux wrote:
>> A note on this: if you follow the principle of least privilege  
>> and  keep your auth in a separate table with a specific and  
>> restricted db  user, you lower the potential of revealing all your  
>> data when a  single system account is compromised.
>> When not using Rails, I end up with many db user accounts. Select-  
>> only, auth-select, auth-mod, data-CRUD, etc, often for different   
>> parts of an application. By using an account with only the  
>> necessary  permissions for a given operation, I limit the damage  
>> that can be  done if that user (or a query run by that user) is  
>> exploited.
>> I''d be very interested in working with someone on a plugin/ 
>> whatever  to allow PLP in Rails. I''ve looked at doing it on my
>> own, but AR is  hard to get my head around in the little chunks of  
>> free time I end up  with.
>
> I''ve had a few thoughts about separation of concern, and login  
> systems, and how difficult a one-size-fits-nobody approach is, and  
> I came to the conclusions that:
>
> a) Plugins aren''t general enough
> b) Generators are outdated, although they have their place
> c) Engines aren''t standard enough
> d) Namespaces make everything tricky
>
> So, I thought, why not make a dedicated Rails application just to  
> handle authentication?  That way, you can layer whatever login  
> functionality you need in your own tablespace, and rely on the  
> separate application to be able to handle groups, ACLs, usernames,  
> password complexity enforcement, and whatever else you might think  
> of without having to contaminate your application with the details  
> behind what should, in principle, be a yes or no answer to specific  
> questions.  The separate application would export as complex an api  
> as necessary using the web services portion of Rails, which would  
> make it fairly trivial to tie into any site that used it.  This has  
> two knock-on benefits: single sign-on to all the sites that use  
> this single back-end site, and the possibility to shield your  
> authentication systems from the outside world that little bit more.
>
> All the customisation bits and pieces to handle corner cases can be  
> knocked up as plugins, generators, engines, or whatever in this  
> separate application without forcing an unnecessary degree of  
> complexity on what could otherwise be a very simple front-end  
> application.
>
> Am I barking up a dead tree here?  As far as I can tell, this  
> approach would seem to fill a rather significant niche, even though  
> it seems to go against the Holy Wisdom of DHH :-)
>
> -- 
> Alex
> _______________________________________________
> Rails mailing list
> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> http://lists.rubyonrails.org/mailman/listinfo/rails

Yes, as soon as you add anything to make the regular dictionary attack fail,
90% of your attackers will move on to the next thing, preferably, on a
different site altogether (or an Oracle database, based on the news stories
this week about their password security!)

The salt must be a non-trivial length, and should use the full range of the
bytes, not just be characters the user could type as part of their password,
otherwise this is just making the password longer.

All of this is about defense in depth, and suitability for the problem.  

If you have a free todo-list app, all this salt stuff may not be necessary.
If your app allows a credit card to be stored and used later, the salt thing
becomes interesting.  However, if you then put your credit card numbers in
plaintext in the database, then you probably spent too much time solving the
wrong problem.

-----Original Message-----
From: Alex Young [mailto:alex-qV/boFbD8Meu8LGVeLuP/g@public.gmane.org] 
Sent: Sunday, November 13, 2005 5:39 AM
To: rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
Subject: Re: [Rails] Yet another reason to use salted passwords

You''re correct, but in a sense this discussion misses the point.  By 
adding *any* salt at all, you''ve made the attacker look for a different
week point - or a rather, a different attack vector.  As soon as they 
see that a dictionary attack won''t work, they''ll move on and
try
something else, because you can guarantee that there will be a way to do 
what they want to do that is easier than beating a salted system.

This, of course, depends on the assumption that the difficulty added by 
the salt is not countered by the fact that you''ve just given the bad
guy
a partial plaintext into the stored password hash.  My google-fu has 
temporarily escaped me, but I *think* this is true for SHA1, for a long 
enough salt.

-- 
Alex

Tom Fakes wrote:
> Looking at the use of the rainbow table mentioned below, assuming the 
> salt value is known by the Bad Guy:
> 
>  
> 
> Case 1: No Salt
> 
>  
> 
> Rainbow table works great. 
> 
> **All** passwords get cracked in 35 minutes.
> 
>  
> 
> Case 2: Fixed Salt
> 
>  
> 
> Pre-purchased Rainbow table won''t work.  I need to generate one
for this
> particular salt, but once I have that, all passwords are cracked. 
> 
> **All** passwords are cracked in 8 months + 35 minutes
> 
>  
> 
> Case 3: Varying salt:
> 
>  
> 
> Pre-purchased Rainbow table won''t work.  I need to generate a
unique
> rainbow table for each of my passwords. 
> 
> **Each** password is cracked in 8 months + 35 minutes.
> 
>  
> 
> Case 4 is Case 1 - alpha numeric passwords, no salt.
> 
>  
> 
>  
> 
> The key here is that the salt values make the pre-calculated rainbow 
> tables fail, and the Bad Guy needs to do more work to get what he wants.
> 
>  
> 
> One interesting case of the Fixed Salt is if you have some hardware 
> acceleration that you can use to hash your passwords.  The salt can be 
> fixed, but locked in the hardware such that no-one can read it (you send 
> in some text and it comes back hashed with the salt).  This makes it so 
> the Bad Guy has to search the entire hash range (or steal the hardware), 
> which for a 40 byte hash is 256^40, or this many possible entries:
> 
>  
> 
>
2,135,987,035,920,910,082,395,021,706,169,552,114,602,704,522,356,652,769,94
7,041,607,822,219,725,780,640,550,022,962,086,936,576
> 
>  
> 
> ------------------------------------------------------------------------
> 
> *From:* Bill Katz [mailto:billkatz-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org]
> *Sent:* Thursday, November 10, 2005 11:13 PM
> *To:* rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> *Subject:* Re: [Rails] Yet another reason to use salted passwords
> 
>  
> 
> I''m not a security expert either, but I have stayed in a Holiday
Inn so
> I''ll take a crack at an answer
> 
> On 11/10/05, *Pat Maddox*
<pergesu-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
<mailto:pergesu-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>>
> wrote:
> 
> On 11/10/05, John Wilger
<johnwilger-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
> <mailto:johnwilger-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>>
wrote:
>>  a) If I have access to the database in order to get the encrypted
>>  version of the password, doesn''t that mean I probably
don''t need to
>>  worry about decrypting passwords at that point since I already have
>>  the rest of the data that was being protected? (Perhaps you should
>>  store login information in a seperate database from everything else,
>>  but I''ll bet this isn''t the case for the vast
majority of
>>  applications.)
> 
> I''m not a security expert (or even at all knowledgeable) by any
means.
> I just know how the SHLG works...it creates a random salt and stores
> it in the db, then hashes the password against it.  So you''re
right,
> if you have access to that then you probably have access to all the
> other data you want.  I think.
> 
> 
> You also have to consider compromise of other systems. Most users
don''t
> have separate passwords for every single account they own. If a cracker 
> gets John Doe''s password on foo.com <http://foo.com>,
he''s like to have
> the password for John Doe''s account on Amazon and maybe his bank.
It''s
> also possible that the password data is separated from other databases 
> of value that are stored in uncompromised systems.
>  
> 
>      
> 
>>  b) regardless of "a", if the salt value is stored right
there next to
>>  the encrypted password, doesn''t that defeat the purpose of
having the
>>  salt?
> 
>     Again, not a security expert, but that seems pretty valid to me.  I
>     suppose the advantage is that all the salts are different, so you
>     can''t just brute force hash your dictionary and get all the
passwords.
>     You''d have to brute force the dictionary for each salt, if you
want
>     to get all the passwords in the DB.
> 
> 
> Look at it from the cracker''s viewpoint.
> 
> Case 1: No Salt
> 
> Without a salt, you generate possible passwords, hash them, and store 
> them into a massive table. If you have a list of likely passwords, like 
> a dictionary, it substantially reduces the size of the generated table. 
> If you limit the presumed length of passwords, you can reduce the number 
> of possible passwords. Depending on the size of your table, you might 
> not get a hit on some of the really long and complicated passwords. If 
> you have to worry about someone using a 15 character long password, the 
> size of your table goes up significantly even if you restrict possible 
> passwords to combinations of dictionary words.
> 
> Case 2: Fixed Salt
> 
> The password scheme has a single hash that''s reused, which is how
the
> login_generator works. We can''t use the tables we generated for
cracking
> foobar.com <http://foobar.com>, because the salt is different. So we 
> have to regenerate the table by prepending the known salt to the list of 
> likely passwords.The table generation doesn''t take an
insignificant of
> time, so the cracker is having to spend his valuable time on your measly 
> system.
> 
> Case 3: Varying Salt
> 
> Now we move to the salted_login_generator system that uses different 
> salts. We have the same problem as the static salt case, but it''s 
> magnifed by every single password we want to decrypt. The 
> salted_login_generator also hashes the starting password, combines that 
> hashed password with a salt, and then hashes the salt+hashed-password 
> again. Does this extra hash step slow us down? Well, it adds an extra 
> SHA-1 computation for each possible password calculation.
> 
> Case 4: We have no clue about the possible passwords
> 
> Each letter in our password could be one of the 26 letters, either lower 
> or upper case, and the numerals (and maybe punctuation symbols). So each 
> letter in our password could take at least 26 + 26 + 10 = 62 
> possibilities, disregarding other symbols for now.
> 
> To cover passwords with length of 1, we generate 62 guesses.
> To cover passwords with length of 2, we generate 62 * 62 guesses.
> To cover passwords with length of n, we generate 62^n guesses.
> 
> For some perspective, 62^8 = 218,340,105,584,896 according to my irb.
> 
> Take a look at the completed rainbow table for SHA-1:
> http://www.rainbowcrack-online.com/?x=sha1
> 
> They use a "mixalpha-numeric" character set, which is the 62
characters
> I have above. Limiting the password (plaintext) length range to 1-7 
> characters, it took 8 months and 47 days to generate the 30.52 Gb table 
> with a Pentium 4 2GHz and 512 MB RAM. And you''d get about 99.33%
success
> rate.
> 
> Has anyone used the Javascript SHA-1 scripts to compute the hash 
> client-side? I believe Yahoo mail used the code from 
> http://pajhome.org.uk/crypt/md5/
> 
> -Bill
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Rails mailing list
> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
_______________________________________________
Rails mailing list
Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
http://lists.rubyonrails.org/mailman/listinfo/rails

Toby Boudreaux wrote:
> Alex - you have a good idea there for, as you say, yes and no auth  
> systems, and the approach (separate apps) has been advocated as a way  
> to separate roles for destructive data handling when building Rails  apps.
That''s not quite what I''m suggesting, although you could
certainly use
my suggestion *with* that.
> Principle of least privilege is still ideal for destructive data  
> handling, though, and keeps us from having (at its most absurd) a  
> separate application for every operation that would require a  distinct 
> role. The fate of a database that is compromised with a CRUD  account is 
> still dark, and using a CRUD user for every operation is  dangerous.
> 
> That being said, I wonder about merging the two ideas: a PLP  
> implementation in Rails and a separate (firewalled or localhost-only)  
> auth app. If AR could ask for a role by key and have account keys/ 
> UNAPs/etc returned, it *might* make it easier to build PLP into AR?
>
I think we''re talking about the same thing here.  I''m not
suggesting two
separate front-end apps, one with full CRUD privileges and one with 
read-only rights, but rather, like you say, a separate auth app which 
can be queried by the front-end app when it runs across a protected section.

I''m about to flesh out the user management of a site I''m
working on
today, so I''ll give the details some thought and come back.

-- 
Alex

On Nov 14, 2005, at 4:09 AM, Alex Young wrote:
> Toby Boudreaux wrote:
>> Alex - you have a good idea there for, as you say, yes and no  
>> auth  systems, and the approach (separate apps) has been advocated  
>> as a way  to separate roles for destructive data handling when  
>> building Rails  apps.
> That''s not quite what I''m suggesting, although you could
certainly
> use my suggestion *with* that.
>
Oh, I know -- I was bringing up a related topic, which is creating  
admin applications to run parallel to user applications.
> I think we''re talking about the same thing here.  I''m not
> suggesting two separate front-end apps, one with full CRUD  
> privileges and one with read-only rights, but rather, like you say,  
> a separate auth app which can be queried by the front-end app when  
> it runs across a protected section.
I know what you''re saying about a centralized auth app, but my point  
was that, when taken to the extreme, separate rails applications  
(whether visible to all users, some users or only to other apps)  
isn''t -- for me -- a sufficient replacement for using restricted  
accounts within a database.

Centralized auth is a good idea, but what about non-password data?  
Running every select with a full CRUD user means that if those user  
credentials are compromised, or if a select is somehow exploited, you  
risk everything. Running selects as select-only users limits the  
damage that can be done. The same applies for updates and deletes.

I think the approach you take to managing the auth connection  
(service-oriented, or by modding AR) could be useful for me in  
working out an elegant and somewhat railsy way of handling sets of db  
user accounts.

Keep me posted :)