|
Grex > Garage > #27: 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.
|
| 82 responses total. |
naftee
|
|
response 1 of 82:
|
Sep 14 04:29 UTC 2006 |
moroccan black ?
|
gull
|
|
response 2 of 82:
|
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 82:
|
Sep 18 19:29 UTC 2006 |
Diffie is just not a mayonaisse brand.
|
cross
|
|
response 4 of 82:
|
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 82:
|
Sep 19 13:36 UTC 2006 |
Would a changeover impose a burden on existing users?
|
gull
|
|
response 6 of 82:
|
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 82:
|
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 82:
|
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 82:
|
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 82:
|
Sep 21 20:32 UTC 2006 |
Got to love simplicity and standards-compliancy.
|
cross
|
|
response 11 of 82:
|
Sep 22 01:03 UTC 2006 |
Well, so what is the general concensus?
|