41 new of 81 responses total.
Nothing. The source is BSD licensed, and at least in the opinion of the author, is a mathematical algorithm that embodies no novel, unique, or unbvious principles.
I think it makes as good as no difference which password hash we are running. I'm astonished that anyone would feel strongly enough about it to want to change it or even discuss it very much. I'm OK with changing it. I'm OK with leaving it alone. We do clearly need to work on decision processes though. My comments on the root grant appear in the coop conference.
re #42 I'm astonished that anyone would feel strongly enough about it to want to change it or even discuss it very much. I'm kinda the opposite. I'm surprised people are upset that it was suggested and brought up as a possible "update" when the argument in favor was fairly concise and makes sense. Standards are not evil. If someone has the time to standardize bits of the system and nobody gets injured or denied system access then what is the harm? I'd rather see the staff foster a relationship of interest and improvement rather than one that harbors distrust while embracing a stagnant mindset.
Regarding #42; That's why I think it should be changed: it makes little difference security wise, yet we have to maintain it. If we moved to the standard, we'd be just as secure, and not have to maintain custom changes to the system. And I think Todd's comments in #43 stand well.
Eventually, there could be a compromise somewhere that allows for system improvements to be formal. Ideally, these improvements would be the kind that are not denied unless proof of obvious DoS or degradation occurs as a result. Will that happen on Grex? I seriously doubt it.
Then you end up with arguments over what an "improvement" is. Marcus clearly sees his algorithm as an improvement over anything that comes with the operating system (whether for technical reasons or not). I see going standard as an improvement over what we've got now. Who wins?
Patch management is one of those things where if it isn't obvious whether you're updates are improvements then you should do a risk assessment. I'd venture to guess that staying on older or non-standard modules would be a higher risk.
I agree. I think that's a good way to look at it.
At the board meeting last night Marcus suggested that the sensible time to start a transition to a standard password algorithm would be in the course of the next upgrade to a new version of OpenBSD. (He was not exactly advocating such a change, but he wasn't opposing it either, just suggesting the best way to do it.) I think that makes sense. You really want to have the system off-line while you do this, so you can confirm that new and old passwords are working right before letting users loose on them. During the system upgrade is a period when we will be working on the password system anyway. The change is absolutely non-urgent, so I don't see much reason to do it before then. Why impose extra down time over this? So I guess that's what I'm advocating at this point. During the next OS version upgrade, we install the patches to enable authenticating with Marcus's passwords, but have new passwords be created with a standard hash. By the time of the upgrade after that, we should be able to drop the Marcus stuff entirely and use a stock authentication system. When is the next OS upgrade due anyway? We are on 3.8 now. Looks like 4.0 is about to be released. But it doesn't look to me like 4.0 is a major step. It looks more like 4.0 was the next number after 3.9. I don't know. Looks like we are getting into the time range where an OS upgrade would be reasonable to do, but not yet critical.
The change is absolutely non-urgent, so I don't see much reason to do it before then. How about: "Why not?" If there are staff folks willing to perform upgrades or implement standards then why stop them? If a major upgrade or emergency is the prerequisite for module improvements then lets simply state it so nobody gets too invested in the garage conference in discussions under false pretenses.
Regarding #49; I think that's sensible, though another couple of points I'd throw out are that (a) this doesn't necessarily involve any downtime, and (b) there's nothing that says you can't put the pieces in slowly. For instance, the current login code handles both OpenBSD's native password format and grex's. We could modify (potentially) plop in the new version of newuser at any time with no effect on existing users at all. Similarly, the passwd command could be put in at any time. The changes to wnu were just to the Makefile (to get it to link against some the stuff I added to newuser to support the OpenBSD hash format). That could be done at any time. A potential plan could be to pick the least frequently used of these commands, put it in, watch for trouble for a few weeks, move in the next least-frequently used command, watch for trouble, etc. The slight advantage over doing it all during an upgrade is that *if* there's a problem and the changes need to be backed out (and it's not discovered during the upgrade itself) you aren't stuck backing everything out at the same time. I also agree with Todd that it's not *so* risky as to be undoable before the next upgrade. I'd champion the middle ground, piecemeal approach, so that it could be backed out at the first sign of trouble.
re #51 I'd champion the middle ground, piecemeal approach, so that it could be backed out at the first sign of trouble. I'm betting anything you suggest "fixing" will get the kebosh if it has any vested ego behind it.
It's up to them to prove you wrong.
re #53 Yes, I'm baiting. Thanks for waving your arms and jumping on the pier.
You lost me, coach.
My feeling is that altering the login routine to change hashes is an unnecessary complication. If you just set passwd up to use the standard hash, normal password expiration will eventually get us switched over. (Assuming passwords still expire...come to think of it, mine hasn't in a while.)
They don't; I think password expiration got turned off with the move to OpenBSD on the i386.
So, Steve said we won't do this without discussion. Marcus posted some comments but hasn't responded to the latest round of responses. Where do people sit with this?
It goes into the Grex Process, where people talk it to death until everyone loses interest, and eventually it's let slide unless some kind of disaster happens. This is very similar to the Seattle Process, which is how transportation issues are managed here in the Pacific Northwest.
How true.
re #59 The light rail is on track but I know what you mean if you're referring to the viaduct.
I was about to laugh... but, then I realised this is really quite sad cause it could not be more true.
Re resp:61: The viaduct, the 520 bridge, the monorail...take your pick.
Too true Now if only the Army Corps of Engineers would step up to replace the Viaduct since they originally made it and if Nicholls and the Seattle circus would keep their noses out of roadway decisions then... Monorail should be strictly a mayor's call, imo
An interesting discussion with Solar Designer, the author of the ``John the Ripper'' software cracker. He discusses password security and the OpenBSD bcrypt algorithm. http://www.securityfocus.com/columnists/388/2
As I read over my responses, I'm amazed by the number of typos I make.
Btw- as an experiment, I grafted support for grexhash into John the Ripper. It was pretty easy; it took about an hour. Also, regarding OpenBSD upgrades: OpenBSD only supports upgrades between consecutive releases; grex is running OpenBSD 3.8 now. To do a supported upgrade, it would have to upgrade to OpenBSD 3.9 and then to 4.0. I don't think skipping releases is a particularly good idea.
So this was proposed over a month ago, and serious discussion stopped about that long ago. What's the deal?
that's GreX for you :(
Yeah, it is. Sad.
*sings* Time keeps on slippin... into the future....
I implemented this about a month ago. We now have the majority of grex users using bcrypt'ed passwords.
As of right now, all but 15 or so users are using bcrypt'ed passwords. Had we plugged this in back in September, it would be down to three or four.
yup, made me login :-P
Welcome back! :-)
We're down to exactly one user using the grexhash system. If we can get that user to login, we can safely eliminate the custom hashing code in the coming upgrade.
That might be me. I just tried to change mine, but it won't let me. I get 'passwd: Permission denied.'
No, it's not you, but the problem with changing your password is almost certainly that you have a custom PATH that doesn't include /suid/bin before /usr/bin.
Looks like the problem is my path includes /usr/local/bin before /suid/bin. I'm not sure how that's happening. I don't set PATH in my .profile.
Hmm; that's actually right.
Okay, there's a wrapper script in /usr/local/bin that had the path to the real password changing utility incorrect. I have corrected it.
You have several choices: