|
|
| Author |
Message |
| 25 new of 547 responses total. |
jp2
|
|
response 446 of 547:
| 
Oct 18 14:27 UTC 2003 |
This response has been erased.
|
cross
|
|
response 447 of 547:
|
Oct 18 14:46 UTC 2003 |
I've proved the security of grex's password hash to be the same as that
of sha1, which is provably mathematically superior to MD5.
Also, isn't YAPP shareware? I thought you had to pay a significant
amount of money for anything other than casual use?
|
jp2
|
|
response 448 of 547:
|
Oct 18 15:12 UTC 2003 |
This response has been erased.
|
cross
|
|
response 449 of 547:
|
Oct 18 19:06 UTC 2003 |
Blowfish in OpenBSD is pretty slow. I've argued many times that building
our own scrambling algorithm was a bad idea, and I certainly would have
done it differently, but it happened before I came on board. Sorry,
them's the breaks. Sometimes you just have to accept what you're given
and work with it as best you can: we've got anywhere from 20,000 to
40,000 users whose passwords are hashed with it. But, we've also gotten
it working with OpenBSD (I've got it working with login.conf on nextgrex).
Jamie, I think you have a lot of good ideas on how to move grex forward,
but don't blow it by being your polemical self. Three months *is*
a reasonable amount of time for a complete build out of nextgrex.
And I don't care how long it took Salcedo to get mnet up and running.
This isn't mnet, and we want to have an amount of downtown that's a
minimal amount longer than the time it takes to transfer the data from
oldgrex to nextgrex (five weeks just to move things over---now that's
outrageously long, in my opinion). I don't even live anywhere *near*
Ann Arbor (otherwise, I'd volunteer to take in the hardware and crank
away on it over the next two or three weekends), and other staffers
don't have a lot of time, so it's unlikely we'll be able to half the
amount of time I already projected.
As for YAPP, I'm all for it. We need something up and running sooner
than later. However, ``you-think-you-heard-someone-say-maybe'' isn't
a license agreement, and if your primary objection to PicoSpan is a
licensing issue, then trading that can of worms for a mess that is a
verbal licensing agreement for YAPP doesn't seem much better. Now,
if I had my druthers, I'd just as soon see FrontTalk built out and
used as a replacement for both. We're sure of the license for that;
unfortunately, that would require someone talking a lot of time to
make happen, and, as we know, time is an issue.
Look, you're preaching to the choir here. So cut the confrontational
crap and let's figure out how to move forward.
|
jp2
|
|
response 450 of 547:
|
Oct 18 19:16 UTC 2003 |
This response has been erased.
|
glenda
|
|
response 451 of 547:
|
Oct 18 20:19 UTC 2003 |
I would like to see us stay with picospan. I left m-net when they switched
to yapp. I tried it for a couple of weeks, hated it and never logged in
again.
|
jp2
|
|
response 452 of 547:
|
Oct 18 20:29 UTC 2003 |
This response has been erased.
|
jp2
|
|
response 453 of 547:
|
Oct 18 20:39 UTC 2003 |
This response has been erased.
|
jep
|
|
response 454 of 547:
|
Oct 18 21:02 UTC 2003 |
Four and a half months is long enough to wait for one or two formerly
essential people to do what they have apparently promised. If there
are holdups who aren't going to do what Grex needs, then they need to
be replaced. Otherwise, the future of Grex is being held hostage, and
those one or two people are being treated as more important than all
of the rest of us.
I can understand it if no one on the staff wants to state it that
baldly. There seems to be little enough of teamwork for this
project. So there it is, I'll say it.
I have used YAPP for years, and Picospan for years, btw, and have not
noticed any deficiencies in text YAPP. (WebYAPP is horrible, but
Backtalk is available.) Let's put it this way, I'd rather have YAPP
and NextGrex than Picospan and the rotting remains of obsolete Sun
hardware.
|
cross
|
|
response 455 of 547:
|
Oct 18 21:35 UTC 2003 |
Regarding #450; You're making all the same arguments I did. They haven't
worked yet, but I'm willing to transition to another algorithm. It just
takes convincing people that it's the right thing to do. However, the
specific suggestion you make, to use the password expiration feature
to force switching to another algorithm, would take a year (and is also
something I suggested several years ago).
Regarding #451; What specifically didn't you like about it? To me,
they seem functionally equivalent, though I confess to not using any of
the more exotic features of either.
Regarding #454; Okay, that's fair. Btw- it's not just picospan; there are
a number of things that are waiting the laying on of hands of one or two
people. I confess I myself am guilty of stalling on at least one thing.
The way I look at it today, it's silly to try and do anything before
OpenBSD 3.4 comes out on the first of November. Assuming there's going to
be a bit of rough edges around the release, let's say it's reasonable to
assume we can do an FTP install on the 4th or so. From today, that gives
us about three weeks before we can *really* make any software changes.
I propose this: we start the clock for the transition to nextgrex today.
We have the period between now and the 4th of November to argue about how
to do things, and then once November hits, we have two months and one week
to get the new system online, with all of the data transferred, and the
Sun turned off. I feel pretty confident we could make that deadline, and
if someone has a pet project they can't squeeze in before that, too bad.
Comments?
|
cross
|
|
response 456 of 547:
|
Oct 18 21:51 UTC 2003 |
Regarding #448; By the way, the details of the grex password hash, as
well as the details about the configuration of many of the subsystems
on grex, have been publically available for some time through the,
``grex staff notes'' on the web. Indeed, there's even a link to the
code that implements it (using that was how I ported it to nextgrex).
See http://www.cyberspace.org/staffnote/passwd.html, with the actual
code at: http://www.cyberspace.org/staffnote/mkp2.c.
|
jp2
|
|
response 457 of 547:
|
Oct 19 00:09 UTC 2003 |
This response has been erased.
|
cross
|
|
response 458 of 547:
|
Oct 19 03:06 UTC 2003 |
Responding to #457:
(1) No. It has it's own recognizable token that doesn't match $[0-9]+$,
but it's easy enough to switch off. /etc/master.passwd can be put
together with awk or perl. Indeed, I already have a script to do it,
and authentication uses the standard BSD login.conf framework.
There are two possible places to go from here. (a) we move to Kerberos.
This could be done by modifying the password changing program to
automatically register principles using a standard string to key
algorithm, or by using the modified KDC Marcus wants that uses his hash
algorithm, where we'd use the existing contents of /etc/shadow as the
key database. I think the latter is a really bad idea. (b) keep the
same hash algorithm, using the login.conf framework to deal with it.
Okay, there are really three: (c) switch over to one of the system
standard algorithms after a suitable period of time, by modifying the
password changing program to do it. Our customizations would disappear
after a year or so. I favor this route. If we want to go Kerberos,
it'd be best to go with a standard string to key algorithm, but this
would be easy using methods I've already outlined elsewhere, using
login.conf to make them transparant to the user.
(2) That's the equivalent of a site-dependent salt. The idea is that if
the same algorithm is used on more than one site, the hashes shouldn't
come out to be the same.
(3) That's not even the case with conventional cryptography (the algorithm
doesn't get *easier* to crack, it just doesn't get appreciably harder).
Regardless, this isn't conventional cryptography; it's a compression based
hash algorithm. Marcus's password scrambling algorithm is essentially
the HMAC construction applied to password hashing. The thing is,
HMAC doesn't provide any additional security to password hashing over
simple hashing, because it's designed to solve a different problem:
authenticating messages over an insecure network, using a shared secret
key. The thing is, with password hashing, either the key or the message
is fixed, so you don't get any additional security.
(4) That would require a change in the current configuration. But,
there's no point. We have the situation with the password hashing
algorithm well in hand on nextgrex. See (1).
Don't bother arguing about the custom hash algorithm. It was a mistake
(well, sort of. It was better than Unix crypt(3)); everyone knows that.
|
jep
|
|
response 459 of 547:
|
Oct 19 03:28 UTC 2003 |
What reason is there to believe that anything will start on November
4, when it didn't start on May 28? Dan, are you speaking for the
staff?
|
cross
|
|
response 460 of 547:
|
Oct 19 04:37 UTC 2003 |
Regarding #459; No, I'm not speaking for all of staff. I am, however,
speaking for myself as *part* of staff. There is of course a difference,
though my experience tells me that timeline is reasonable if the
rest of staff commits, say, 4 of 5 hours a week to make it happen.
I'm hoping other staff members will chime in here saying either, ``no,
that's completely unreasonable, and here's why...'' or, ``Yes, I think
would could do that.''
My reason for stating that November 4 is a good starting date is that
the next version of OpenBSD *will* be released on the 1st of November,
and therefore it's reasonable to assume the 4th will be a date when most
of the major problems of the release will be worked out, and it would
be feasible to do an install.
|
gelinas
|
|
response 461 of 547:
|
Oct 19 05:50 UTC 2003 |
There is a change in object file format with the next release, if I've
properly understood the discussion. We (staff) have been discussing
when to make the switch, with most wanting to wait for the release that
includes/requires it. So November 1 sounds like a good starting point
to me.
I expect this to be a significant part of the agenda of Wednesday's
staff meeting.
|
gelinas
|
|
response 462 of 547:
|
Oct 19 06:24 UTC 2003 |
On expiring passwords: ssh does not work well with expired passwords.
Blanket expiration of all passwords would cause a lot of trouble.
|
mary
|
|
response 463 of 547:
|
Oct 19 12:05 UTC 2003 |
I'd like to respond to the earlier thread, of how we've gotten to the
point that the move to New Grex has stalled. Because I'm going to name
names and be pretty straightforward here, I'm going to be very clear this
is my opinion and I could be dead wrong on a lot of it.
One of the things that makes Grex so cool is that we are the sum of
volunteer effort. It's also a problem as there really isn't anyone to
call on the carpet when project goals slide. And not only are we
dependent on volunteers but a very few pretty much call the shots for how
anything goes. Partly this is out of respect for their opinions, partly
it's because if the wrong decision is made they are the ones who will have
to clean up the mess. But there is something else working there too, that
I can't quite put into kind words, but it's working against the system as
a whole right now. It can be seen in the difficulty our staff seems to
have working as a team.
We are all at fault for allowing one or two people to be so central to
Grex's future. It's my understanding that Marcus is under a lot of stress
at the moment, dealing with family issues. Been there, done that, but I
was fortunate not to have a community of thousands breathing down my neck
to simultaneously keep their project growing. If Marcus is holding things
up right now it's not Marcus' fault. It's our fault for letting *any one
person* be in the position of being that necessary.
So, where I'm going, is toward a shift in philosophy. We need to not only
move Grex to new hardware but to a way of working that fosters teamwork,
uses software that is team customizable, and where any one person could
walk away and the rest of staff could pick up and carry on. It's way time
this should happen.
I don't think Picospan is going to fit that goal. I'd like to take a
serious look at software that would. It's scary, for sure. It probably
would mean we'd not be too happy until we'd had a chance to mold it to our
specific needs. But the point is we could mold it and the staff and users
would get to decide how. And we'd be far far less dependent on one
person. A win/win after the agony of working though the change.
I'd also like to applaud Jan and other staff, who are working hard to
document exactly what they are doing with New Grex, and looking to
standardize as much of the hardware and software as possible. They are
looking out for us.
|
jep
|
|
response 464 of 547:
|
Oct 19 13:23 UTC 2003 |
Mary, in my opinion, that came off as both tactful and straight. I
don't think I've ever managed to do both at the same time. Nice job.
|
aruba
|
|
response 465 of 547:
|
Oct 19 14:29 UTC 2003 |
I basically agree with Mary here, and like everyone I am frustrated that we
haven't moved forward. I'd like to see some input from more staffers.
|
cross
|
|
response 466 of 547:
|
Oct 19 15:05 UTC 2003 |
Well, there is another issue at play. Replacing Picospan is fine with
me, but what are we going to replace it with? An old version of YAPP is
available in source form, but even mnet doesn't run that, and there are
no indications that it's completely free (as in not paying for it), or
that the new version is available in source form, free, or that we have
any chance of getting a license for it without paying many thousands
of dollars. What alternatives do we have? Is frontalk there yet?
That's the *only* reasonable alternative if getting YAPP doesn't pan out.
|
jp2
|
|
response 467 of 547:
|
Oct 19 21:17 UTC 2003 |
This response has been erased.
|
cross
|
|
response 468 of 547:
|
Oct 19 22:30 UTC 2003 |
What's the email address? I'll send a message asking, but I'm not
convinced it's the right direction.
|
jp2
|
|
response 469 of 547:
|
Oct 19 23:49 UTC 2003 |
This response has been erased.
|
cross
|
|
response 470 of 547:
|
Oct 20 01:09 UTC 2003 |
Okay, I sent an email to that address. We'll see what comes back.
|
