51 new of 81 responses total.
so; if we can bring marcus watts back from the deep unknown, do you think we can resurrect dave thaler ?
Dunno. It'd certainly be nice if he open-sourced yapp....
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.
Marcus, you're the one who brought up MD5, not me. I'm just pointing out that it's the default in OpenBSD and giving pointers to more information about it so that others can go look for themselves. I don't know what you knowing the designer of bcrypt has to do with any of it. It would be trivial to plug your algorithm into John the Ripper - the source code is there. (For those that don't know, John the Ripper is a password cracking program: it takes a dictionary of words, permutes them in simple ways [adding numbers and the like], hashes them, and compares them to hashed passwords. If they match, you know the original password. This is essentially how the login scheme works already, it's just throwing a whole slew of passwords at it shotgun-style to see if you can find one or two that work.) That your hash is not in the basic distribution just means script kiddies won't crack grexhash'ed passwords. But then, script kiddies aren't likely to be able to get to the grexhash'ed passwords anyway; someone who can will likely be able to do the tiny amount of work to get a version of John (or crack, or whatever) running that *will* handle grexhash'ed passwords. That a version of John the Ripper exists that compares against bcrypt'ed passwords doesn't imply that there's a weakness in bcrypt itself; no known weaknesses have been found in the crypto. I'm sure you knew that that was what I meant, so I'm not sure where you were going with that. If someone is attacking it via a brute force, offline dictionary attack, and that's the best they can do, then that means things are working the way they should be. Certainly, grex should not move to an experimental version of Kerberos or anything else. We need solid, mainstream, production software here. If the decision is made to move to Kerberos at some point, it would be far easier to instrument the login_passwd program and passwd to add principles to a Kerberos database than take the hashed passwords out of /etc/master.passwd and use them as Kerberos 5 keys. Surely, using a string value from *any* file on grex as a key would be a bad idea. If you're assuming bcrypt is bad, on the basis that attackers will be able run John against it, then how can you possibly justify using any variant of the same hashed string as a cryptographic key? Now, is the main point of your argument that we're better off not changing because your hash is obscure? How is it secure? If someone can get to the contents of /etc/master.passwd (or the db file) then they've already compromised grex. At that point, it would be easier for them to add a password sniffer than run crack against the password file. Of course there are times when individual staff effort should be commended. I believe I said your hash was a win on the Sun. But there are also times when decisions should be re-evaluated in the face of changing environments. I don't think that's perverse, I don't think it should piss people off, nor is that what I trying to. I don't see how that's "endlessly debating" things. In fact, so far, you're the *only* person who has voiced objection to changing the hash algorithm. What, then, is contentious, and why? If you, by your own statement, are not attached to this hashing algorithm, then why are you so upset about the question? And I've never called into question your expertise. I don't think name calling and implied questions about mine are called for. But, for the record, I learned crypto from Michael Rabin. Are there those that know more about it than me? Certainly. But what does that have to do with the current discussion?
(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.)
Provos and AFS chest thumping. Holy cow. What next: Pushup contests? re #34 But then, script kiddies aren't likely to be able to get to the grexhash'ed passwords anyway Then why do you care? Grex doesn't have to be obscure unless its only about job security for folks like yourself. Your rant was transparent, Marcus.
STeve, why does Marcus seem to think this was talked about "over, over, and over" yet you seem to think nothing was discussed? Which is it, gents? I'm also amused that Marcus is talking about 1) pissing off staff and, 2) concensus building; yet, nobody seems to agree with neither STeve or mdw on how things are being conducted. Black box, anybody?
Regarding #36; Are you referring to Marcus or me? I wrote #34, which you quoted, but you mention Marcus by name. The reason I care is that I don't think grex should be maintaining customizations when reasonable standard alternatives exist (Provos didn't design the bcrypt algorithm, by the way, someone at MIT did. He just implemented it. Perhaps they collaborated; I don't really know.)
Marcus is probably referring to conversations from several years ago. It's interesting that Marcus seems to be against my proposal, yet his argument almost supports it. In particular, he speaks about how organizations as small as grex shouldn't rely on any single individual to keep them running. That would imply, in cases like this, sticking as close to the standard software distribution as possible. It would certainly rule out things like experimental Kerberos servers that would almost certainly require the originator to maintain (unless someone were to invest quite a bit of effort into it). I'm not at all sure I followed the rest of his argument; the last time this came up for discussion was nearly two years ago, when grex moved to this machine. It's hardly been under continuous debate since then. At the time, the decision to leave the custom hash in place was made in order to facilitate allowing Marcus to plug in his modified KDC. But Marcus only logged into grex two or three times in the ensuing two years (his recent logins seem to coincide with this discussion), and given how the staff climate has changed over that time, it seems reasonable to re-open the issue.
What happens if Marcus sells his proprietary custom password hash to The Well?
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: