whh@pbhya.PacBell.COM (Wilson Heydt) (11/19/88)
I've been reading the discussions of how to tighten security in the
light of recent events. In particular, the remarks about weaknesses
in the existing password encryption algorithms.
I am puzzled about an omission in the solutions suggested.
As I recall from the supplementary Unix manuals--specifically the
two articles on passowrd security--it is noted that the standard
Unix schemeuses the passowrd as the encryption key on a standard
plaintext. Would it not be a great help in stopping brute-force
attacks to make the plain-text configurable by binary-licnese sites?
Then the attacker would have to either break to the plain text for
each site--difficult enough in itself, restrict itself to some
subset of the possible plaintexts, or generate an implausibly large
dictionary.
Am I off base? Merely out of date? Or has this been (or is this
being) done?
--Hal
=========================================================================
Hal Heydt | "Hafnium plus Holmium is
Analyst, Pacific*Bell | one-point-five, I think."
415-645-7708 | --Dr. Jane Robinson
{att,bellcore,sun,ames,pyramid}!pacbell!pbhya!whh jgreely@banjo.cis.ohio-state.edu (J Greely) (11/20/88)
In article <21670@pbhya.PacBell.COM> whh@pbhya.PacBell.COM (Wilson Heydt) writes: >it is noted that the standard >Unix schemeuses the passowrd as the encryption key on a standard >plaintext. More specifically, the plaintext is 0x0000000000000000, encrypted 25 times with a variant of DES. > Would it not be a great help in stopping brute-force >attacks to make the plain-text configurable by binary-licnese sites? Depends on the attack (see below). All a different plaintext accomplishes is forcing the cracker to recompile his cracker with a new plaintext (and pre-running the initial permutation, for speed). >Then the attacker would have to either break to the plain text for >each site--difficult enough in itself, restrict itself to some >subset of the possible plaintexts, or generate an implausibly large >dictionary. point by point: 1. break the plaintext: trivial to do, if I can read libc.a on your system. Since crypt is a standard library function, the object file is open to anyone who wants it. Your secret plaintext is secret only so long as no one is allowed to use the crypt function. Of course, you can remove crypt.o from libc.a, and hide it somewhere for rebuilding system utilities (which you'll at least need unlinked objects for). Messy, but it does add some security. You *will* be surprised at how many programs use it, though. Oh, and don't forget to shut off world read permissions for any program you link it into. 2. possible plaintexts: 2^64, non-trivial (no kidding). 3. large dictionary: pre-encrypting /usr/dict/words with all of the possible salts uses up just about a gig of disk, (11 bytes per encryption, 4096 salts, 25000 words). Generating this is non- trivial: 102,400,000 encryptions; figure about 5 crypts/second on a Sun 3/50, or 237 days to generate this with one Sun (assuming sufficient disk space). Of course, we have over 200 suns here, reducing that to a very reasonable time. Once I know your plaintext, I have plenty of time to generate passwords. How often do you plan on changing it, remembering that all of your users have to change their passwords every time you change the plaintext? I'll just fill a box of tapes, write your site's name on them, and save them "for later" (half :-)). Did I mention that we've managed a 45% speed improvement in the crypt function (and we're not done speeding it up yet)? >Am I off base? Merely out of date? Or has this been (or is this >being) done? It *is* a good idea, just not easy in practice (particularly for binary sites). -=- J Greely (jgreely@cis.ohio-state.edu; osu-cis!jgreely) "By focusing my awareness upon the void that is beyond 'self', I was able to transcend each humilitation ..." <WHAM!> "...except the one with the saran wrap and the yogurt."
ok@quintus.uucp (Richard A. O'Keefe) (11/20/88)
In article <27987@tut.cis.ohio-state.edu> jgreely@banjo.cis.ohio-state.edu (J Greely) writes: >1. break the plaintext: trivial to do, if I can read libc.a on your > system. Since crypt is a standard library function, the object > file is open to anyone who wants it. Your secret plaintext is > secret only so long as no one is allowed to use the crypt function. > Not so trivial if the revised crypt() is an RPC call to a "crypt server"; then you would need read access to the crypt server code as well. [This would be one occasion when the added cost of an RPC call would be welcome!] A site-configurable plaintext for crypt() sounds nice, but remember what Feynman found out about safes!
jfh@rpp386.Dallas.TX.US (John F. Haugh II) (11/21/88)
In article <27987@tut.cis.ohio-state.edu> jgreely@banjo.cis.ohio-state.edu (J Greely) writes: >point by point: >1. break the plaintext: trivial to do, if I can read libc.a on your > system. Since crypt is a standard library function, the object > file is open to anyone who wants it. Your secret plaintext is > secret only so long as no one is allowed to use the crypt function. No, you can call setkey() from inside of login(1). Then the cracker has to be able to read login(1). If you allow the bad guy to read login, you lose. If you are running shadow password files and you let the bad guy read that, then you lose as well. But in the normal case you would have to be root to read the files, or have physical access to the dump tapes or system console [ to break in at single user ]. Greely is on the right track - you can't just add one feature [ new plaintext ] and expect that to solve all your problems. -- John F. Haugh II +----------Quote of the Week:---------- VoiceNet: (214) 250-3311 Data: -6272 | "Okay, so maybe Berkeley is in north- InterNet: jfh@rpp386.Dallas.TX.US | ern California." -- Henry Spencer UucpNet : <backbone>!killer!rpp386!jfh +--------------------------------------
jgreely@wizard.cis.ohio-state.edu (J Greely) (11/21/88)
In article <8724@rpp386.Dallas.TX.US> jfh@rpp386.Dallas.TX.US writes: >In article <27987@tut.cis.ohio-state.edu> I write: >>1. break the plaintext: trivial to do, if I can read libc.a on your >> system. >No, you can call setkey() from inside of login(1). Then the cracker >has to be able to read login(1). Uh, no. Maybe we're looking at different crypt sources (mine's 4.3 BSD), but setkey has nothing to do with the plaintext, which is initialized to zeros in crypt right *after* the call to setkey. The code basically does this: convert input password to block setkey(block) screw with E-table set block to plaintext (zeros) encrypt(block) repeatedly make it printable and spit it out Calling setkey from login accomplishes nothing. Now, if you added a function set_plaintext(), and called *that* from login, you'd have a chance. But you still can't just change login. You have to change everything else that needs to test passwords, *and* make sure they're all unreadable. (wouldn't you feel silly if you forgot to relink su?) -- J Greely (jgreely@cis.ohio-state.edu; osu-cis!jgreely) Unseen, in the background, Fate was quietly slipping the lead into the boxing glove.
dlm@cuuxb.ATT.COM (Dennis L. Mumaugh) (11/22/88)
In article <716@quintus.UUCP> ok@quintus.UUCP (Richard A. O'Keefe) writes: >Not so trivial if the revised crypt() is an RPC call to a "crypt server"; >then you would need read access to the crypt server code as well. [This >would be one occasion when the added cost of an RPC call would be welcome!] > After battling a recalcitrant NFS system for this last four days, this hits home! You assume that 1). The network is working 2). The RPC and the TCP/UDP underneath are working 3). The RPC server is running and sane 4). The RPC data base is sane. All of the above would be required for one to login. Any one thing wrong and you couln't login. Remember most work stations and general customer machines boot into multi-user automatically and not everybody has diskless workstations. One could not login even as root to fix things. Hmmmmm. Do you plan for a trap door in the code if RPC fails? How about if it is just extremely slow. How do you know the difference [cf. Turing Halting ]? -- =Dennis L. Mumaugh Lisle, IL ...!{att,lll-crg}!cuuxb!dlm OR cuuxb!dlm@arpa.att.com
ok@quintus.uucp (Richard A. O'Keefe) (11/24/88)
In article <2220@cuuxb.ATT.COM> dlm@cuuxb.UUCP (Dennis L. Mumaugh) writes: >After battling a recalcitrant NFS system for this last four days, this >hits home! You assume that > 1). The network is working > 2). The RPC and the TCP/UDP underneath are working > 3). The RPC server is running and sane > 4). The RPC data base is sane. >All of the above would be required for one to login. If they're not working, there isn't a lot of point in _trying_ to log in anyway. If the network isn't working, a disc-less node can't even boot. If RPC isn't working, NFS isn't working, and I can't get at my files. (Even if you particular machine has a disc, if you're on a network you almost certainly want to get at some files which are elsewhere. Think about an Apollo network with NLS.) There is no reason why a password server could not be replicated.
boyd@necisa.necisa.oz (Boyd Roberts) (11/28/88)
In article <741@quintus.UUCP> ok@quintus.UUCP (Richard A. O'Keefe) writes: > >There is no reason why a password server could not be replicated. So, we'll just re-invent YP, again!?! No point doing something badly, when you can get some other mindless jerk to do it _really_ badly. On another issue, aren't the ``automated password'' camp completely off the beam? With that style of password choice there's no point in cracking the _password_. Attack would be focused on the password _generator_ function. Unless, of course, the generator algorithm is at least equally difficult to crack. Enough of this password discussion. Boyd Roberts NEC Information Systems Australia boyd@necisa.necisa.oz ``When the going gets wierd, the weird turn pro...''
ok@quintus.uucp (Richard A. O'Keefe) (11/29/88)
In article <522@necisa.necisa.oz> boyd@necisa.necisa.oz (Boyd Roberts) writes: >In article <741@quintus.UUCP> ok@quintus.UUCP (Richard A. O'Keefe) writes: >>[In reply to a claim that a password server would be vulernable to >> having *one* machine go down.] >>There is no reason why a password server could not be replicated. > >So, we'll just re-invent YP, again!?! No point doing something badly, when >you can get some other mindless jerk to do it _really_ badly. As near as I can figure out, Boyd Roberts appears to be claiming that every new replicated server is "some mindless jerk ... re-invent[ing] YP, again ... _really_ badly". Strange. I thought replicated servers (e.g. name-servers, time-servers) were around before YP was even dreamed of. There was a lot of stuff from Xerox on "registries". Calling a (distributed implementation of) a function remotely isn't *quite* the same as using YP, but let it pass.
bzs@encore.com (Barry Shein) (11/30/88)
>On another issue, aren't the ``automated password'' camp completely off >the beam? With that style of password choice there's no point in >cracking the _password_. Attack would be focused on the password >_generator_ function. Unless, of course, the generator algorithm is >at least equally difficult to crack. > >Boyd Roberts NEC Information Systems Australia I tend to agree with you, now we'll spend the next year or two finding out how non-random the supposedly random password generators are (or perhaps 15 minutes once some evil person exploits the fact...) I believe a change to the passwd program demanding 8 character passwords (perhaps 7 chars, that's an easy thing to calculate) with some reasonable rules to avoid dictionary words etc (like must have at least one punctuation and/or mixed case and/or digits) would be sufficient and people can get back to more important things. In fact easy to remember passwords like: Hey%Jude RunUnix! Lemme+In are quite hard to crack unless you have some reason to guess that sort of thing. People are pretty good generators if someone explains to them what the game is. -Barry Shein, ||Encore||
brian@apollo.COM (Brian Holt) (12/06/88)
In article <2220@cuuxb.ATT.COM> dlm@cuuxb.UUCP (Dennis L. Mumaugh) writes: >In article <716@quintus.UUCP> ok@quintus.UUCP (Richard A. O'Keefe) writes: >>Not so trivial if the revised crypt() is an RPC call to a "crypt server"; >>then you would need read access to the crypt server code as well. [This >>would be one occasion when the added cost of an RPC call would be welcome!] >> >After battling a recalcitrant NFS system for this last four days, this >hits home! You assume that > 1). The network is working > 2). The RPC and the TCP/UDP underneath are working > 3). The RPC server is running and sane > 4). The RPC data base is sane. >All of the above would be required for one to login. Any one >thing wrong and you couln't login. Remember most work stations >and general customer machines boot into multi-user automatically >and not everybody has diskless workstations. One could not login >even as root to fix things. > Another approach to this was detailed in a paper given at the Jan. 1988 Usenix Conference ("A User Account Registration System for a Large (Heterogeneous) UNIX Network"; Pato, Martin and Davis). This details Apollo's new heterogenous distributed registry. It is based on NCS, and runs on Apollo's, Sun's, Vaxen, etc. The idea is to have a distributed, replicated database that is accessed via RPC mechanisms. In addition, a local cache keeps track of verification information for the most recently (most frequently? Not sure) accessed accounts. I don't work on this, I just use it, and it all seems to work well, certainly better than the hassle's I've heard of with other approaches. Please read the paper (it's in the conference proceedings, p. 155) before asking further questions. =brian Here's the abstract (reprinted without permission): Three problem areas arise when considering a user registration system for a large heterogenous distributed computing environment. Large environments demand controls on the complexity of administration. heterogeneitty requires an examination of the notion of identity in the network as well as the interoperability of software on different hosts. Distribution raises the problems of availability, reliabilty and security. Generally available UNIX environments (4.3 BSD and AT&T System V.3) provide few tools for solving these problems. Account administration is typically handled through manual editing of a single /etc/passwd file. Consistency is maintained on multiple machines by periodically copying the /etc/passwd file to each machine in the network. For large networks, with thousands of users and machines, these mechanisms are clumsy and error prone, and they vest too much power in a single system administrator. RGY is a replicated user registration system built on Apollo's portable Network Computing System (NCS). The system consists of a set of daemons which maintain a replicated user registration database. Remote access to the user registration database is provided at each client site through remote procedure calls ina portable subroutine library that replaces the getpwent(3) and getgrent(3) C library calls. Weakly consistent replicatino provides a high degree of availability and reliability. Propagation of individual updates is performaed yielding an inexpensive mechanism for maintaining consistency. Updates are secureely performed using authenticated interfaces, allowing any client site to update the database. -- Internet: brian@apollo.COM UUCP: {decvax,mit-erl,yale}!apollo!brian NETel: Apollo: 508-256-6600 x5694 Home: 617-332-3073 USPS: Apollo Computer, Chelmsford MA Home: 29 Trowbridge St. Newton MA (Copyright 1988 by author. All rights reserved. Free redistribution allowed.)