john@uunet.uu.net (04/10/91)
John Lupien <lupienj@hpwadac.hp.com> types: In article <1991Mar27.094325.24599@en.ecn.purdue.edu> kidder@en.ecn.purdue.edu (Mark Stephen Kidder) writes: >>PS I learned earlier from another that UNIX does not use a DES >> encryption method for the password; however, a one-way method >> is used making decoding a password impossible. >^^^^^^^^^^^ >To borrow a phrase from one of those "Airplane" movies, "You use that >word a lot. I don't think it means what you think it means." > >When someone says that something is "impossible", the first thing that >comes to my mind is "how long has it been impossible, and how long will >it stay that way?". Certainly I don't know how to decode an encrypted >UNIX password, but I think it is somewhat foolhardy to assume that nobody >does. There are some very clever people around, and some of them have some >very fast and capable hardware. It doesn't matter how fast or powerful the hardware is. To steal a quote (from where I can't remember) "You can't feed sausage backwards through a meat grinder and come out with a pig at the other end". Now that this little misconception is cleared up :) it still doesn't mean that your machine is secure. While there is no known method of reversing the encrytpion, you can use comparison or other BFI methods (BFI=Brute Force and Ignorance) to get at passwords. This topic has been beaten to death in here but it all comes down to the same thing... As long as you choose passwords carefully, your password is relatively safe! The best passwords are completely random sequences. The next best (and easiest to remember) is phonetic permutations of foreign words with random capitalizations. Of course, none of this will protect you %100. I've found that most computer break-ins are not by super geniuses that toss super-computer power at machines, but rather a result of a persistant individual who exploits the ignorance of users and poor system administrators. As long as even ONE person can log into your machine, it's not completely secure. Common sense and awareness are are your only defense. There are a lot easier ways to break into a unix box than through the password file. Also, getting a copy of your password file requires access to your machine in the first place. If a competent hacker has access to your box, they probably won't waste time with your password file. They'll be busy looking for other holes in your system to exploit. >--- >John R. Lupien >lupienj@hpwarq.hp.com Cheers ______Opinions stated are my own. Transcripts available by request______ === =--==== AT&T Canada Inc. John Benfield =----==== 3650 Victoria Park Ave. Network Support Analyst (MIS) =----==== Suite 800 ==--===== Willowdale, Ontario attmail : ~jbenfield ======= M2H-3P7 email : uunet!attcan!john === (416) 756-5221 Compu$erve: 72137,722 ____Eagles may soar, but weasels don't get sucked into jet engines._____
anamaria@saffron.wpd.sgi.com (Ana Maria De Alvare') (04/11/91)
I agree with John Benfiel that common sense is the weapon against password
cracking, and that a cracker only needs one misuse, poorly chosen password
to get access to your system.
I want to make it clear that a person can has access to someone machine's
password file throught the internet without having any accounts directly
related to that person. For example, throught the ftp anonymous service,
I can copy a password file over. This scenario is considered access to
the remote machine in question. However, public anonymous access to a
remote machine, is not being thought as authorizing anonymous browsing,
and copying over files other than the ones explicitly publish with
the ftp anonymous procedures. In other words, ftp anonymous access is not
look as individual access rights. So beware system administrators to
curtail the amount of access you give away to ftp anonymous services.
-------------------------------------------------------------------------------
Ana Maria De Alvare' MTS Secure IRIX Silicon Graphics, Inc.
anamaria@sgi.COM {decwrl,sun}!sgi!whizzer!saffron!anamaria 415-335-7309
-------------------------------------------------------------------------------meissner@osf.org (Michael Meissner) (04/11/91)
In article <26520@adm.brl.mil> anamaria@saffron.wpd.sgi.com (Ana Maria De Alvare') writes: | I want to make it clear that a person can has access to someone machine's | password file throught the internet without having any accounts directly | related to that person. For example, throught the ftp anonymous service, | I can copy a password file over. This scenario is considered access to | the remote machine in question. However, public anonymous access to a | remote machine, is not being thought as authorizing anonymous browsing, | and copying over files other than the ones explicitly publish with | the ftp anonymous procedures. In other words, ftp anonymous access is not | look as individual access rights. So beware system administrators to | curtail the amount of access you give away to ftp anonymous services. Ummm, unless you wrote your own ftpd, the standard BSD one explicitly chroot's anonymous FTP requests to the logon directory of the user 'ftp'. In every system manual, where I've seen how to set up anonymous FTP, it mentions this, and tells the system manager never to make the logon directory be '/'. -- Michael Meissner email: meissner@osf.org phone: 617-621-8861 Open Software Foundation, 11 Cambridge Center, Cambridge, MA, 02142 Considering the flames and intolerance, shouldn't USENET be spelled ABUSENET?
magnus%thep.lu.se@Urd.lth.se (Magnus Olsson) (04/11/91)
In article <MEISSNER.91Apr10175314@curley.osf.org> meissner@osf.org (Michael Meissner) writes: >In article <26520@adm.brl.mil> anamaria@saffron.wpd.sgi.com (Ana Maria >De Alvare') writes: > >| I want to make it clear that a person can has access to someone machine's >| password file throught the internet without having any accounts directly >| related to that person. For example, throught the ftp anonymous service, >| I can copy a password file over. >Ummm, unless you wrote your own ftpd, the standard BSD one explicitly >chroot's anonymous FTP requests to the logon directory of the user >'ftp'. In every system manual, where I've seen how to set up >anonymous FTP, it mentions this, and tells the system manager never to >make the logon directory be '/'. Of course, you still need an /etc/passwd file (relative to FTP's "new" root), but fortunately, the password information isn't needed. Here's what you get if you onnect with anonymous ftp to our machines and do a "get /etc/passwd": root:*:0:1:System PRIVILEGED Account:/:/usr/new/csh ftp:*:295:15:Anonymous ftp:/usr/users/ftp:/usr/new/csh All the ordinary users have been edited out, and there's no password information left. All the presumptive cracker gets to know is that there are accounts called root and ftp, and he probably knew that already... Magnus Olsson | \e+ /_ Dept. of Theoretical Physics | \ Z / q University of Lund, Sweden | >----< Internet: magnus@thep.lu.se | / \===== g Bitnet: THEPMO@SELDC52 | /e- \q
mouse@thunder.mcrcim.mcgill.edu (der Mouse) (04/14/91)
In article <26512@adm.brl.mil>, attcan!vpk1!john@uunet.uu.net writes: > John Lupien <lupienj@hpwadac.hp.com> types: > In article <1991Mar27.094325.24599@en.ecn.purdue.edu> kidder@en.ecn.purdue.edu (Mark Stephen Kidder) writes: [Are those attribution lines really right? They look odd. -Mouse] >>> PS I learned earlier from another that UNIX does not use a DES >>> encryption method for the password; however, a one-way method is >>> used making decoding a password impossible. >> ^^^^^^^^^^^ >> To borrow a phrase from [some movie], "You use that word a lot. I >> don't think it means what you think it means." > It doesn't matter how fast or powerful the hardware is. [...] While > there is no known method of reversing the encrytpion, you can use > comparison or other BFI methods ([...]) to get at passwords. What's the difference? Any method that takes the hashed password as input and produces the original form as output (or, arguably, any string which would be accepted for (eg) logins) counts as "decoding the password" or "reversing the encry[pt]ion". Whether this is done by some clever method only the no-such-agencies currently know, by table lookup in a monster table, by exhaustive search through the space of possibilities, or some other method, is completely irrelevant. The common password encryption scheme is not DES, not quite; it is DES with the E-box diddled slightly by the salt value (supposedly to defeat attempts to use DES hardware for exhaustive search). It is a reasonably good approximation to a one-way function. Nevertheless, to mangle the language sightly, it is not impossible and is steadily becoming less so. There are only 2^56 input values. I have code that does approximately a thousand trials a second on general-purpose hardware. Let's suppose with a little hardware work we could push this to a million per second (a bit in advance of current hardware, but probably not that much). This still sounds fairly secure, as it works out to about two thousand years to cover the entire space. But now we spend a little money and buy/build a thousand of those hardware assist units. Now we're down to two years. And the vast majority of the space of possibilities corresponds to passwords like V 3 ^A 9 W ' ; x that no sane person would pick because they're so impossible to remember. No, it's time to start thinking about it. Now. Not in five years, when anyone with access to one of the latest FrobozzCo 64K-processor 2684TRX PLA machines can exhaust the space in a month, and find your password and mine much sooner than that. Or when storage densities have improved to the point where one person can carry that monster lookup table I mentioned in a pocket. (64 bits times 2^56 passwords times 2^12 salts is 2^71 bytes. That looks ridiculous. Today.) der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu
root@NEXTSERVER.CS.STTHOMAS.EDU (Max Tardiveau) (04/15/91)
mouse@larry.mcrcim.mcgill.edu writes (about password security) : > No, it's time to start thinking about it. Now. Not in five years, > when anyone with access to one of the latest FrobozzCo64K-processor > 2684TRX PLA machines can exhaust the space in a month,and find your > password and mine much sooner than that. Or when storage densities > have improved to the point where one person can carry that monster > lookup table I mentioned in a pocket. (64 bits times 2^56 passwords > times 2^12 salts is 2^71 bytes. That looks ridiculous. Today.) > > der Mouse > > old: mcgill-vision!mouse > new: mouse@larry.mcrcim.mcgill.edu > Well, I couldn't resist. Let's see. 2^71 is... 2,361,183,241,434,822,606,848, or (thanks to number(1)) : two sextillion three hundred sixty one quintillion one hundred eighty three quadrillion two hundred forty one trillion four hundred thirty four billion eight hundred twenty two million six hundred six thousand eight hundred forty eight. A big hard disk is 1 billion bytes. A huge carousel is one trillion bytes. This is nine orders of magnitude larger. We'll get there, but not tomorrow, nor the day after. In other words : Don't panic. --------------------------------------------------------------- Max Tardiveau Department of Computer Science University of St.Thomas St.Paul, MN 55105 Internet : m9tardiv@cs.stthomas.edu --------------------------------------------------------------- "Ban the bomb. Save the world for conventional warfare."
hubcap@hubcap.clemson.edu (System Janitor) (04/15/91)
*
* Ummm, unless you wrote your own ftpd, the standard BSD one explicitly
* chroot's anonymous FTP requests to the logon directory of the user
* 'ftp'. In every system manual, where I've seen how to set up
* anonymous FTP, it mentions this, and tells the system manager never to
* make the logon directory be '/'.
But the man page for ftpd (usually) also says something like:
~ftp/etc) Make this directory owned by the superuser and unwrit-
able by anyone. The files passwd(5) and group(5) must
be present for the ls command to work properly.
... and they never warn you to delete the encrypted password field
from ~/ftp/etc/passwd. Lots of people have their *real* password files
available via anonymous ftp, and the manual more or less *tells* them to
do it!
-Mikerickert@mp.cs.niu.edu (Neil Rickert) (04/15/91)
In article <1991Apr15.140747.29793@hubcap.clemson.edu> hubcap@hubcap.clemson.edu (System Janitor) writes: > >But the man page for ftpd (usually) also says something like: > > ~ftp/etc) Make this directory owned by the superuser and unwrit- > able by anyone. The files passwd(5) and group(5) must > be present for the ls command to work properly. I don't know about others, but I never interpreted this as implying that ~ftp/etc/passwd should have the same contents as /etc/passwd. I replaced all passwords with '*', and deleted most users from the copy we use. -- =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= Neil W. Rickert, Computer Science <rickert@cs.niu.edu> Northern Illinois Univ. DeKalb, IL 60115 +1-815-753-6940
croft@csusac.csus.edu (Steve Croft) (04/20/91)
Leong and Tham presented a paper at winter Usenix where they claimed a hardware based encyrpter could determine a lower case password in 15 days. On the basis of this, they claimed that UNIX password encryption is insecure. They claim the board would cost about $2000 to build and consist of about 100 ECL chips. The paper is in the proceedings; sorry if this has been mentioned earlier. Steve Croft stevec@water.ca.gov
mjo@irie.ais.org (Mike O'Connor) (04/20/91)
In article <1991Apr20.150213.23439@csusac.csus.edu> croft@csusac.csus.edu (Steve Croft) writes:
:Leong and Tham presented a paper at winter Usenix where they claimed a
:hardware based encyrpter could determine a lower case password in 15
:days. On the basis of this, they claimed that UNIX password encryption
:is insecure.
How would the passwords be recognized as such? Visual inspection? I
can't imagine my password as being anything but gibberish, even if
decrypted.
====
Mike O'Connor (mjo@ais.org)gwyn@smoke.brl.mil (Doug Gwyn) (04/21/91)
In article <1991Apr20.163540.23924@engin.umich.edu> Mike O'Connor <mjo@ais.org> writes: >How would the passwords be recognized as such? Visual inspection? A UNIX password is "recognized" when it is found to encrypt to the known ciphertext. Note that for purposes of account cracking, any plaintext having this property will serve as a password just as good as the one you originally chose (in case there are multiple plaintexts that encrypt to the same ciphertext).
cs132041@cs.brown.edu (Jeremy Gaffney) (04/22/91)
In article <1991Apr20.163540.23924@engin.umich.edu>, mjo@irie.ais.org (Mike O'Connor) writes: |> In article <1991Apr20.150213.23439@csusac.csus.edu> croft@csusac.csus.edu (Steve Croft) writes: |> :Leong and Tham presented a paper at winter Usenix where they claimed a |> :hardware based encyrpter could determine a lower case password in 15 |> :days. On the basis of this, they claimed that UNIX password encryption |> :is insecure. |> |> How would the passwords be recognized as such? Visual inspection? I |> can't imagine my password as being anything but gibberish, even if |> decrypted. |> As was mentioned earlier in this thread, all that would be required is any password which returned the same encryption as the original. I would be interested in knowing how they determine the seeding that is used to encrypt the original...I was under the impression that this was site-specific. jg (cs132041@cs.brown.edu) |> |> ==== |> Mike O'Connor (mjo@ais.org)