|
Grex > Agorage > #4: Proposal: Eliminate grex's custom password hash. | |
|
| Author |
Message |
cross
|
|
Proposal: Eliminate grex's custom password hash.
| 
Sep 14 01:30 UTC 2006 |
I propose eliminating grex's strange proprietary password hashing algorithm,
and replacing it with the system standard hash. This involves modifying the
password program in the next system upgrade to *not* use grex's hash when
storing the hashed password.
|
| 81 responses total. |
naftee
|
|
response 1 of 81:
|
Sep 14 04:29 UTC 2006 |
moroccan black ?
|
gull
|
|
response 2 of 81:
|
Sep 18 19:16 UTC 2006 |
That seems sensible. Why did Grex implement its own hash to begin
with? Was it to get around the old 8-character limit on DES hashes?
|
tod
|
|
response 3 of 81:
|
Sep 18 19:29 UTC 2006 |
Diffie is just not a mayonaisse brand.
|
cross
|
|
response 4 of 81:
|
Sep 19 04:27 UTC 2006 |
Regarding #2; That was one reason. Another was to facilitate moving to
Kerberos on the Sun. But, that never happened (and there are other ways to
get user keys into the Kerberos database - grex's hash required modifications
to the KDC, not just grex's local authentication). Another was speed: grex's
hash is based on SHA1, which is faster than DES.
Actually, grex's hash is based on HMAC using SHA1 as the underlying hash.
But I'm not sure why; HMAC adds no additional security over SHA1 for this
application.
|
remmers
|
|
response 5 of 81:
|
Sep 19 13:36 UTC 2006 |
Would a changeover impose a burden on existing users?
|
gull
|
|
response 6 of 81:
|
Sep 19 21:14 UTC 2006 |
It shouldn't. Usually the way something like that works is the old
hash is simply replaced with the new one the next time you change your
password.
|
cross
|
|
response 7 of 81:
|
Sep 20 01:44 UTC 2006 |
Regarding #5; David's got it exactly right in #6. Optionally, to speed up
the process, the login process itself could be instrumented in such a way
that it would detect whether a user is using the grexhash algorithm, and if
so, change to the standard hashing algorithm. After the next reap cycle,
pretty much everyone would be using the standard hash (except for a couple
of long dormant accounts that people are loath to delete. In these cases,
the password could be changed until reactivation was requested by the
owners, or people that know them could gently request that they login to
change their passwords, etc).
I'd be willing to modify login_grexpass (the program that authenticates
users who login via telnet, SSH, ftp, etc) to do this. For the record:
that's also the best way to get users into a Kerberos KDC if that's ever
desired in the future. Marcus's method was insecure, as on the Sun, large
chunks of /etc/shadow ended up in core files that were readable. Marcus's
idea was to import grexhash passwords into the KDC directly, as keys; if
someone had ever run strings on those core files, they'd have the user's
Kerberos key. Clearly not a good thing for that user. But, honestly, it
doesn't really look like grex will ever move to Kerberos, and those who were
most interested in that aren't active anyway.
That's a long way of saying that changing to the standard hash should be
transparent to the users.
|
gull
|
|
response 8 of 81:
|
Sep 21 16:51 UTC 2006 |
To dig under the covers a bit, the reason this works so smoothly is
each password entry has a flag at the beginning that tells crypt()
which hash it's using. That way it can apply the correct hash when
checking the password, even if different users have passwords using
different hashes. For example, a hash that starts with "$1" is using
MD5, and one that starts with "$2" is using Blowfish.
|
cross
|
|
response 9 of 81:
|
Sep 21 19:38 UTC 2006 |
Yes. And the login program has access to the unencrypted password, and can
thus rehash it using a different algorithm.
|
spooked
|
|
response 10 of 81:
|
Sep 21 20:32 UTC 2006 |
Got to love simplicity and standards-compliancy.
|
cross
|
|
response 11 of 81:
|
Sep 22 01:03 UTC 2006 |
Well, so what is the general concensus?
|
gull
|
|
response 12 of 81:
|
Sep 22 02:00 UTC 2006 |
I can't think of a good reason not to do it, and anything that reduces
the amount of nonstandard software that has to be maintained seems like
a winner.
|
naftee
|
|
response 13 of 81:
|
Sep 22 03:04 UTC 2006 |
unlucky
|
cross
|
|
response 14 of 81:
|
Sep 22 03:06 UTC 2006 |
Great! Then...who wants to implement it? I can write the code, but no longer
have access to install it (or even debug it).
|
cross
|
|
response 15 of 81:
|
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.
|
cross
|
|
response 16 of 81:
|
Sep 22 23:03 UTC 2006 |
I have also modified newuser, wnu, and the passwd program to make this
proposed change.
|
cross
|
|
response 17 of 81:
|
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.
|
spooked
|
|
response 18 of 81:
|
Sep 23 02:40 UTC 2006 |
Dan: I have added you to group wheel
Let me know if you need anything further.
|
cross
|
|
response 19 of 81:
|
Sep 23 02:44 UTC 2006 |
Thanks, Mic. Does everyone concur with me doing this?
|
cross
|
|
response 20 of 81:
|
Sep 23 02:57 UTC 2006 |
Well, it appears as though I'm out of wheel again. Hmm.
|
steve
|
|
response 21 of 81:
|
Sep 23 03:06 UTC 2006 |
This will not be done without talking about it!
|
cross
|
|
response 22 of 81:
|
Sep 23 03:18 UTC 2006 |
Very well. That's what this item is for. Let's talk about it. Steve? Your
position?
|
cross
|
|
response 23 of 81:
|
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?
|
steve
|
|
response 24 of 81:
|
Sep 23 07:10 UTC 2006 |
I haven't in the last five days or so, at all. Sorry.
But we have an large problem here, that of a staff person giving
you root access, without prior conversations about it. That you
were once on staff is essentially irrevelant. This issue is not
about trust, eiher. I personally trust that you would not do
anything to hurt Grex. But the issue of changing the hash is not
something I care to do without more people talking about it!
That several staff members aren't reading this item (or conference)
is not a reason to go ahead without consulting others. THAT is
what I am pissed about. The issue of whether or not to make a
change is another matter, which I need more time to think on, and
I think others will say that as well.
|