From: Jim S. <ja...@ne...> - 2004-09-21 15:03:43
|
Alex Peshkov wrote: > JIt seems to me that I've described them in my letter - we can't > prevent stealing hashes of passwords (at least for CS on posix). > Current hashes may be relatively easy brutforced on a modern CPUs. > Therefore let's try to make them hard to brutforce. The best way is to > let people use that hashes they trust. Therefore - crypt plugins. Wrong on every count. The SHA hashes are considered by security experts to be secure. SHA-1 produces a 160 bit hash, which is considered unbreakable. It can be broken by iterating through every possible password or lists of possible passwords, but reasonable password security can readily defeat that. The point, however, is that the strength of security is the weakest link, and the hash algorithm is far, far from the weakest link. It is rather pointless to worry about the relative merits of SHA versus MD5 when we're sending passwords in the clear. Any password sniffer installed on any lan through which IP traffic passes can pick up the passwords, so why worry about the hash? The reason that a security architecture is essential is to determine the relative strengths of the links and shore up the weaker. Sure, the existing cypt is a farce and should be replaced with SHA, but the rest of your proposal adds nothing to security and gets in the way of doing it right. > >> I asked before that a security architect be developed and discussed >> before anything was implemented. Without a security architecture, >> how do we know how a smattering of features interplays with other >> work under development? For example, Interbase and Firebird through >> 2.0 use an architecturally unsupportable hack that breaks the >> layering to connect to the security database. It can't be >> implemented in Vulcan. You're adding special semantics for the >> security database. How does it know that it's a security database? > > > It asks class SecurityDatabase about security db-name, and compares > with one to be attached. Vulcan supports any number of security databases. Your scheme is useless in version 3. But since there is no reliable way to compare two Windows filenames (which is the source of endless database corruptions), your scheme doesn't even work in version 2. > >> Why do you care is J. Random User reads a secure hash of a password? >> He can't do anything with it? > > > Appears with exesting hashes - can. It's possible to brutforce them. You might want to do some homework before you make this statement. > >> Trying to hide the hash is completely pointless. > > > Please compare /etc/passwd and /etc/master.passwd in FreeBSD. Are you > sure they do pointless things? We're talking about Firebird here. What FreeBSD may or may not have done has nothing to do with the merits of your proposal. If you have a security analysis, publish it and we'll consider it. Otherwise, write one. > >> Hiding it in an ineffective manner is less than pointless. > > > With some additional work done I can effectively hide them for remote > connections. Is this pointless? If sysadmin wants to hide them > completely, it's enough for him to block local (embedded) connections. Yes, it is pointless. You can't block embedded access if the file can be read. All you can do is make it moderately inconvenient. Don't confuse "inconvenient" with "secure". > >> Without an end to end analysis, plugging perceived holes is dumb. >> The politcally/correct hack was an example of really stupid design, >> as was the silly idea of "encrypting" passwords on the wire. >> Plugging holes usually means little plugs in big holes that do >> nothing to make the entire system more secure. At worst, they are >> ineffective hacks that interfere with future robust security. > > > I tried to avoid mentioned problems, but before discussing something > public, it was necessary (for me) to have a working prototype. > Building it helped me find problems, which I could not even imagine > without this work done. If this is a working prototype, why are you asking whether you can check it in? > >> >> I'm really sorry if it's an inconvenience to write up and present a >> prospective architecture for others to review, but that's the only >> way to make a system secure. >> >> The security architecture is more important that the code. It should >> come first. >> >> I don't want to see any "security" enhancements checked into anything >> until we have had an opportunity to review the big picture first. >> Phasing in a secure hash make sense. I don't see that any of the >> rest makes sense at all. > > > Sorry, it simply doesn't work without other changes. I tried to > explain why, may be I expressed my thought not well enough, but I'd > like to see what real problems this change creates, not only common > words. > I wanted to solve one main problem - give users an ability to use such > hashes for passwords that they want. I think my design solves this > particular problem. I don't know, what addtional problems it may raise > for future security design. Moreover, with hash calculation, moved > from client to server, future security review seems easier - for > example, implementation of auth plugins. No architecture, no implementation. Unless you have an analysis that demonstates, after full discussion, that your proposal increases security, it shouldn't be done. Why not phase out the crypt hash in favor of SHA-1 and skip the rest? -- Jim Starkey Netfrastructure, Inc. 978 526-1376 |