response 11 of 82:

Sep 22 01:03 UTC 2006

Well, so what is the general concensus?

response 13 of 82:

Sep 22 03:04 UTC 2006

unlucky

response 15 of 82:

Sep 22 21:36 UTC 2006

Note: I have written a modified version of login_grexpass (that all users use
when they authenticate to grex by a password) that replaces grexhash'ed hashes
with the system standard hash for the user's login class.  I have not debugged
it, but it was not hard; for debugging, I compiled in a routine that should
make it possible to run the modified version on grex without doing anything
to normal users.

response 17 of 82:

Sep 23 00:48 UTC 2006

I have also installed a throw-away test virtual machine running OpenBSD 3.9,
and have tested all of my changes to the above code (with the exception of
the wnu code, which simply links against the newuser code, which is working.
The only thing I changed for wnu was the Makefile).

All that remains is for some staff member to install this stuff.  I'll do it,
but I'll need root access.

response 19 of 82:

Sep 23 02:44 UTC 2006

Thanks, Mic.  Does everyone concur with me doing this?

response 21 of 82:

Sep 23 03:06 UTC 2006

   This will not be done without talking about it!

response 23 of 82:

Sep 23 03:23 UTC 2006

(By the way: Steve removed me from the wheel account and the staff conference
ulist [which I had added myself to in order to announce when I'd finished
copying all of the programs into the base system.  For the record, yes, I was
planning on waiting until hearing more in this conference before proceeding].)

Regarding #21; By the way, this has been under discussion for more than a
week.  Steve, I wonder, do you regularly read this conference?

response 25 of 82:

Sep 23 11:04 UTC 2006

There are a couple of issues here.  Firstly, there is the whole root
access issue.  Honestly, you folks ought to know better.

Secondly, there is the whole "how things get decided" bit.  There are
reasons why it would be good/bad to switch to using Poul-Henning Kamp's
md5 pw hash, but nobody's managed to raise them.  Raising the same issue
over & over again works great in politics.  It's not a particularly
effective way to make a technical point.  

Regarding your "core dump" argument; if we have things that do that
today, then we definitely better not switch over to using md5.  There are
lots of programs out that will crack passwords given md5 crypt strings.
Few of those programs are going to support grex crypt strings, precisely
because it is non-standard.  Say again why we want to have a "standard"
crypt string that everybody's code understands?

Regarding sha-1/hmac, this is probably the least relevant argument you
could make for grex.  99% of our vandals don't care, and probably at least
50% of our users have security practices that make this entire argument
a moot point.  However, since you mention it: a more modern and standard
password hash than any you've proposed is PKCS#5 pbkdf2.  This is what's
in fact used in kerberos 5 today as well as many other places.  It's based
on hmac, & in kerberos 5, uses sha-1.  From the cryptographic end, md5
is regarded today as suspect, and even sha-1 has recently come under a cloud.
I don't understand your fascination with this argument; not only does it
not really matter for grex, but if you follow the evidence to its end,
it points away from md5 and towards hmac.

response 27 of 82:

Sep 24 00:59 UTC 2006

Btw- A paper on the OpenBSD bcrypt hash is available here:

        http://www.openbsd.org/papers/bcrypt-paper.pdf

That gives a good overview of the bcrypt algorithm that is the default in
OpenBSD.  Note that it is explicitly contrasted with the old MD5 based
password hash that Marcus mentions.  I don't know why he mentioned that at
all, come to think of it.

Marcus did mention PBKDF2.  That's available as an RFC.  A link to it is
here:

        http://www.ietf.org/rfc/rfc2898.txt

While of course they are different, notice how this algorithm resembles
somewhat the internals of the bcrypt implementation: both are based on
repeated permuting the input password based by some function with the result
of the previous iteration as an additional input.  Same basic concept, same
basic function.  Is PBKDF2 stronger?  Perhaps.  Is it worth the maintenance
cost?  As Marcus himself says, it's not likely to be relevant on grex; our
users aren't security concious enough for that.  That's the real attack
vector: the strength of the password itself, not the security of the hash
(and, as Marcus says, some doubt has been cast on the security of SHA-1.
Hmm, another strike against our home-grown algorithm?).

But suppose for a moment that it turns out that the bcrypt algorithm is
weak, or that an HMAC/SHA-256 version of PBKDF2 just becomes clearly the way
to go for password authentication.  Then, if the OpenBSD people are as
security concious as Steve and Marcus claim, surely they will implement the
alternative.

But, then how to switch to it?  You don't de-hash the hashed passwords; the
crypto doesn't work that way.  Instead, you have to get the user to somehow
give you the password so it can be hashed using the new algorithm.  This
highlights another benefit of moving to the standard model: it is easy to
switch algorithms over time.  You simply change the default crypt cipher for
the user's login class in /etc/login.conf to be another algorithm (or a
stronger version of the current algorithm, if that's better).  Then, the
next time the user changes the password, it will automatically be rehashed
with the new algorithm.

Why?  It goes back, again, to the fact that the system stores an identifying
string at the front of the hashed password in /etc/master.passwd that tells
it what algorithm was used to hash the password.  When the user goes to
authenticate, the system uses the algorithm current associated with the
user's hashed password.  However, when the user selects a *new* password,
however, the system looks up what algorithm is associated with the user's
login class (or the system default), and hashes the user's new password
using that algorithm.  If there's a problem, you impose a password
expiration time of, say, a month or two.  Let the system do the dirty work
for you.  All you do is change a configuration file.

Again, though, this is not a security argument, it's a maintenance argument.
One of grex's most precious and scarce resources is staff time.  Marcus's
hash is a drain on that time; perhaps normally not much, but what if the
OpenBSD people change the authentication interface around?  What if the
structure of the passwd program changes suddenly?  As things stand now,
someone has to go in, sort out how things work, and shoehorn our stuff into
the existing model.  Why not just use the existing model, when it offers the
same or comparable security?  In short, it *does* matter.

For the record, my philosophy on things of this nature is that, the standard
for deviations from the base system shouldn't be, "why shold it be the
same?" but rather, "why should it be different?"  Given limited staff
resources, it really should be up to those who want to keep this algorithm
to justify why they want to.

Am I out to lunch here?  What do others think?

response 29 of 82:

Sep 24 04:41 UTC 2006

Hey, Mic.
Can I have root, too?  ;)

response 31 of 82:

Sep 24 05:32 UTC 2006

so;

if we can bring marcus watts back from the deep unknown, do you think we can
resurrect dave thaler ?

response 33 of 82:

Sep 24 07:13 UTC 2006

My main problem with this whole process is that nobody on staff
has the endless amounts of time you seem to require to debate this
issue over and over and over and over and over.  Moreover you appear
to believe you are a better expert in this matter than any of the
current grex staff.

I know about bcrypt, in fact, I knew the author
Niels Provos when he was in A^2 - and by an odd coincidence he ended
up in my old office at the argus building for a while.  I was also
involved in part of the design process for putting PBKDF2 into
kerberos 5.  Today, I'm working to improve encryption technology
in AFS.  There are certainly people who know more in this field
than I do.  I haven't seen any evidence you are one of those people.

I find it perverse you waste so much of everybody's time in monotonic
pursuit of this issue.  You claimed just now that "bcrypt" has no
known weakness, yet there's a version of John the Ripper that has
bcrypt support in it.  Solar Designer has respect for bcrypt - yet
our cookbook vandals have the code.  It's a classic security tradeoff;
can we crank our password quality checks and iteration counts to defeat
the future cookbook vandal who slips in & has superior computing resources
to guess passwords selected by people looking for the lowest entropy possible?
You claim "bcrypt 'has no known vulnerabilities'", in fact, any password
based system does, and using standard algorithms on a public system has
interesting implications.

You claim standards compliance justifies saving
staff time, yet other staff members volunteered their scarce time to do just
that. There are times when individual initiative is to be commended, yet there
are other times when consensus building is in fact more important. Pissing off
other staff members is not a valid consensus building exercise.

You may be believing I have some sort of unnatural attachment to the grex
pwhash algorithm.  I don't.  It has its own weaknesses, as well as
strengths.  I built one experimental version of kerberos 5 that
could use any combination of mit string to key, unix crypt, grex's hash,
and pbk's md5.  I don't see grex moving to kerberos in the near future,
and I even agree there's value to running "standard" software.  The
right answer for a grex upgrade might be "bcrypt".  This is not a black
and white decision, nor even shades of grey.  It's also not my decision
to make, nor is it yours.

That is the core problem here.  Grex does not need a divided and contentious
staff.  Grex needs a cooperative staff who can work well together to
achieve mututal goals.  I am quite capable of being as bad a cowboy as
anybody here.  I reign that in hard.  Most of what you see here on grex
is the result of hard work on others, and grex is so much more because of
all that work.  Grex cannot afford to depend on any one person for stuff,
even you, and especially me.  That is a danger in any sized organization,
and it's a special danger to a small organization like grex.
This is *far* more important than md5 vs. sha1.
I don't care if grex goes with bcrypt with a count of 1 or one gadzillion,
or even with md5.
I care a lot if grex becomes unusable, if grex gets compromised, or
if the decision making or implementation process becomes too unwieldly
or controversial that it drives good people away.

response 35 of 82:

Sep 24 16:54 UTC 2006

(I also don't see how I appear to think I'm more of an expert than anyone else
in this matter.  Would someone please (a) tell me if I'm doing this, and (b)
tell me how?  Surely, asking for a justification of something that requires
staff effort to support is reasonable.)