tom.jennings@f111.n125.z1.FIDONET.ORG (tom jennings) (05/30/91)
Getting lists of high-privilege passwords to systems is all too easy.
Here's one method that was used a few years ago in the BBS world. It
doesn't reply on technics so it will still work today.
It's 1985. The hint that something was wrong was hearing of bizarre
behavior from otherwise rational, well known people. Stolen software,
crashing systems, etc. The kind of thing when you here it, you doubt
the teller of the story. The stories persisted however, over a period
of a few months.
Finally after a series of incidents (I forget particulars -- but it
involved crashed/formatted drives, that sort of maliciousness) as
frequently happens the perpetrator did one-too-many and their scam
collapsed. The unravelling was convoluted and I don't remember it so
I'll tell it unravelled:
This person set up a BBS, advertised it well on other BBSs, enticing
them with the usual attractions. A few months later the BBS
dissapeared, a very common occurrance.
Some interval after that is when the trouble began.
When his BBS was up, as is customary each caller entered their name,
password, other info. Relying on the fact that most people are lazy
and use very few different passwords on the systems they call, he
looked through his caller file and picked out the names of other
sysops and well-known & respected callers. He then called other BBSs
and tried to login as some of them. Some fraction of them worked.
It was and is typical for sysops to give other sysops very high
privileges on their own systems. I do this now with one or two people.
It's a common practice.
So he hit the occasional jackpot -- full system privileges on one or
two (maybe more) other systems. Then he downloaded *those* caller
files. (The beginning of the end was a sysop finding a caller-file
download in a log.) Using the same method of calling other BBSs he was
able to get a very strong cross-list of sysop names and hi-priv
passwords.
MOST IMPORTANTLY -- if he hadn't been so stupid, he could have had a
powerful source of information probably for years, undetectable until
someone looked, and he could have even edited log files. Lucky for us
he got greedy and stupid and caught. You can draw your own conclusions!
--
tom jennings - via FidoNet node 1:125/777
UUCP: ...!uunet!hoptoad!fidogate!111!tom.jennings
INTERNET: tom.jennings@f111.n125.z1.FIDONET.ORGkarn@epic..bellcore.com (Phil R. Karn) (06/03/91)
I have been working on a scheme that would thwart the attack just mentioned here. It's called "MINK". MINK is a one-time-password scheme that uses an iterated one-way function. (We're currently using the MD-4 cryptographic hash function as the basis of the one-way function.) Each time you log in, the password you send over the wire is different. You precompute the series of passwords by running your "real" (secret) password through the one way function using local, trusted computer hardware. Then you use the sequence you just created in REVERSE ORDER. E.g., if you start by generating a list of 100 iterated passwords, you first use password #100, then password #99 the next time you log in, and so on. The system you're logging onto verifies your identity by running your new password through the one way function once and comparing the result to the password you sent the last time you logged in. If they match, the password you just sent replaces the entry in the password file for next time. When the iteration count goes to zero, you reinitialize the system after you log in by picking a new password, running it through the one-way function 100 times, and sending that to the system. If the one-way function is fast enough, you don't have to actually precompute the list of one-time passwords; you can run the proper number of iterations "on the fly" each time you log in. Our MD-4 based function is fast enough on the PC to allow this. All this makes it impossible for someone eavesdropping on you as you log in to determine the next password to use, since that would require inverting the one-way function. If your passwords are well chosen (i.e., if they're not found by the usual dictionary searches) then even the password file on the host system would be useless to an attacker. This would have helped considerably in the case of the "evil BBS sysop". Phil
patrick@chinet.chi.il.us (Patrick A. Townson) (06/03/91)
In article <14715.2845348B@fidogate.FIDONET.ORG> tom.jennings@f111. n125.z1.FIDONET.ORG (tom jennings) writes: > Getting lists of high-privilege passwords to systems is all too easy. > Here's one method that was used a few years ago in the BBS world. It > doesn't reply on technics so it will still work today. > It's 1985. The hint that something was wrong was hearing of bizarre > behavior from otherwise rational, well known people. Stolen software, > crashing systems, etc. The kind of thing when you here it, you doubt > the teller of the story. The stories persisted however, over a period > of a few months. The keyword here is the year, 1985. You must remember that the BBS world was just starting to come out of its infancy. A lot of the guys who started systems in the early 1980's were very naive in their assumptions and expectations about their fellow users. Many were/had been ham radio operators, a good-neighbor type of person willing to share his knowledge and ability freely with others. People were just getting into 'home computers'. I've been into BBS'ing and home computers since 1979, and 1977 respectively, but most folks were not in it that early. My first regular use of a terminal connected to a computer mainframe was 1968, when it was still relatively unheard of. The BBS' were originally a way to share tech information among users, and everyone was friendly and eager to help the new people, ala ham radio, other hobbyist groups with a technical bent to them. Passwords and a lot of security were considered unfriendly. Requiring a user to register in advance, be verified, and *then* start using the BBS was unheard of ... after all, everyone's just trying to help out, no one was on line to cause harm, etc. Then the discussion boards came along. Bill Blue, with his PMS (People's Message System) software was a good example of this. In the license to use PMS, he *flatly forbade* the use of passwords and pre-registration to get on line. The software did have a file of regular users, but this was to mark where they had been reading and to automatically configure the software for them each time they called as a convenience. Bill Blue's one concession to the real world was that 'unregistered users', i.e. the ones not in the aforementioned file, had their messages run through an obscenity checker prior to posting. And I don't mean to single him out ... his package was quite sophisticated and one of the best BBS packages of the era. But his mentality was so common, so prevalent in those days: come one, come all; everyone welcome cause we are all giving a helping hand; we don't question your motives in being here, etc. I helped sysop a PMS board for awhile and suggested that users should register their name, address and phone number in *private* records at the site so that they could be contacted in the event of a problem, a special event, etc ... and to prevent the possibility of an abusive message going out under their name. I caught hell for even thinking about it! All the usual excuses were presented including the all time great one: "This would chill their freedom of speech if they had to make themselves known, etc ..." Some users even thought the sysop had no right knowing who they were or how to contact them!! The sysop might not be trusted, etc. Well, you old-timers know the routine, all the stories, the mentality which pervaded that whole period ... And that is the attitude we were just starting to get weened away from by the middle 1980's ... I operated a BBS on an Apple 2+ for three years (1983-85) and had the same bunch of clowns trying to break in, pleading ignorance and copping an attitude when you caught them ... It took a lot of sysops getting burned badly; a lot of users getting defrauded by other users, etc before finally the consensus by most responsible sysops was to begin closing the doors and requiring passwords and verification, etc. And it took awhile before users began to realize that having one password on every system was no different than having all your locks keyed to one master key ... lose it and everything is up for grabs. > When his BBS was up, as is customary each caller entered their name, > password, other info. Relying on the fact that most people are lazy > and use very few different passwords on the systems they call, he > looked through his caller file and picked out the names of other > sysops and well-known & respected callers. He then called other BBSs > and tried to login as some of them. Some fraction of them worked. Yeah, well if he had tried this about 1980-82, a much larger fraction would have worked ... in those days everyone had only one password for the few systems which required them at all. > It was and is typical for sysops to give other sysops very high > privileges on their own systems. I do this now with one or two people. > It's a common practice. There is no reason under the sun to give anyone privileges *that high*. Consider TBBS, with the various degrees of authority ... regular users having 10 or 15, assistant sysops and managers of the individual SIGS getting around 25 or so ... and the sysop getting 255. You can give your friends 'very high privileges' on TBBS and still give them less than 255. And at unix sites where I have an account, I would not want such privileges given to me, mainly to avoid the possibility of accusations being made later. A couple of sites I frequent (other than chinet and eecs) have offered to give me root privileges on a 'need to use it' basis, to deal with a problem on line in the middle of the night, etc ... but then some fraud/vandalism would occur and I would get blamed! Or do you give your close friends keys to your house and your bank deposit box as well? > So he hit the occasional jackpot -- full system privileges on one or > two (maybe more) other systems. Then he downloaded *those* caller > files. (The beginning of the end was a sysop finding a caller-file > download in a log.) Using the same method of calling other BBSs he was > able to get a very strong cross-list of sysop names and hi-priv > passwords. Well again, in *those days*, sysops were considered something special and different, only trying to be a good neighbor, etc ad nauseum. Some sysops are as rotten to the core as many users, although there are more of the latter. The vast majority of both categories are decent, fine people. > You can draw your own conclusions. Yes you can. It cannot be stressed enough that passwords need to be changed frequently, and be difficult to guess or force. It is also important that the sysop keep accurate records of users, and have recourse to each one. Nothing cuts through the hacking and cracking as fast as a sysop knowing who is on line. A user identified is a user who does not make trouble. Anytime a sysop can pick up the phone and call a user to ask "why would you have posted the message you did when you were on line today", the sysop has one less user to worry about. -- Patrick Townson patrick@chinet.chi.il.us / ptownson@eecs.nwu.edu / US Mail: 60690-1570 FIDO: 115/743 / AT&T Mail: 529-6378 (!ptownson) / MCI Mail: 222-4956
louisg@vpnet.chi.il.us (Louis Giliberto) (06/03/91)
In article <1991Jun02.215724.25764@chinet.chi.il.us> patrick@chinet.chi.il.us (Patrick A. Townson) writes: > >A user identified is a user who does not make trouble. Anytime a sysop can >pick up the phone and call a user to ask "why would you have posted the >message you did when you were on line today", the sysop has one less user >to worry about. > Yes, I agree with Mr. Townson completely. However, it can work both ways. When I call a BBS, I call with the philosophy that if I wish to use the sysop's system, I abide by his rules. If I don't want to abide by the rules, I call another system. Fair enough I think. However, there still are many good BBS's that don't validate users, don't have u/d quotas, etc. These primarily work since they are basically monitored by the users themselves. If someone breaks "protocol", the other users usually bash him before the sysop needs to take action. After repeated bashings, the loser usually goes away. If you really think about it, USENET is much this way. Most often, other news readers are the ones who say "that does not belong here" etc. There are some idiots, but for the most part it works rather well. Again, I agree with Pat, but I thought I'd balance his statement by saying that it is still possible to run a BBS system the old fashioned way. The only problem with this is the new question of sysop responsibility. Louis Giliberto louisg@vpnet.chi.il.us -- --------------------------------------------------------------------------- ! "As above, so below; as below, so above" -- The Kybalion ! ! "I don't trust him; he has dark hair" -- My girlfriend's mother ! ! "So I'm stupid; what's your point?" -- Me !
learn@ddsw1.MCS.COM (William Vajk) (06/04/91)
In article <1991Jun03.071209.2319@vpnet.chi.il.us> Louis Giliberto writes: >In article <1991Jun02.215724.25764@chinet.chi.il.us> Patrick A. Townson writes: >>A user identified is a user who does not make trouble. Anytime a sysop can >>pick up the phone and call a user to ask "why would you have posted the >>message you did when you were on line today", the sysop has one less user >>to worry about. >Yes, I agree with Mr. Townson completely. One would like to think so, but this still is no assurance, as events at igloo proved to me. Assuming you have thus created a system with all honest and forthright users doesn't mean that someone of lesser ethical standards wasn't, at some point, watching over some user's shoulder. The results were a disaster for me. Bill Vajk
toad@cellar.UUCP (Tony Shepps) (06/05/91)
louisg@vpnet.chi.il.us (Louis Giliberto) writes: > However, there still are many good BBS's that don't validate users, don't hav > u/d quotas, etc. These primarily work since they are basically monitored by > the users themselves. If someone breaks "protocol", the other users usually > bash him before the sysop needs to take action. After repeated bashings, the > loser usually goes away. This follows a serious "given" that a lot of BBS sysops have forgotten. For electronic communities that are primarily message-oriented, it's the USERS who ultimately define the systems, not the sysops. A sysop can go a long way to provide a good atmosphere for discussion, to provide quality BBS software, and to help the users whenever possible. But the bottom line remains: if quality callers continue to use the system, the system will prosper. Our message-oriented, multi-line system has been running for a mere eight months, but we have had little to no trouble with crackers and/or abusers. I wonder why? We don't voice validate; and we don't have a strict set of rules. But maybe that's partly why the crackers don't come after us in droves. To them, we appear reasonable. We allow handles and we don't hit new users with a list of DON'Ts on their opening call. I like to think we've gotten the user base we like merely by using proper grammar, offering goodies and quality software, and a dose of intellect in our opening screens. We are friendly, open, and intellectual, and so are our users. Coincidence? > If you really think about it, USENET is much this way. Exactly; and count Prodigy as an example of a system with a lot of rules, with a sysop (i.e. management) that doesn't understand that it's the users who ultimately define the system. I'm not disagreeing with Pat's original statements, and I'd guess that the probability of successfully operating a more open system is dependent on the nature of the electronic communities in the area, just as it would be foolish to run something on the honor system in the streets of NYC. ---------------------------------------------------------------------------- - Tony Shepps toad@cellar.UUCP (...uunet!cellar!toad) Not a problem. - - The Cellar BBS +1 215 336 9503 Reliable hardware, responsible sysops, - - and lin# noise is nev~r a prob{{{[3~[3~[3~[3~[3~[3~[3~ NO CARRIER
zane@ddsw1.MCS.COM (Sameer Parekh) (06/06/91)
You have a nice method, but bringing it into public usage will be hell. -- The Ravings of the Insane Maniac Sameer Parekh -- zane@ddsw1.MCS.COM
rogue@cellar.UUCP (Rache McGregor) (06/06/91)
karn@epic..bellcore.com (Phil R. Karn) writes: > Each time you log in, the password you send over the wire is > different. You precompute the series of passwords by running your > "real" (secret) password through the one way function using local, > trusted computer hardware. Then you use the sequence you just created > in REVERSE ORDER. E.g., if you start by generating a list of 100 > iterated passwords, you first use password #100, then password #99 the > next time you log in, and so on. The system you're logging onto > verifies your identity by running your new password through the one > way function once and comparing the result to the password you sent > the last time you logged in. If they match, the password you just sent > replaces the entry in the password file for next time. Unfortunately, such a scheme undoubtedly requires the user to keep a written list of passwords, the easiest bane to security that ever existed. Rachel K. McGregor : Let the fire be your friend a/k/a Rogue Winter : And the sea rock you gently rogue@cellar.uucp : Let the moon light your way {tredysvr,uunet}!cellar!rogue : 'Til the wind sets you free -Shriekback
tom.jennings@f111.n125.z1.FIDONET.ORG (tom jennings) (06/06/91)
r In article <14715.2845348B@fidogate.FIDONET.ORG> tom.jennings@f111. n125.z1.FIDONET.ORG (tom jennings) writes: >>> Getting lists of high-privilege passwords to systems is all too easy. >>> Here's one method that was used a few years ago in the BBS world. It >>> doesn't reply on technics so it will still work today. > The keyword here is the year, 1985. You must remember that the BBS world ... > Passwords and a lot of security were considered unfriendly. Requiring a ... > Some users even thought the sysop had no right knowing who they were or > how to contact them!! The sysop might not be trusted, etc. I have no arguments with this. The scam would still work, was my only point. Today, in 1991, to implement the scam, I'd simply do what other sysops do -- verify! The end result -- I'd still have their passwords! All I meant by "Draw your won conclusions" was simply that using the same password on all or many systems is a bad idea. >>> It was and is typical for sysops to give other sysops very high >>> privileges on their own systems. I do this now with one or two people. >>> It's a common practice. > There is no reason under the sun to give anyone privileges *that high*. A rather broad statement ... as a matter of fact I can think of lots of reasons. Doesnt matter, it was merely to illustrate the kinda goodies you could get via this scam. > Or do you give your close friends keys to your house and your bank deposit > box as well? Yes, as a matter of fact. (Not the bank box though! :-) There are 6 of us in our semi-cooperative household, and at least 20 other people have keys, and are welcome to come in at any time even if we are not here and make themselves welcome. (Possible realities == one per second per human at least. :-) >>> You can draw your own conclusions. > Yes you can. It cannot be stressed enough that passwords need to be > changed frequently, and be difficult to guess or force. It is also I totally agree. I still cheat once in a while. :-) > A user identified is a user who does not make trouble. Anytime a sysop can > pick up the phone and call a user to ask "why would you have posted the > message you did when you were on line today", the sysop has one less user > to worry about. Yeeow! Thought police! Do I have to pee in a jar? Will you hold it? -- tom jennings - via FidoNet node 1:125/777 UUCP: ...!uunet!hoptoad!fidogate!111!tom.jennings INTERNET: tom.jennings@f111.n125.z1.FIDONET.ORG
new@ee.udel.edu (Darren New) (06/07/91)
In article <g0F431w164w@cellar.UUCP> rogue@cellar.UUCP (Rache McGregor) writes: >Unfortunately, such a scheme undoubtedly requires the user to keep a written >list of passwords, the easiest bane to security that ever existed. Actually, there are two times when this works well. One is if the user is in a secure place calling another secure place over insecure connections. For example, a military installation connecting to another military installation over the internet, or a home user calling a bbs. Presumedly, in these cases, the physical security of the list of passwords is greater than the security of the communication channel. The other situation where this can work well is if a "token" computer is used to generate the passwords. This can be a credit-card sized computer with a small number of keys and a small display which can calculate the proper password. Of course, the physical security of this password-computer is important, but could be guarded in much the same way that ATM cards are guarded. "We have the technology. We can rebuild..." -- Darren -- --- Darren New --- Grad Student --- CIS --- Univ. of Delaware --- ----- Network Protocols, Graphics, Programming Languages, FDTs ----- +=+ Nails work better than screws, when both are driven with hammers +=+
david.turrell@f111.n125.z1.FIDONET.ORG (david turrell) (06/07/91)
On June 2, 1991, Patrick A. Townson writes: >A couple of sites I frequent [...] have offered to give me root privileges on >a 'need to use it' basis, to deal with a problem on line in the middle of the >night, etc ... but then some fraud/vandalism would occur and I would get >blamed! It's been stressed to me that even "root" should use his/her highest privilege as infrequently as possible, to reduce the possibility of an "virus" monitoring password entry and gaining root privileges itself. The ideal policy is for the superuser/sysop to log in at the lowest level possible which still allows for completion of any work that needs to be done. This advice was meant for large, shared systems, which is what PC's are becoming. >It cannot be stressed enough that passwords need to be >changed frequently, and be difficult to guess or force. I've gotten away without changing my passwords all that often, although I closely watch accounts where I pay *money*, which allows me to quickly detect abuses. I think the best part of your advice is about making passwords difficult to guess. Passwords made of random characters are too hard to memorize; but I would avoid using the word "wizard" and the names of characters in popular computer fantasy games and science fiction. I remember a WYLBUR system whose teletypes echoed the password. After typing a "mask" of G's on top of W's on top of M's. Then people left the printout lying around; didn't even bother to throw it away when they left. -David -- david turrell - via FidoNet node 1:125/777 UUCP: ...!uunet!hoptoad!fidogate!111!david.turrell INTERNET: david.turrell@f111.n125.z1.FIDONET.ORG
ptownson@eecs.nwu.edu (Patrick A. Townson) (06/09/91)
In article <14885.284ECCAC@fidogate.FIDONET.ORG> tom.jennings@f111.n125.z1.FIDONET.ORG (tom jennings) writes: >> A user identified is a user who does not make trouble. Anytime a >> sysop can pick up the phone and call a user to ask "why would you >> have posted the message you did when you were on line today", the >> sysop has one less user to worry about. > Yeeow! Thought police! > Do I have to pee in a jar? Will you hold it? Don't say something stupid like that. The one has nothing to do with the other. People should be able to post what they want within the general parameters the BBS has established for its users. No sysop who is trying to run a fair and open dialogue for his users is going to harass someone based on the *content* of their speech. But if you are going to say a sysop has no right to even know who is making which speeches *he* (sysop) might be held accountable for, then all I can say is god bless you and run your BBS however you like. You still seem to have some confusion in your own mind about the difference between free speech and the use of other people's property to make your speech. Have it your own way, Sir. If you feel happier comparing the whole thing to drug testing, then do that. Patrick T.
alan@ukpoit.co.uk (Alan Barclay) (06/12/91)
In article <55643@nigel.ee.udel.edu> new@ee.udel.edu (Darren New) writes: [On the security aspects of password token computers] >which can calculate the proper password. Of course, the physical >security of this password-computer is important, but could be >guarded in much the same way that ATM cards are guarded. Ah, you mean badly. -- Alan Barclay iT | E-mail : alan@ukpoit.uucp Barker Lane | BANG-STYLE : .....!ukc!ukpoit!alan CHESTERFIELD S40 1DY | VOICE : +44 246 214241
karn@epic.bellcore.com (Phil R. Karn) (06/13/91)
In article <14906.28501E22@fidogate.FIDONET.ORG>, david.turrell@f111.n125.z1.FIDONET.ORG (david turrell) writes: |> I remember a WYLBUR system whose teletypes echoed the password. After typing a |> "mask" of G's on top of W's on top of M's. Then people left the printout lying |> around; didn't even bother to throw it away when they left. |> Yes, back at Cornell in the middle 70's I demonstrated a similar attack against VM/CMS passwords. As a typical IBM mainframe system, VM/CMS operated in half duplex (virtual 2741 mode), so it had no way of directing a terminal to suppress echo as a password was typed in. So a series of overstruck characters were printed as part of the prompt in an attempt to mask the password. I'm not sure now, but I think the characters were S, M and *. Printing terminals, particularly the dot-matrix kind (Decwriters and Silent 700-class thermal printers) were of course the standard in those days. I noticed that a few dots in the matrix were left unhit by the mask characters in the font used by at least one dot matrix printer (the NCR terminal in my room, used by many other members of my fraternity, including one with system programmer privileges). Given a "masked" password from the trash I discovered I could easily narrow down the possible letters for each position within the password by examining the matrix dot positions left clear by the password mask. Since the passwords were only four characters long to begin with, it didn't take long to determine the right one by trial and error. Phil
karn@epic.bellcore.com (Phil R. Karn) (06/13/91)
In article <g0F431w164w@cellar.UUCP>, rogue@cellar.UUCP (Rache McGregor) writes: |> karn@epic..bellcore.com (Phil R. Karn) writes: |> [description of my MINK one-time-password scheme deleted] |> Unfortunately, such a scheme undoubtedly requires the user to keep a written |> list of passwords, the easiest bane to security that ever existed. No, it does not. "Pre-computing" a list of one-time passwords on paper is only one way MINK can be used, and it is not the one I prefer. I generally compute my one-time passwords only as I need them with a local, trusted computer. The remote system gives me the seed and the current iteration count, which I then type into my local program. The local program then prompts for my secret password and produces the current one-time password. The one-way function takes no more than a second or two to iterate 100 times, even on a slow 4.77 MHz 80C88 machine such as the Atari Portfolio, small enough to carry in your briefcase. Most of the time I just use my laptop to do the computation since I'm usually already using it as my terminal. Occasionally at a conference where public email facilities are provided (e.g., USENIX, Interop or IETF) I will pre-compute a few one-time passwords in my hotel room and write them down in my notebook in order to save lugging my laptop or Atari around. Once these passwords have been used, they're useless. If one were to be stolen before I had used it, I would quickly discover that fact the next time I attempted to log in as the system would ask me for a later one-time password than I was expecting. In the ideal case, of course, the local portion of MINK would be built into your Telnet or terminal program, making it totally automatic. The user would type his or her secret password just as though it were going across the wire, but it would be intercepted by the local program and used to generate the current one-time password. Phil
karn@epic.bellcore.com (Phil R. Karn) (06/13/91)
In article <DPASSAGE.91Jun12150630@soda.berkeley.edu>, dpassage@soda.berkeley.edu (David G. Paschich) writes: |> This security scheme, while better than the standard UNIX stuff, still |> rests on the security of the user's "secret password". It doesn't |> protect against a user choosing a stupid password. Yes, you are absolutely right. But any "what you know" authentication scheme that relies on a secret user-chosen password will also have this problem. The only currently practical alternative is a "what you have" scheme (e.g., smart cards) which have problems of their own (cost of the devices, user resistance, possible compromise of stolen cards depending on their design, etc). Phil
dpassage@soda.berkeley.edu (David G. Paschich) (06/13/91)
In article <1991Jun12.194910.9095@bellcore.bellcore.com> karn@epic.bellcore.com (Phil R. Karn) writes:
No, it does not. "Pre-computing" a list of one-time passwords on paper
is only one way MINK can be used, and it is not the one I prefer. I
generally compute my one-time passwords only as I need them with a
local, trusted computer. The remote system gives me the seed and the
current iteration count, which I then type into my local program. The
local program then prompts for my secret password and produces the
current one-time password.
[stuff deleted by dgp]
In the ideal case, of course, the local portion of MINK would be built
into your Telnet or terminal program, making it totally automatic.
The user would type his or her secret password just as though it were
going across the wire, but it would be intercepted by the local program
and used to generate the current one-time password.
This security scheme, while better than the standard UNIX stuff, still
rests on the security of the user's "secret password". It doesn't
protect against a user choosing a stupid password. I find that on the
system I run, far more accounts are broken into by using the account's
name as the password than by dictionary attacks. (Which are also
still possible under this scheme, given the fact that the remote
system provides the iteration count and the random seed, just a lot
easier to detect, since the only way to check the generated password
is to try to log in with it.)
Don't get me wrong; I realize that this is still an improvement in the
state of the art, and that password technologies will only ever stay a
few years (at most) ahead of cracking technologies. Just pointing out
that it's not perfect.
--
David G. Paschich Open Computing Facility UC Berkeley
dpassage@ocf.berkeley.edu
"But I'd rather be a fish, 'cause a fish is an animal" -- Gener Foxjerry.andrews@f111.n125.z1.FIDONET.ORG (jerry andrews) (06/14/91)
All your points are well-taken; I'd like to add one sysop's experience,
though.
I've been running computer-based conversations systems since 1979.
The first was a grafiti (sic) file on a campus mainframe, and that was
followed by several systems until I settled on a TBBS system in 1983.
I've been with TBBS ever since.
I have always required registration. I have never (not once) had an
abuse severe enough to require locking out a user. It seems that the
simple process of filling out the registration form is enough to
discourage most malicious users. TBBS's security is tough enough that
crashing and cracking haven't been a problem, and the occasional
abusive message I can usually handle with a single message in private.
In the period from about '83 to about '86, I did notice a lot more
attempts to crash my board. Thanks to the robust nature of the
software, I don't think it was ever done (though the board did crash
for sometimes unexplained reasons). That has settled down a lot.
Be well.
--
jerry andrews - via FidoNet node 1:125/777
UUCP: ...!uunet!hoptoad!fidogate!111!jerry.andrews
INTERNET: jerry.andrews@f111.n125.z1.FIDONET.ORG