emv@math.lsa.umich.edu (Edward Vielmetti) (06/03/90)
from ftpd(8):
BUGS
The anonymous account is inherently dangerous and should be
avoided when possible.
Despite this dire warning, there are over 500 systems on the internet
which support anonymous FTP. There are known bugs in several versions
of ftpd which allow crackers to break in; word about this spread rather
quickly around some parts of the net just before the internet worm hit.
The worm didn't expose these vulnerabilities, so there's good reason
to believe that some people are still at risk.
ftpd identifies itself in the login banner like so:
220 stag.math.lsa.umich.edu FTP server (Version 5.55 Tue Apr 17 20:44:35 EDT 1990) ready.
so that a potential cracker need only retrieve this one piece of
information to see whether a system might be susceptible to attack.
There's no guarantee that the date in this banner is the actual
date that the code was fixed, nor does the version number seem to
mean much; but if the version is well known the means of entry can
be assured. Any BSD'ish system with a date earlier than the berkeley
fixes posted 10/31/88 and 11/18/88 is an easy target, as are systems
for which vendors have supplied fixes.
I would estimate by a sampling of these banners that one host in 10
that does anonymous FTP is vulnerable.
Some sites keep anonymous FTP directories to be world-writable,
letting any random internet user drop a file in a directory. If you
see a file named GETMONEY.txt, makemoney.doc, or sex-bbs.doc (or
variations on same) in your FTP directory, this is why. It is not
good practice to allow random anonymous users to scribble into
directories; several sensible systems have "upload" or "tmp"
directories for submissions, from which an archive manager will
move files into their real homes. The problem of allowing remote
users to update archives which belong to them should be addressed
with ordinary passworded accounts.
Despite the widespread use of anonymous FTP, the internet RFC's
provide no guidelines to its use or configuration. The conventions
that define anonymous FTP, its risks, and suggestions on how
to set up a good FTP site should be collected in the form of
an RFC on anonymous ftp.
--Ed
Edward Vielmetti, U of Michigan math dept.
emv@math.lsa.umich.educhrome@hscfsas1.harvard.edu (David C. Kovar) (06/03/90)
In article <EMV.90Apr18204600@picasso.math.lsa.umich.edu> emv@math.lsa.umich.edu (Edward Vielmetti) writes: >ftpd identifies itself in the login banner like so: > >220 xxxxxxxxxxxxxxxxxxxxxxx FTP server (Version 5.55 Tue Apr 17 20:44:35 EDT 1990) ready. > I am not up on which versions of FTP are currently vulnerable but it strikes me as quite irresponsible to use actual host names in an example. If nothing else, you're going to get some people FTPing to it just to see what the scoop is. (I just did to see if you really were using an actual example.) I'm all for securing systems, but you've got to be somewhat intelligent about doing it. If posts show up in this newsgroup that cause certain systems to be broken into (ie, by attracting attention to them) then the newsgroup will go away. Worse still, there is a small chance, very small given current laws, that you will be held responsible for any break in caused by your post.
fozzy@caen.engin.umich.edu (Eric Wines) (06/03/90)
In article <2616@husc6.harvard.edu> chrome@hscfsas1.UUCP (David C. Kovar) writes: >In article <EMV.90Apr18204600@picasso.math.lsa.umich.edu> emv@math.lsa.umich.edu (Edward Vielmetti) writes: >>ftpd identifies itself in the login banner like so: >> >>220 xxxxxxxxxxxxxxxxxxxxxxx FTP server (Version 5.55 Tue Apr 17 20:44:35 EDT 1990) ready. >> > > I am not up on which versions of FTP are currently vulnerable but it >strikes me as quite irresponsible to use actual host names in an example. >If nothing else, you're going to get some people FTPing to it just to >see what the scoop is. (I just did to see if you really were using an >actual example.) > I think you are quite wrong. To be on the internet these days your system had better be secure. Your login accounts had better have good passwords, your ftp had better be secure, etc. It would extremely trivial to query every entry in /etc/hosts for ftp version information. If it is really a hole don't you think there are hacker's that have exploited it? Would I be wrong to tell a co-worker that some idiot sysadmin at bozo.com has root wide open without a password (just an example). My company is not on the internet. We may be in the near future. If this is to happen things will have to be *extremely* secure on the machine that connects. I have co-workers who don't really know what the internet is expressing concern about security in the face of the the possibility of connecting to it (from what they here on the news). I think being on the internet is like having a home phone. Anyone can call you at anytime, even at 4AM. You can unplug your phone but that's not really a solution. You can get an answering service for a phone to keep people from bugging you, but for the internet, your system should be secure or you'd better not care.
wisner@hayes.fai.alaska.edu (Bill Wisner) (06/03/90)
chrome@hscfsas1.harvard.edu (David C. Kovar) writes: > it >strikes me as quite irresponsible to use actual host names in an example. He goes on to warn: > Worse still, there is a small chance, >very small given current laws, that you will be held responsible for >any break in caused by your post. Chill out, Dave. Ed used his *own machine* as an example. Really. Bill Wisner <wisner@hayes.fai.alaska.edu> Gryphon Gang Fairbanks AK 99775 "Wisner, you're scum." -- Matt Crawford <matt@oddjob.uchicago.edu>
mrc@Tomobiki-Cho.CAC.Washington.EDU (Mark Crispin) (06/03/90)
In article <EMV.90Apr18204600@picasso.math.lsa.umich.edu> emv@math.lsa.umich.edu (Edward Vielmetti) writes: >Despite the widespread use of anonymous FTP, the internet RFC's >provide no guidelines to its use or configuration. The conventions >that define anonymous FTP, its risks, and suggestions on how >to set up a good FTP site should be collected in the form of >an RFC on anonymous ftp. Just as a matter of history, on Tenex and TOPS-20, userid ANONYMOUS could only write to the PS:<ANONYMOUS> directory (its home directory). ANONYMOUS could only read files that were on PS:<ANONYMOUS>, group- accessible to ANONYMOUS (generally never done), or world-readable. Furthermore, passwords were never stored in any file readable by any user, even in encrypted form. The only way to read a password in any form (including encrypted) was to do a privileged system call. Anyone who could do this system call had already broken security (had the equivalent of root). The operations which required passwords were system calls which took the user's attempted password in plaintext. The encryption algorithm was in the operating system and there was no specific function to return the encrypted form of a password (although with enough effort someone could find out what the encryption algorithm was). Failed password attempts were counted, and an excessive failure rate was cause to bump the user off the system. Many systems considered *all* password attempts to be failures at some point before the bump-off point, so even a valid password would fail. It worked pretty well. Most Tenex/TOPS-20 sites had warm fuzzy feelings about allowing ANONYMOUS and never had any security problems because of it. There are lessons to be learned, starting with the abolishment of /etc/passwd and user access to the encryption algorithm. _____ | ____ ___|___ /__ Mark Crispin Atheist & Proud _|_|_ -|- || __|__ / / 6158 Lariat Loop NE R90/6 pilot |_|_|_| |\-++- |===| / / Bainbridge Island, WA "Gaijin! Gaijin!" --|-- /| |||| |___| /\ USA 98110-2098 "Gaijin ha doko ka?" /|\ | |/\| _______ / \ +1 (206) 842-2385 "Niichan ha gaijin." / | \ | |__| / \ / \ mrc@CAC.Washington.EDU "Chigau. Gaijin ja nai. kisha no kisha ga kisha de kisha-shita Omae ha gaijin darou." sumomo mo momo, momo mo momo, momo ni mo iroiro aru "Iie, boku ha nihonjin." uraniwa ni wa niwa, niwa ni wa niwa niwatori ga iru "Souka. Yappari gaijin!"
zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff) (06/03/90)
All this emphasis on turning off tftp and waiting for shadow password files may be clouding the simpler and more effective solution. Force users to pick good passwords! Something with some non-alpha characters and mixed case (not the first letter capital). Neither turning off tfpd or even shadow passwords will protect you from local users or people who used to have root.
imp@dancer.Solbourne.COM (Warner Losh) (06/03/90)
In article <6703@blake.acs.washington.edu> mrc@Tomobiki-Cho.CAC.Washington.EDU (Mark Crispin) writes: >... There are lessons to be learned, starting with the >abolishment of /etc/passwd and user access to the encryption >algorithm. Sorry. There are too may passwd files out there to do this. Shadow files might help, but then again they might not. The algorithm for password encryption is well known and available via anonymous ftp from many site. Even if it wasn't, you'd have to put something like this into the kernel, and we all know that /vmunix is world readable. That and a good disassembler would totally defeat whatever you just gained.... What is needed is a good guide to how to setup anonymous FTP correctly so that nobody can steal any real files. Also, while we're on the subject: Remember what tftp gives the known universe. Access to all world readable files. Turn it off or restrict it at your site if you are connected to anything resembling the ineternet. In article <1990Apr20.192233.4092@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: >Ah yes, good old security-through-obscurity. Where have we heard that >before? And it doesn't work. Never has, never will. The only people that you will catch by this are the people too lazy to be inventive. And those are the people least likely to crack your system anyway. >If OSI is the answer, what on >Earth could be the question?? You really don't want to know .... :-) -- Warner Losh imp@solbourne.com Excuse me sir, this is a spot check. Can we see your clue please?
davidsen@sixhub.UUCP (Wm E. Davidsen Jr) (06/03/90)
In article <1990Apr20.192233.4092@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: | In article <6703@blake.acs.washington.edu> mrc@Tomobiki-Cho.CAC.Washington.EDU (Mark Crispin) writes: | >... There are lessons to be learned, starting with the | >abolishment of /etc/passwd and user access to the encryption | >algorithm. | | Ah yes, good old security-through-obscurity. Where have we heard that | before? I don't know that I have any objections to shadow password. WHy give the show away? It's like having L.sys or Systems world readable. I accept that I can't keep the encryption a secret, so why give the encrypted passwords away. I don't see what this has to do with security-through-obscurity here. -- bill davidsen - davidsen@sixhub.uucp (uunet!crdgw1!sixhub!davidsen) sysop *IX BBS and Public Access UNIX moderator of comp.binaries.ibm.pc and 80386 mailing list "Stupidity, like virtue, is its own reward" -me
davidsen@sixhub.UUCP (Wm E. Davidsen Jr) (06/03/90)
In article <6721@blake.acs.washington.edu> mrc@Tomobiki-Cho.CAC.Washington.EDU (Mark Crispin) writes: | We are talking about no "setuid" | programs; in its place are new unprivileged system calls which make | the necessary checks. That's nice in the far future, but I'll take what I have and understand, carefully used. I'm perfectly content to have user programs use setuid (not to root, thanks) to control access to things like databases and other user owned resources. I think you could get a few good theses from thrying to design something better than having the owner of the resource provide a setuid program to provide access. The problem has been that vendors have been to cheap, lazy, or incompetent to provide services by means other than using setuid root for things. I regard about 30% of what most vendors do as being the result of lazyness (not that this implies a security hole in that many cases, but a lack of elegance). -- bill davidsen - davidsen@sixhub.uucp (uunet!crdgw1!sixhub!davidsen) sysop *IX BBS and Public Access UNIX moderator of comp.binaries.ibm.pc and 80386 mailing list "Stupidity, like virtue, is its own reward" -me
emv@math.lsa.umich.edu (Edward Vielmetti) (06/03/90)
In article <EMV.90Apr18204600@picasso.math.lsa.umich.edu> I wrote:
from ftpd(8):
BUGS
The anonymous account is inherently dangerous and should be
avoided when possible.
I would estimate by a sampling of these banners that one host in 10
that does anonymous FTP is vulnerable.
You log on to an anonymous FTP site and notice that their FTP appears
vulnerable. What do you do?
1. nothing.
2. break in and do something nasty.
3. contact the system manager and let them know what's wrong.
4. break in and leave a note to the system manager to let them
know what's wrong.
5. break in, leave a note to the system manager to let them know
what's wrong, and install a fix.
6. notify CERT and ask for further guidance.
Option 1 is easy, option 2 also. Option 3 requires tracking down a
person in charge, as worst you send mail to postmaster. I won't
recommend options 4 or 5, though I suspect that exercising them
a couple of times would trigger option 6.
Suggestions on the wording of the message to the system manager
welcomed.
--Ed
Edward Vielmetti, U of Michigan math dept.
emv@math.lsa.umich.edufozzy@caen.engin.umich.edu (Eric Wines) (06/03/90)
In article <2672@husc6.harvard.edu> kovar@popvax.uucp (David C. Kovar) writes: >In article <1990Apr19.205930.15589@caen.engin.umich.edu> fozzy@caen.engin.umich.edu (Eric Wines) writes: >>I think you are quite wrong. To be on the internet these days your >>system had better be secure. Your login accounts had better have good >>passwords, your ftp had better be secure, etc. It would extremely trivial >>to query every entry in /etc/hosts for ftp version information. >>If it is really a hole don't you think there are hacker's that have >>exploited it? >> Would I be wrong to tell a co-worker that some idiot sysadmin at bozo.com >>has root wide open without a password (just an example). > > So, if in the course of my normal, legal wanderings around the Internet >I find that your machine has a security flaw I should immediately post >to alt.security saying "Machine X has a security flaw Y and this is how >you exploit it?" I sincerely hope that this is not what you mean. Of course not. I wouldn't suggest that you should point out specific flaws at specific sites. When discussing something like ftp, I don't think it's a big deal to pick a host at random out of /etc/hosts and use it as an example. Obviously you're not going to mention how to crack the host. Showing the login information and saying something like "this version of ftp is three years old, people are still running old versions of ftp and many of these are not entirely secure" just isn't a big deal to me. Pointing out an excellent example of a well known hole that has been ignored by a large (?) number of sites is a good thing. > Yes, you should keep your machine as secure as possible if you're going >to attached yourself to a public network. I've no problems at all with >that. But if you discover a hole in my system and tell everyone else before >you tell me about it, I am going to be quite upset. And, if breaking into >my system is illegal, and you are party to an illegal act by passing >on that information, then you've also just broken the law. I think you're stretching things a bit. Certainly a list of systems and their security weaknesses isn't going to be posted (well, at least not on Usenet. I'm sure it's common on BBS's with cracking information). I think it would be very interesting to write some shell scripts to gather *statistical* information about fairly blatant security weaknesses on internet hosts, but I'm sure not going to do it.
shenkin@cunixf.cc.columbia.edu (Peter S. Shenkin) (06/03/90)
In article <PMY$TW?@b-tech.uucp> zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff) writes: >All this emphasis on turning off tftp and waiting for shadow password >files may be clouding the simpler and more effective solution. Force >users to pick good passwords! Something with some non-alpha >characters and mixed case (not the first letter capital). This suggestion has been mentioned many times on the net, but it also has a problem. If passwords are non-mnemonic, unpronounceable and non-suggestive (as all "good" passwords are), then they are easy for users to forget; not daily users, but occasional users, such as, say, a biology graduate student who logs on once a month to do a DNA sequence search. Such users often constitute the vast majority of users on departmental systems. These users then *WRITE DOWN* their passwords, compromising security differently, but perhaps as severely, as is now the case. For a while I had an account on a VMS system which, in the interest of security, expired my password periodically, and required me to change it. I mostly used a UNIX system, but had to log into the MicroVAX occasionally to access a connected array processor; I was an occasional user. Keeping track of my password became such a pain that for a while I wrote it down and kept it in an unobrusive place, though I didn't like doing that. Evenually I discovered that I could change it, then change it right back to the usual, and the machine wouldn't complain. I felt a bit guilty putting something over on the poor machine, but I feel I saved it from itself. Its security measures were actually compromising security. Not that I have answers.... -P. ************************f*u*cn*rd*ths*u*cn*gt*a*gd*jb************************** Peter S. Shenkin, Department of Chemistry, Barnard College, New York, NY 10027 (212)854-1418 shenkin@cunixc.cc.columbia.edu(Internet) shenkin@cunixc(Bitnet) ***"In scenic New York... where the third world is only a subway ride away."***
ken@cs.rochester.edu (Ken Yap) (06/04/90)
In article <1990Jun3.152118.4758@cunixf.cc.columbia.edu>: |In article <PMY$TW?@b-tech.uucp> zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff) writes: |>All this emphasis on turning off tftp and waiting for shadow password |>files may be clouding the simpler and more effective solution. Force |>users to pick good passwords! Something with some non-alpha |>characters and mixed case (not the first letter capital). | |This suggestion has been mentioned many times on the net, but it also has |a problem. If passwords are non-mnemonic, unpronounceable and non-suggestive |(as all "good" passwords are), then they are easy for users to forget; not I once read a good suggestion for choosing a mnemonic, yet hard to guess password: take a catchy phrase and turn it into an acronym, capitalizing and inserting punctuation as necessary. For example "Hey man, don't have a cow" becomes Hm,dhac. I can't take credit (or blame :-)) for this, I wish I remember the poster who suggested this. If you are out there, take a bow. Don't blame me if everybody chooses a Simpsons phrase... :-)
jfh@rpp386.cactus.org (John F. Haugh II) (06/04/90)
In article <PMY$TW?@b-tech.uucp> zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff) writes: >All this emphasis on turning off tftp and waiting for shadow password >files may be clouding the simpler and more effective solution. Force >users to pick good passwords! Something with some non-alpha >characters and mixed case (not the first letter capital). Using "good" passwords is meaningless without some control over the encrypted passwords, because as sure as the sun rises in the east, people write down "good" passwords. On the other hand, permitting crappy passwords and protecting the access to the encrypted crappy password can be secure if the number of possible trials per unit time is sufficiently small. A common feature of many [ including mine ] enhanced login schemes is a limit to the number of consecutive failures, which limits the number of failing login attempts on a port to a very small number per unit time, while not increasing [ by way of using excessively complex computation scams ] the time to login successfully. Another feature is to limit the number of failed attempts on an account before the account is turned off. Given this setup using the shadow login code I posted last year, % faillog -u root -p -u jfh -p Username Failures Maximum Latest root 0 0 Sat May 26 13:49:38 1990 on tty1A jfh 1 1000 Mon Jun 4 07:57:21 1990 on tty01 my account will be expired after 1,000 failures. After 1,000 failed trials the bad guy will no longer be able to know whether the password is good or bad. If I were extremely paranoid I could lower this value to 10 or so and use trivial english words such as "Cat" or "Dog" without too much concern. On my system the maximum failed login rate is on the order of 6 per minute through the modems. This is a factor 10,000 slower than estimates of PCs, which many have stated at being near 1,000 per second. However, since I control the access to my encrypted passwords, the problem is serialized at my machine, while someone is perfectly free to employ two or more other machines to parallelize the problem in an unprotected environment. Moral of the story, pester your vendor for shadow password support ... -- John F. Haugh II UUCP: ...!cs.utexas.edu!rpp386!jfh Ma Bell: (512) 832-8832 Domain: jfh@rpp386.cactus.org Proud Pilot of RS/6000 Serial #1472
richard@pegasus.com (Richard Foulk) (06/05/90)
>>Ah yes, good old security-through-obscurity. Where have we heard that >>before? > >And it doesn't work. Never has, never will. The only people that you >will catch by this are the people too lazy to be inventive. And those >are the people least likely to crack your system anyway. But, there are probably alot more of the "too lazy to be inventive" types around. "Security-thourgh-obscurity" certainly isn't great. But I haven't seen or heard of any evidence that it's totally useless. Multiple layers of security would seem to be better than one "perfect" barrier. -- Richard Foulk richard@pegasus.com
jfh@rpp386.cactus.org (John F. Haugh II) (06/06/90)
In article <1990Jun5.002739.16450@pegasus.com> richard@pegasus.com (Richard Foulk) writes: >"Security-thourgh-obscurity" certainly isn't great. But I haven't seen >or heard of any evidence that it's totally useless. The most common example of "Security Through Obscurity" is hiding the password encryption algorithm. Read "Password Management Guidelines" from the NCSC [ or Dod ] [ it is one of the green books in the rainbow series ] for information on why this is a bad idea. Other "obscurity" techniques have similiar problems. -- John F. Haugh II UUCP: ...!cs.utexas.edu!rpp386!jfh Ma Bell: (512) 832-8832 Domain: jfh@rpp386.cactus.org Proud Pilot of RS/6000 Serial #1472
brnstnd@stealth.acf.nyu.edu (06/06/90)
In article <PMY$TW?@b-tech.uucp> zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff) writes: > All this emphasis on turning off tftp and waiting for shadow password > files may be clouding the simpler and more effective solution. Force > users to pick good passwords! Something with some non-alpha > characters and mixed case (not the first letter capital). Oh, wonderful. Changing 3 bits of information per character to 3.2 bits per character will slow down the average ``crack'' from fifteen million encryptions to forty million encryptions. Big deal. ---Dan
brnstnd@stealth.acf.nyu.edu (06/06/90)
In article <1990Jun3.152118.4758@cunixf.cc.columbia.edu> shenkin@cunixf.cc.columbia.edu (Peter S. Shenkin) writes: [ if passwords are ``good,'' they'll be written down ] > Not that I have answers.... I have an answer, which I posted to alt.security a few weeks ago but which was obliterated by cmcl2's alt.* distribution. Here's another copy. ---Dan From: brnstnd@stealth.acf.nyu.edu Newsgroups: alt.security Subject: How to get the advantages of all types of passwords Message-ID: <11082:May1722:49:4990@stealth.acf.nyu.edu> Date: 17 May 90 22:49:49 GMT References: <1990May3.211534.11818@Solbourne.COM> <iLmNi7w161w@halcyon.wa.com> <1990May9.185628.9241@utzoo.uucp> Reply-To: brnstnd@stealth.acf.nyu.edu (Dan Bernstein) Organization: IR Lines: 23 X-Original-Subject: Re: Improved password cracker - add a sleep() User-chosen passwords are easily guessable. Random system-generated passwords are written down all too often. Expired passwords have been shown to make password guessing easier, and they don't provide any advantage. What's the solution? Mix 'n' match. A password has, say, two parts: one chosen by the user and neither expired nor restricted, one generated randomly by the system and changed periodically (some sizable fraction of a year). The first part is NEVER written down; users are told that if they write down the first part, they'll be drawn and quartered. The second part is almost certainly written down, typically on a piece of paper in the user's desk; users are explicitly told that this is okay. Because the first part of the password is chosen by the user and never written down, a casual cracker can't find it by just snooping around an office. Because the second part of the password is chosen by the system, brute-force cracking will fail miserably. I proposed this last year (in u-w) but never saw much response. ---Dan
greywolf@unisoft.UUCP (The Grey Wolf) (06/07/90)
In article <PMY$TW?@b-tech.uucp> zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff) writes: >All this emphasis on turning off tftp and waiting for shadow password >files may be clouding the simpler and more effective solution. Force >users to pick good passwords! Something with some non-alpha >characters and mixed case (not the first letter capital). > >Neither turning off tfpd or even shadow passwords will protect you from >local users or people who used to have root. I'm rather new to some of this stuff, so please excuse my ignorance. To what extent does one disable tftp (or did the original user mean anonymous ftp)? If, indeed, one disables tftp, why is this done? tftp is about the only way to boot a machine over the network if one needs to reformat the local disk, and we don't have QIC drives or 9-track drives for every machine, and hooking them up/disconnecting them is a pain in the ass. I'd much rather not have to move the workstation if I can avoid it. Please don't flame me about hardware or the inadequacies of our setup; it would be a waste of time and it would completely beg the question. -- MORALITY IS THE BIGGEST DETRIMENT TO OPEN COMMUNICATION. /earth: minimum percentage of free space changes from 10% to 0% should optimize for space^H^H^H^H^Hintelligence with minfree < 10%
jfh@rpp386.cactus.org (John F. Haugh II) (06/07/90)
In article <19105:Jun616:44:3190@stealth.acf.nyu.edu>, brnstnd@stealth.acf.nyu.edu writes: > Because the first part of the password is chosen by the user and never > written down, a casual cracker can't find it by just snooping around an > office. Because the second part of the password is chosen by the system, > brute-force cracking will fail miserably. The flaw in your assumption is the sentence "Because the second part of the password is chosen by the system, brute-force cracking will fail miserably." The problem is that the "hard" part is permitted to be written down anywheres, or even encouraged to. This reduces the problem to finding out the "easy" part of the password. If this system uses two separate passwords, each given in turn, I try cracking the "easy" password whenever prompted, since I am always able to respond with the "hard" password I just found written on your desk blotter. If this system interweaves the two parts, I try cracking by starting with the "hard" part and interweaving my guesses. This is only comlicated by the number of possible positions my "easy" part can be interwoven into. I would presume that avoiding too much complication would greatly limit the number of positions, further weakening this scheme. > I proposed this last year (in u-w) but never saw much response. I hope you like my response ;-) -- John F. Haugh II UUCP: ...!cs.utexas.edu!rpp386!jfh Ma Bell: (512) 832-8832 Domain: jfh@rpp386.cactus.org Proud Pilot of RS/6000 Serial #1472
kayvan@mrspoc.Transact.COM (Kayvan Sylvan) (06/08/90)
>>>>> "brnstnd" == brnstnd <brnstnd@stealth.acf.nyu.edu> writes: brnstnd> What's the solution? Mix 'n' match. A password has, say, two brnstnd> parts: one chosen by the user and neither expired nor brnstnd> restricted, one generated randomly by the system and changed brnstnd> periodically (some sizable fraction of a year). The first brnstnd> part is NEVER written down; users are told that if they write brnstnd> down the first part, they'll be drawn and quartered. The brnstnd> second part is almost certainly written down, typically on a brnstnd> piece of paper in the user's desk; users are explicitly told brnstnd> that this is okay. Hmmm... Interesting. If the paper on which the second part is written down is kept locked up (or otherwise is inaccesible to random snooping), then it jut might work. ---Kayvan -- | Kayvan Sylvan @ Transact Software, Inc. -*- Los Altos, CA (415) 961-6112 | | Internet: kayvan@{mrspoc.Transact.com, eris.berkeley.edu, largo.ig.com} | | UUCP: ...!{apple,pyramid,bionet,mips}!mrspoc!kayvan "Imagine Cute Saying" |