dlm@cuuxb.ATT.COM (Dennis L. Mumaugh) (12/17/88)
The latest copy of the USENIX Journal has an article worth reading:
%A Matt Bishop
%T An Application of a Fast Data Encryption Standard Implementation
%J Computing Systems
%I The USENIX Association
%V 1
%N 3
%P 221-254
%D Summer 1988
%O The University of California Press
%X The Data Encryption Standard is used as a basis for the UNIX
password encryption scheme. Some of the security of that scheme
depends on the speed of the implementation. This paper presents a
mathematical formulation of a fast implementation of the DES in
software, discusses how the mathematics can be translated into code,
and then analyzes the UNIX password scheme to show how these results
can be used to implement it. Experimental results are provided for
several computers to show that the given method speeds up computation
of a password by roughly 20 times (depending on the specific
computer).
This paper shows how to improve the speed of DES and can also show how
to improve breaking DES.
As far as UNIX passwords, it further justifies the use of a shadow
password file and the use of 64 character pass phrases.
--
=Dennis L. Mumaugh
Lisle, IL ...!{att,lll-crg}!cuuxb!dlm OR cuuxb!dlm@arpa.att.combzs@Encore.COM (Barry Shein) (12/18/88)
>As far as UNIX passwords, it further justifies the use of a shadow >password file and the use of 64 character pass phrases. > >-- >=Dennis L. Mumaugh Why? Because it shows a 20x speedup possibility? Let's do the arithmetic again... Given a 100 character character set and 8 characters in a password the search space is 100^8 which is: 10,000,000,000,000,000 Currently even fast DES implementations on fast processors can't seem to hit 1,000 encryptions per second although it's probably possible, let's allow 20,000 encryptions per second, a brute force search would now take: 500,000,000,000 500 billion seconds or almost 16,000 years. Even improving *that* by a factor of 1,000 (ie. 20,000,000 encryptions per second) wouldn't leave much hope for the cracker (16 continuous machine-years.) Drop down to a 64 character set and we get a search space of: 281,474,976,710,656 which still takes 450 years to search completely at 20,000 encryptions per second (even using arguments which say on average one only has to search half the space this isn't too encouraging to a cracker.) Improving by 1,000 further (a highly improbable event in the near future) still reduces this to 6 months absolute dedicated machine time on a machine or machine configuration (eg. parallel) which makes a Cray-3 look like $4.99 pocket calculator. If someone has access to those kinds of resources and wants into your account they can hire a small army and hijack your computer much cheaper and less visably. Let's face it folks, at these fantastic rates the following methods would be far more effective: 1. Have a dirty tricks agency plant a video camera in your office ceiling which transmits images of you keying in your password. 2. Tap your network. 3. Bribe key personnel in your area to get whatever it is they really want. 4. Purchase your company, even AT&T. Dennis, without further justification for your position/conclusion I claim you're grasping for straws and succumbing to mob mentality. -Barry Shein, ||Encore||
beb@mit-amt (Brian E Bradley) (12/18/88)
Documents released under the Freedom of Information Act reveal that, starting in the late 1950's, the NSA was able to "read" the keyclicks of a typist and know what was typed. There are a couple of dozen more tricks that even I, as a civilian, are aware of. Let's face it: if someone is so eager to spy on you or break in that they're willing to spend lots of money on it, you probably can't prevent it. The best you can hope for is to catch them in the act and feed them false or misleading information. But if your work is drab, boring, useless, or commonplace, rest easy: they probably won't be interested.
pcg@aber-cs.UUCP (Piercarlo Grandi) (12/19/88)
In article <4420@xenna.Encore.COM> bzs@Encore.COM (Barry Shein) writes:
# >As far as UNIX passwords, it further justifies the use of a shadow
# >password file and the use of 64 character pass phrases.
#
# Why? Because it shows a 20x speedup possibility? Let's do the
# arithmetic again...
#
# [ .... some reassuring arithmetic that DES can't be compromised .... ]
It takes a lot to properly answer your posting. Let me say, as numerous other
posters will be better able to point out, that there are *many* ways to skin
a DES.
Even by looking at the non classified, non restricted papers on encryption
available, it is clear that breaking a 56 bit key (especially if educated
guesses at the potential boundaries on the actual keyspace are made) is not
that terribly hard, e.g. by probabilistic techniques...
In particular, UNIX password deciphering, where a number of *clever* (whereas
you assume brute force) attack techniques have been devised, is now regarded
by some as affordable to anybody with large but not truly extraordinary
resources.
# Let's face it folks, at these fantastic rates the following methods
# would be far more effective:
#
# [ .... the traditional, most effective ways of breaking security .... ]
Breaking DES text in general is still quite hard, enough so that cipher
breaking is indeed not going to be the weak link in a software+hardware+network security chain.
# Dennis, without further justification for your position/conclusion I
# claim you're grasping for straws and succumbing to mob mentality.
Still, I think that Dennis is not grasping for straws. The most feared
danger with any cryptographic technique is that somebody will come up with a
clever theorem or a clever hack that chips away at your assumptions about how
hard it is to do certain things. This paper in this respect is ominous.
Another fact (reliable hearsay actually) that ought to send shivers thru the
back of security people is that a 100 decimal digits numbers has been factored
without too much fuss. Look into comp.parallel...
--
Piercarlo "Peter" Grandi INET: pcg@cs.aber.ac.uk
Sw.Eng. Group, Dept. of Computer Science UUCP: ...!mcvax!ukc!aber-cs!pcg
UCW, Penglais, Aberystwyth, WALES SY23 3BZ (UK)jbuck@epimass.EPI.COM (Joe Buck) (12/20/88)
Dennis Mumaugh writes: >>As far as UNIX passwords, it further justifies the use of a shadow >>password file and the use of 64 character pass phrases. In article <4420@xenna.Encore.COM> bzs@Encore.COM (Barry Shein) writes: >Why? Because it shows a 20x speedup possibility? Let's do the >arithmetic again... >Given a 100 character character set and 8 characters in a password >the search space is 100^8 which is 10,000,000,000,000,000 Irrelevant, because not all passwords are equally probable. The Internet worm broke large numbers of accounts by using about five guesses obtained from the user's line in the password file, and broke quite a few more using a list of about 500 words (it's amazing how many accounts can be broken by using the twenty most common female names as guesses). People are incredibly lax about password security at most sites. Make it fast enough, and people can just crunch away using /usr/dict/words; an uneducated user is much more likely to use a word than a random group of eight characters. Since the password file is publically readable, you can just retrieve it, crunch away quietly on a different machine until you've broken the passwords you want. With a shadow password file and appropriate security logging, you can't repeatedly guess a user's password without triggering some alarms. -- - Joe Buck jbuck@epimass.epi.com, or uunet!epimass.epi.com!jbuck, or jbuck%epimass.epi.com@uunet.uu.net for old Arpa sites I am of the opinion that my life belongs to the whole community, and as long as I live it is my privilege to do for it whatever I can. -- G. B. Shaw
w-colinp@microsoft.UUCP (Colin Plumb) (12/20/88)
In article <2743@epimass.EPI.COM> jbuck@epimass.EPI.COM (Joe Buck) writes: >Irrelevant, because not all passwords are equally probable. This is true, but that's the system administrator's problem. As soon as you go beyond simple derivitaves of words (transposition, random capitalisation, etc.), there is no word list a password cracker can use, and brute-force search is the only way. My general rule is that a password must be something which has never, to the best of your knowledge, been written down anywhere in the world. My objection to shadow password files is that the layer of security they provide relies on the unreadability of the file by non-root people. Unix is not particularly secure this way. There are probably half a dozen ways to get a copy of a root-read-only file on any Unix system; the bugs don't help you do anything nastier than forge mail (L.sys), so aren't pursued with any great alacrity. Come on, don't you know a suid program that doesn't check its input files' permisisons properly and obligingly spits it out (perhaps slightly mangled) as output? -- -Colin (uunet!microsof!w-colinp)
karn@ka9q.bellcore.com (Phil Karn) (12/21/88)
I too have my doubts about the effectiveness of shadow password files. My fear is that it will make administrators complacent; they'll reason that since no one can get at the file, then there's no need to ensure on a regular basis that people pick hard-to-guess passwords. The next thing you'd know, the crackers would be back because they figured out somebody's trivial password by trial and error through the login prompt. It doesn't take very long to try the simple permutations even that way. I think the password file should remain publicly readable, thereby giving the administrators more of an incentive to police it regularly for easy-to-guess passwords. I'd also like to see a standard "key crunching" algorithm for transforming a password (or phrase) longer than 8 characters into a 56-bit DES key. Such a standard would be useful for encryption programs as well. A 56-bit search space is well beyond the brute-force abilities of most crackers (though perhaps not the NSA) **IF** the keys are widely and evenly distributed within it. Phil
smb@ulysses.homer.nj.att.com (Steven M. Bellovin) (12/21/88)
In article <12750@bellcore.bellcore.com>, karn@ka9q.bellcore.com (Phil Karn) writes: > > I'd also like to see a standard "key crunching" > algorithm for transforming a password (or phrase) longer than 8 characters > into a 56-bit DES key. My original reaction, when someone raised this issue, was that it wasn't necessary. I'm no longer quite as certain. The average user seems to be using just 26 letters for a password, thereby using about 20% of the total key space. Put another way, each character is only using 26/128 of the total bit combinations available at that position. To bring that to 56 bits, we need ~11.3 characters, which suggests a minimum length for passwords. The question, then, is what Phil asks: how to crunch the 12 characters. A better way to phrase the question is this: what algorithm will spread out the effect of each of the 12 characters? Put that way, the answer is fairly obvious: run each character through DES. DES has excellent distribution properties; on the average, changing a single bit position in the input will change approximately half the bit positions in the output. I believe the same is true of key changes. If so, what we can do is use each letter, with a lot of leading zeros, to encrypt some constant string, then feed that output back in for the next character. If you want, you can take the final version and cycle through another 25 times, as in the current code, but it isn't clear to me that it's necessary. It is necessary, I'd say, to always do the same number of encryptions, in order to reduce the ability of an intruder to get feedback from timing login attempts. Other wrinkles include using alternating encryption/decryption cycles; this tends to produce better mixing. (Of course, that would totally screw up passwords with letter pairs, which suggests that each successive input character be shift by a different number of bits.)
jfh@rpp386.Dallas.TX.US (The Beach Bum) (12/21/88)
In article <12750@bellcore.bellcore.com> karn@ka9q.bellcore.com (Phil Karn) writes: >I too have my doubts about the effectiveness of shadow password files. My >fear is that it will make administrators complacent; they'll reason that >since no one can get at the file, then there's no need to ensure on a >regular basis that people pick hard-to-guess passwords. I feel that shadow password files [ and I run one here ... ] raise the amount of desparation required for an attempt to succeed. Now, short of a physical breakin, one would need to sit at a login prompt for quite some time before getting a password broken. Before the user didn't even need a shell login to steal the password file, a UUCP login would have done. This has been changed ... -- John F. Haugh II +-Quote of the Week:------------------- VoiceNet: (214) 250-3311 Data: -6272 |"Unix doesn't have bugs, InterNet: jfh@rpp386.Dallas.TX.US | Unix is a bug" UucpNet : <backbone>!killer!rpp386!jfh +-- -- author forgotten --
root@zardoz.UUCP (Operator) (12/21/88)
In article <4420@xenna.Encore.COM> bzs@Encore.COM (Barry Shein) writes: >>As far as UNIX passwords, it further justifies the use of a shadow >>password file and the use of 64 character pass phrases. >Why? Because it shows a 20x speedup possibility? Let's do the >arithmetic again... >Given a 100 character character set and 8 characters in a password >the search space is 100^8 which is: But you don't need to search through all 100^8 combinations to have a reasonable change of gaining entry. All you need is to search through a 1000, or possibly even 10,000 common names and words, and you will find a match on a surprisingly large number of systems. Under this scenario, a 20 X speedup can make a big difference on the practicality of sneeking in a large batch job to do some password crunching. neil@cpd.com uunet!zardoz!neil
henry@utzoo.uucp (Henry Spencer) (12/22/88)
In article <110@microsoft.UUCP> w-colinp@microsoft.UUCP (Colin Plumb) writes: >My objection to shadow password files is that the layer of security they >provide relies on the unreadability of the file by non-root people. >Unix is not particularly secure this way... This does somewhat depend on how alert the sysadmin is. However, I think you're missing a point: shadow password files do add one more layer of complication for would-be crackers. There is no such thing as perfect security, just ways of making life harder for the bad guys. -- "God willing, we will return." | Henry Spencer at U of Toronto Zoology -Eugene Cernan, the Moon, 1972 | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
henry@utzoo.uucp (Henry Spencer) (12/22/88)
In article <12750@bellcore.bellcore.com> karn@ka9q.bellcore.com (Phil Karn) writes: >I too have my doubts about the effectiveness of shadow password files. My >fear is that it will make administrators complacent; they'll reason that >since no one can get at the file, then there's no need to ensure on a >regular basis that people pick hard-to-guess passwords. Turn it around: would you suggest deleting shadow password files, from systems which already have them, just to keep the sysadmins alert? Seems a bit drastic to me. I would think that any sensible sysadmin realizes that password guessing via login is always a threat. And insensible :-) sysadmins are beyond help anyway, short of massive upheaval in the software to make it naive-sysadmin-friendly. -- "God willing, we will return." | Henry Spencer at U of Toronto Zoology -Eugene Cernan, the Moon, 1972 | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
nevin1@ihlpb.ATT.COM (Liber) (12/22/88)
In article <12750@bellcore.bellcore.com> karn@ka9q.bellcore.com (Phil Karn) writes: >My >fear is that it will make administrators complacent; they'll reason that >since no one can get at the file, then there's no need to ensure on a >regular basis that people pick hard-to-guess passwords. Any administrator who will reason this out probably has so many other security holes on his/her system that it won't really matter anyway. Do you really want someone that naive as your system's "most trusted user"? >The next thing you'd know, the crackers would be back because they figured >out somebody's trivial password by trial and error through the login prompt. >It doesn't take very long to try the simple permutations even that way. And by not putting shadow password files on the system, a cracker is going to think that it will be *harder* to break the system than if he couldn't read the password file? I have a very hard time believing this. >I think the password file should remain publicly readable, thereby giving >the administrators more of an incentive to police it regularly for >easy-to-guess passwords. If it is possible for your adminstrator to reason that there is no need to make sure passwords are hard to guess when shadow files are around, won't he/she also reason that there is no need to make sure passwords are hard-to-guess when the passwords themselves are crypted? These both follow the same line of reasoning (as a matter of fact, the second case is more likely since this is the well-known reason for being able to have /etc/passwd readable in the first place. For a reference, look at section 2.4 of K&P's "The Unix(R) Programming Environment"). Also, since most of the administors I know don't bother to police their password files manually (only the gurus at NSA can uncrypt in their head :-)), why would running their automatic tools be any different with shadow files? In this case, the less information given to a cracker, the better. It's just too easy to break into a system given an encrypted password file and a little knowledge about human nature. -- NEVIN ":-)" LIBER AT&T Bell Laboratories nevin1@ihlpb.ATT.COM (312) 979-4751
bzs@Encore.COM (Barry Shein) (12/24/88)
From: henry@utzoo.uucp (Henry Spencer) >In article <12750@bellcore.bellcore.com> karn@ka9q.bellcore.com (Phil Karn) writes: >>I too have my doubts about the effectiveness of shadow password files. My >>fear is that it will make administrators complacent; they'll reason that >>since no one can get at the file, then there's no need to ensure on a >>regular basis that people pick hard-to-guess passwords. > >Turn it around: would you suggest deleting shadow password files, from >systems which already have them, just to keep the sysadmins alert? Although I agree with Phil Karn I also agree with Henry that this reasoning is not compelling. I tend towards the concern that if password files are made unreadable then we admit system security demands their unreadability. Given that we create the situation where if there's any suspicion that the pw file has gotten out we have to admit a security crises. For example, discovering a software bug which allowed any file to be read by any user, I know of a few in many systems (they've been discussed in the recent past, no secrets here.) Right now that would be a major concern on some systems, minor on others (eg. a system where all files are readable anyhow, not terribly uncommon, or of no great consequence.) By moving to shadow password files there's no choice, any bug which permits reading of unreadable files must be admitted to be a major security breach. Perhaps on your (universal "your") system you can tell your management and users that it really doesn't matter if every disgruntled employee now has a copy of the pw file but that sort of complacency can't be counted on. To turn it around, if you find a bug which allows anyone WRITE access to any file on the system don't you immediately check the password file? Unfortunately read access is more insidious since you probably can't tell if the pw file has been read by an unauthorized user, and it requires no tracks (that is, I can check the pw file against a recent backup tape after a write breach, after a read breach there's no modification to compare for.) Or do we conclude that we'll make the pw files unreadable but not be concerned if they happen to get read? I claim it's a can of worms being created. -Barry Shein, ||Encore||
mdf@ziebmef.uucp (Matthew Francey) (12/27/88)
In article <12750@bellcore.bellcore.com>, karn@ka9q.bellcore.com (Phil Karn) writes: > I'd also like to see a standard "key crunching" > algorithm for transforming a password (or phrase) longer than 8 characters > into a 56-bit DES key. Such a standard would be useful for encryption > programs as well. A 56-bit search space is well beyond the brute-force > abilities of most crackers (though perhaps not the NSA) **IF** the keys are > widely and evenly distributed within it. But what will this accomplish is the password file is readable and the encrpytion method (key crunching and all) public? The cracker would simply crunch her dictionary, and continue as before. A possible solution is to have each site pick its own secret encryption method (for example, start with a non-zero block). Could it remain secret for a long long time (years... it would be a major pain changing it)? Probably not, since anyone could disassemble passwd... -- Name: Matthew Francey Address: N43o34'13.5" W79o34'33.3" 86m mdf@ziebmef.UUCP uunet!utgpu!{ontmoh!moore,ncrcan}!ziebmef!mdf
karn@ka9q.bellcore.com (Phil Karn) (12/29/88)
>> I'd also like to see a standard "key crunching" >> algorithm for transforming a password (or phrase) longer than 8 characters >> into a 56-bit DES key. > But what will this accomplish is the password file is readable and the >encrpytion method (key crunching and all) public? A lot. The point is that to be maximally effective, the UNIX password algorithm should be given keys with 56 bits of entropy. That is, the distribution of actual user keys should be uniformly distributed over all 2^56 possible values. Present attacks on encrypted UNIX passwords are so successful only because the actual passwords people use are clustered in a tiny portion of this key space, and it is easily searched by brute force. However, a truly uniform key distribution would virtually defeat this for anyone but the NSA. Now this can be done in two ways: by having people use passwords that resemble either "(X4Hj12@", or "The wolf ate the duck whole.". The first is eight random characters (actually, only printing ASCII characters were chosen here, making the entropy more like 52 bits instead of 56). The second is an English sentence of 28 characters. According to Shannon's figure of 2 bits/letter for the entropy of English, this sentence has 56 bits of entropy. But which password is a human user more likely to remember? That's the whole point behind key crunching. By itself, this is not enough since people are likely to object to having to type repeatedly such long passwords. The answer to that problem is a good authentication scheme that would allow you to give your password only once (when logging in to your "home" computer) which would then enable your system to authenticate you to the other systems you use regularly on the network. As much as people like to bash rsh/rlogin as insecure, you must admit that it may actually enhance security if the alternative was to require people to enter their passwords so frequently that they choose short, simple ones to simplify typing. Phil
cory@gloom.UUCP (Cory Kempf) (12/30/88)
In article <13022@bellcore.bellcore.com> karn@ka9q.bellcore.com (Phil Karn) writes: > The answer to that problem is a good >authentication scheme that would allow you to give your password only once >(when logging in to your "home" computer) which would then enable your >system to authenticate you to the other systems you use regularly on the >network. Let's see if I have this right... you are going to allow the workstation that is sitting on my desk to convince another system that I am me, right? This workstation that I can bring down if I want, and bring back up in single user mode? With me in the playing the part of root? This workstation that will then lie for me if I ask it to? and tell your system that I am you? Or just about anybody else? Really? +C -- Cory ( "...Love is like Oxygen..." ) Kempf UUCP: encore.com!gloom!cory "...it's a mistake in the making." -KT
dave@cs.wisc.edu (Dave Cohrs) (12/30/88)
In article <276@gloom.UUCP> cory@gloom.UUCP (Cory Kempf) writes: >Let's see if I have this right... you are going to allow the >workstation that is sitting on my desk to convince another system that >I am me, right? > >This workstation that I can bring down if I want, and bring back up in >single user mode? With me in the playing the part of root? There are types of networking hardware that make it much easier to detect when your workstation is rebooted (or whatever). Don't assume that all the world's an Ethernet. Also, if I read Phil correctly, he's talking about having you, the user, authenticate the workstation as *yours*. That is, you have to go though some authentication protocol, giving your password, which would give your workstation some cookie that said "this workstation belongs to cory", and that this cookie could be verified to be authentic in some way without you, the user, doing anything more. Supposedly, if you hadn't authenticated yourself using the standard, approved of procedure, you wouldn't be able to make a valid cookie yourself, and no other computer would believe your workstation's lie. If being root on your workstation can spoof the authentication mechanism, then it's pretty useless in the grand scheme of things. Yes, rlogin is too trusting. Placing your UID in a magical location in every packet your workstation sends out, or some other equally naive mechanism (the kind that you appear to be assuming), is not quite up to the level of security that Phil seems to be talking about. -- Dave Cohrs +1 608 262-6617 UW-Madison Computer Sciences Department dave@cs.wisc.edu ...!{harvard,rutgers,ucbvax}!uwvax!dave
karn@jupiter..bellcore.com (Phil R. Karn) (12/30/88)
>Let's see if I have this right... you are going to allow the >workstation that is sitting on my desk to convince another system that >I am me, right? Use a little imagination. Your workstation might use the pass phrase that you give it when you first log in as the secret key in an encryption-based network authentication protocol. Simply becoming root on your system would not be enough to gain privileges on another system. Phil
jbayer@ispi.UUCP (Jonathan Bayer) (12/30/88)
In article <276@gloom.UUCP> cory@gloom.UUCP (Cory Kempf) writes: =In article <13022@bellcore.bellcore.com> karn@ka9q.bellcore.com (Phil Karn) writes: => The answer to that problem is a good =>authentication scheme that would allow you to give your password only once =>(when logging in to your "home" computer) which would then enable your =>system to authenticate you to the other systems you use regularly on the =>network. = =Let's see if I have this right... you are going to allow the =workstation that is sitting on my desk to convince another system that =I am me, right? = =This workstation that I can bring down if I want, and bring back up in =single user mode? With me in the playing the part of root? = =This workstation that will then lie for me if I ask it to? and tell =your system that I am you? Or just about anybody else? = =Really? You missed the point. In order for you playing the part of root to convince the other system that you are root your root system will have to have been identified to the other systems as being allowed to become root. In other words, the authentication system will only authenticate those ids which it has been told to do so. JB -- Jonathan Bayer ------------------------------------ Intelligent Software Products, Inc. "The time has come," the Walrus said... 19 Virginia Ave. ------------------------------------ Rockville Centre, NY 11570 (516) 766-2867
vyrus@altger.UUCP (vyrus) (01/02/89)
I have heard about a paper presenting a mathematical formulation of a fast implementation of the DES in software able of speding up UNIX crypt() password encryption routine by roughtly 20 times. (@ulysses.homer.nj.att.com) I wonder if someone would mind telling more about the matter or, (even better!) sending me an high language (C? great!) implementation of such algorithm. Another thing: I tried for over a month to design in C a decent pseudo random generator, but in vain. I know there is a lot a theory about random generators, but where are the samples? Now I am using DES to generate pseudo randomness and the process is terribly slooow. Any hints? [well, I did succeeed in writing my program, but when I applied its output to David Wood's Random_Number_Generator_Tester.c I found it was too bad] Thanks in advance. =David=
debra@alice.UUCP (Paul De Bra) (01/03/89)
In article <1273@altger.UUCP> vyrus@altger.UUCP (vyrus) writes: }I have heard about a paper presenting a mathematical formulation of a fast }implementation of the DES in software able of speding up UNIX crypt() }password encryption routine by roughtly 20 times. (@ulysses.homer.nj.att.com) } }I wonder if someone would mind telling more about the matter or, (even better!) }sending me an high language (C? great!) implementation of such algorithm. } This is certainly possible, but the implementation in Unix is made slow on purpose, to make password cracking more time consuming... }Another thing: I tried for over a month to design in C a decent pseudo }random generator, but in vain. I know there is a lot a theory about }random generators, but where are the samples? Now I am using DES to generate }pseudo randomness and the process is terribly slooow. Any hints? } }[well, I did succeeed in writing my program, but when I applied its output }to David Wood's Random_Number_Generator_Tester.c I found it was too bad] } Des is certainly an akward choice. rand() is not very random, but have you tried the berkeley "random" function? I don't have the source at hand right now, but it is probably reasonably random and fast. Paul. -- ------------------------------------------------------ |debra@research.att.com | uunet!research!debra | ------------------------------------------------------
cory@gloom.UUCP (Cory Kempf) (01/04/89)
In article <384@ispi.UUCP> jbayer@ispi.UUCP (Jonathan Bayer) writes: [ in response to the idea of logging in only to your 'home' computer, and allowing it to validate you to the rest of the network:] >You missed the point. In order for you playing the part of root to >convince the other system that you are root your root system will have >to have been identified to the other systems as being allowed to become >root. In other words, the authentication system will only authenticate >those ids which it has been told to do so. Hey, this might just be a really great idea! However, let's take it one step further: Program the function keys to have our login name and password! For example, set F1 to "cory", and F2 to "d0:^FQ+m&". This way, we can all use really cryptic passwords that are hard to remember, and we won't even have to remember them! When we want to log in, all we do is type in F1<cr>F2<cr>! When we want to use the network, and it asks for a password, all we have to do is hit F2<cr>! What could be easier? +C (btw, if anyone missed it, :-) ) -- Cory ( "...Love is like Oxygen..." ) Kempf UUCP: encore.com!gloom!cory "...it's a mistake in the making." -KT
dww@stl.stc.co.uk (David Wright) (01/07/89)
In article <276@gloom.UUCP> cory@gloom.UUCP (Cory Kempf) writes: #In article <13022@bellcore.bellcore.com> karn@ka9q.bellcore.com (Phil Karn) writes: #> The answer to that problem is a good #>authentication scheme that would allow you to give your password only once #>(when logging in to your "home" computer) which would then enable your #>system to authenticate you to the other systems you use regularly on the #>network. # #Let's see if I have this right... you are going to allow the #workstation that is sitting on my desk to convince another system that #I am me, right? #This workstation that will then lie for me if I ask it to? and tell #your system that I am you? Or just about anybody else? #Really? Yes, of course. Why not? Not without some help, and not with current standard UNIX and rsh/rlogin/etc. programs, but it is possible. Part of the help will have to be a trusted authentication server somewhere on the network. Now your workstation - which knows your password (you just typed it in, remember?) - can persuade the authentication server that you are you. Root or not, it does not know MY password, so if it tells the server that you are me, it won't be believed. (Yes, of course the transaction to the server is encrypted in case someone is listening on the cable). The authentication server will then issue a session key to your user agent, (e.g. a program in your workstation). If the permissions held by the services (or perhaps by the authentication server) allow you to use those services, then they will allow YOUR access based on the session key your user agent presents to them, which they will validate by asking the authentication server. Again, the session keys have to be transferred through an encrypted channel, or else used as a pair like public and private keys in a public key system. You can't use MY session key because it wasn't issued to you. If perchance you find it out, it won't help for long as it will become invalid at the end of MY session, or after a short time period. It could even be changed every few minutes, at the expense of a few extra authentication transactions going on in the background. The above is only a simple sketch of what would be a fairly complex system. But I hope (even if it is incomplete) it shows that it is possible to design an environment in which a user logs on once ("to the network") and then can use services on the network without logging in again to each host that a wanted service happens to be on, even though the workstation the user is directly using is insecure. -- Regards, "Are you sure YOUR password won't appear in RTM's next list?" David Wright STL, London Road, Harlow, Essex CM17 9NA, UK dww@stl.stc.co.uk <or> ...uunet!mcvax!ukc!stl!dww <or> PSI%234237100122::DWW
treese@athena.mit.edu (Win Treese) (01/08/89)
In article <920@acer.stl.stc.co.uk> "David Wright" <dww@stl.stc.co.uk> writes: >In article <276@gloom.UUCP> cory@gloom.UUCP (Cory Kempf) writes: >#In article <13022@bellcore.bellcore.com> karn@ka9q.bellcore.com (Phil Karn) writes: >#> The answer to that problem is a good >#>authentication scheme that would allow you to give your password only once >#>(when logging in to your "home" computer) which would then enable your >#>system to authenticate you to the other systems you use regularly on the >#>network. ># >#Let's see if I have this right... you are going to allow the >#workstation that is sitting on my desk to convince another system that >#I am me, right? >#This workstation that will then lie for me if I ask it to? and tell >#your system that I am you? Or just about anybody else? >#Really? > >Yes, of course. Why not? Not without some help, and not with current >standard UNIX and rsh/rlogin/etc. programs, but it is possible. [...authentication scheme description deleted...] See Steiner, Neuman, and Schiller, "Kerberos: An Authentication System for Open Network Systems," USENIX, Winter 1988, Dallas, TX. Kerberos is very similar to the scheme Mr. Wright described, and it has been running at MIT for a few years now. More information can be obtained by writing to info-kerberos@athena.mit.edu. BTW, the basic scheme Kerberos uses was described in a *1978* paper by Needham and Schroeder, which appeared in CACM. Win Treese Digital Equipment Corp. Cambridge Research Lab treese@crl.dec.com