Forum: Ruby on Rails Yet another reason to use salted passwords

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.
9e7c9c07e64a6b7b075097831c360d53?d=identicon&s=25 billkatz (Guest)
on 2005-11-12 12:49
(Received via mailing list)
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.
Ff82af3238a57fbd1212832ec1a19f28?d=identicon&s=25 dylans (Guest)
on 2005-11-12 12:49
(Received via mailing list)
Never even heard of this before. Good article... and thanks Bill !
38a8230ed3d5c685558b4f0aad3fc74b?d=identicon&s=25 joevandyk (Guest)
on 2005-11-12 12:49
(Received via mailing list)
On 11/10/05, Bill Katz <billkatz@gmail.com> 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?
3dd4b52a0946bd698b1d1635a46ea3a3?d=identicon&s=25 francois.beausoleil (Guest)
on 2005-11-12 12:49
(Received via mailing list)
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/
4bd34a2216dc8bdbf1f017f64e4d59e8?d=identicon&s=25 kyle (Guest)
on 2005-11-12 12:49
(Received via mailing list)
The normal login generator is actually salted too.
38a8230ed3d5c685558b4f0aad3fc74b?d=identicon&s=25 joevandyk (Guest)
on 2005-11-12 12:49
(Received via mailing list)
On 11/10/05, Kyle Maxwell <kyle@kylemaxwell.com> 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?
42172acdf3c6046f84d644cb0b94642c?d=identicon&s=25 pergesu (Guest)
on 2005-11-12 12:49
(Received via mailing list)
On 11/10/05, Joe Van Dyk <joevandyk@gmail.com> wrote:
> 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@lists.rubyonrails.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
42172acdf3c6046f84d644cb0b94642c?d=identicon&s=25 pergesu (Guest)
on 2005-11-12 12:49
(Received via mailing list)
On 11/10/05, Joe Van Dyk <joevandyk@gmail.com> wrote:
>
> 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
4bd34a2216dc8bdbf1f017f64e4d59e8?d=identicon&s=25 kyle (Guest)
on 2005-11-12 12:49
(Received via mailing list)
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
38a8230ed3d5c685558b4f0aad3fc74b?d=identicon&s=25 joevandyk (Guest)
on 2005-11-12 12:49
(Received via mailing list)
On 11/10/05, Pat Maddox <pergesu@gmail.com> wrote:
> > 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?
42172acdf3c6046f84d644cb0b94642c?d=identicon&s=25 pergesu (Guest)
on 2005-11-12 12:49
(Received via mailing list)
On 11/10/05, Joe Van Dyk <joevandyk@gmail.com> wrote:
> > > 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
10d9ed7ab11115b081bb36f56a7a13bc?d=identicon&s=25 johnwilger (Guest)
on 2005-11-12 12:49
(Received via mailing list)
On 11/10/05, Pat Maddox <pergesu@gmail.com> wrote:
> On 11/10/05, Joe Van Dyk <joevandyk@gmail.com> 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
42172acdf3c6046f84d644cb0b94642c?d=identicon&s=25 pergesu (Guest)
on 2005-11-12 12:49
(Received via mailing list)
On 11/10/05, John Wilger <johnwilger@gmail.com> wrote:
> 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
3f900b38ec3b2c45427c354722fa4ce3?d=identicon&s=25 tom (Guest)
on 2005-11-12 12:49
(Received via mailing list)
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.
9e7c9c07e64a6b7b075097831c360d53?d=identicon&s=25 billkatz (Guest)
on 2005-11-12 12:49
(Received via mailing list)
On 11/10/05, Tom Fakes <tom@craz8.com> wrote:
> 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
3f900b38ec3b2c45427c354722fa4ce3?d=identicon&s=25 tom (Guest)
on 2005-11-12 12:49
(Received via mailing list)
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@gmail.com]
Sent: Thursday, November 10, 2005 10:18 PM
To: rails@lists.rubyonrails.org
Subject: Re: [Rails] Yet another reason to use salted passwords



On 11/10/05, Tom Fakes <tom@craz8.com> 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
9e7c9c07e64a6b7b075097831c360d53?d=identicon&s=25 billkatz (Guest)
on 2005-11-12 12:49
(Received via mailing list)
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@gmail.com> 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.


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
5c0f4e71d9d0b71b8b60a2693df1571a?d=identicon&s=25 deirdre (Guest)
on 2005-11-12 12:49
(Received via mailing list)
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)
27c170f482104299af279902be0a9c26?d=identicon&s=25 trevor (Guest)
on 2005-11-12 12:49
(Received via mailing list)
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
5c0f4e71d9d0b71b8b60a2693df1571a?d=identicon&s=25 deirdre (Guest)
on 2005-11-12 12:49
(Received via mailing list)
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.
631950bd299098576e57053ce703e082?d=identicon&s=25 nshb (Guest)
on 2005-11-12 12:49
(Received via mailing list)
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
Afebfc47e8dfbecb51319218ec29bc41?d=identicon&s=25 patrick (Guest)
on 2005-11-12 12:49
(Received via mailing list)
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:
5c0f4e71d9d0b71b8b60a2693df1571a?d=identicon&s=25 deirdre (Guest)
on 2005-11-12 12:49
(Received via mailing list)
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?
5c0f4e71d9d0b71b8b60a2693df1571a?d=identicon&s=25 deirdre (Guest)
on 2005-11-12 12:49
(Received via mailing list)
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.
42172acdf3c6046f84d644cb0b94642c?d=identicon&s=25 pergesu (Guest)
on 2005-11-12 12:49
(Received via mailing list)
On 11/11/05, Deirdre Saoirse Moen <deirdre@deirdre.net> 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
5c0f4e71d9d0b71b8b60a2693df1571a?d=identicon&s=25 deirdre (Guest)
on 2005-11-12 12:49
(Received via mailing list)
On Nov 11, 2005, at 4:52 AM, Pat Maddox wrote:

>
> 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
05d703f649ef1d07e78d7b479fb4c4ac?d=identicon&s=25 james.adam (Guest)
on 2005-11-12 12:49
(Received via mailing list)
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...
9b25c57dd5ed2098de538c2039d7726d?d=identicon&s=25 ken.barker (Guest)
on 2005-11-12 12:50
(Received via mailing list)
On 11/11/05, Deirdre Saoirse Moen <deirdre@deirdre.net> 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?
9b25c57dd5ed2098de538c2039d7726d?d=identicon&s=25 ken.barker (Guest)
on 2005-11-12 12:50
(Received via mailing list)
On 11/11/05, Ken Barker <ken.barker@gmail.com> 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
05d703f649ef1d07e78d7b479fb4c4ac?d=identicon&s=25 james.adam (Guest)
on 2005-11-12 12:50
(Received via mailing list)
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
9e7c9c07e64a6b7b075097831c360d53?d=identicon&s=25 billkatz (Guest)
on 2005-11-12 12:50
(Received via mailing list)
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.
Ff43001ac5fe9805aa6ca2e89d3b7b5d?d=identicon&s=25 jake (Guest)
on 2005-11-12 12:50
(Received via mailing list)
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@gmail.com]
Sent: Friday, November 11, 2005 12:14 PM
To: rails@lists.rubyonrails.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@deirdre.net> 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.
3f900b38ec3b2c45427c354722fa4ce3?d=identicon&s=25 tom (Guest)
on 2005-11-12 12:50
(Received via mailing list)
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@gmail.com]
Sent: Thursday, November 10, 2005 11:13 PM
To: rails@lists.rubyonrails.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@gmail.com> wrote:

On 11/10/05, John Wilger <johnwilger@gmail.com> 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
5c0f4e71d9d0b71b8b60a2693df1571a?d=identicon&s=25 deirdre (Guest)
on 2005-11-12 12:50
(Received via mailing list)
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.
Ad7805c9fcc1f13efc6ed11251a6c4d2?d=identicon&s=25 alex (Guest)
on 2005-11-13 14:47
(Received via mailing list)
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.
70d14478017f13972bb6d82a5dcf161f?d=identicon&s=25 rails (Guest)
on 2005-11-13 16:19
(Received via mailing list)
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.
Ad7805c9fcc1f13efc6ed11251a6c4d2?d=identicon&s=25 alex (Guest)
on 2005-11-13 18:04
(Received via mailing list)
Toby Boudreaux wrote:
>
> 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 :-)
70d14478017f13972bb6d82a5dcf161f?d=identicon&s=25 rails (Guest)
on 2005-11-13 21:56
(Received via mailing list)
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
3f900b38ec3b2c45427c354722fa4ce3?d=identicon&s=25 tom (Guest)
on 2005-11-14 04:39
(Received via mailing list)
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.
Ad7805c9fcc1f13efc6ed11251a6c4d2?d=identicon&s=25 alex (Guest)
on 2005-11-14 10:17
(Received via mailing list)
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.

>
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.
70d14478017f13972bb6d82a5dcf161f?d=identicon&s=25 rails (Guest)
on 2005-11-14 15:50
(Received via mailing list)
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 :)
This topic is locked and can not be replied to.