e910276@dal1.kaist.ac.kr (KiChang Yang) (05/25/91)
I'm much interested in UNIX system. Recently, I found this '*' curios symbol in /etc/passwd. For example, bin:*:2:1::/bin:/bin/csh Could you tell me what this symbol means? Thanks in advance. +--------------------------------------------------------------------+ ! e910276@dal1.kaist.ac.kr ! Korea Institute of Technology. ! KiChang Yang. !--------------------------------------------------------------------+
rickert@mp.cs.niu.edu (Neil Rickert) (05/25/91)
In article <27017@adm.brl.mil> e910276@dal1.kaist.ac.kr (KiChang Yang) writes: > >I'm much interested in UNIX system. >Recently, I found this '*' curios symbol in /etc/passwd. >For example, > bin:*:2:1::/bin:/bin/csh >Could you tell me what this symbol means? It doesn't mean anything in particular. It represents the encrypted password. It happens that no encrypted password can ever be '*', so this is just one way of preventing anybody from ever logging in on this account. If for some reason I want to suspend a user from logging in, I might just prefer to put 'SUSPEND' in this field, as another way of preventing logins. -- =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= Neil W. Rickert, Computer Science <rickert@cs.niu.edu> Northern Illinois Univ. DeKalb, IL 60115 +1-815-753-6940
siebeck@infoac.rmi.de (Wolfgang Siebeck ) (05/26/91)
rickert@mp.cs.niu.edu (Neil Rickert) writes: >In article <27017@adm.brl.mil> e910276@dal1.kaist.ac.kr (KiChang Yang) writes: >> >>I'm much interested in UNIX system. >>Recently, I found this '*' curios symbol in /etc/passwd. >>For example, >> bin:*:2:1::/bin:/bin/csh >>Could you tell me what this symbol means? > It doesn't mean anything in particular. It represents the encrypted password. >It happens that no encrypted password can ever be '*', so this is just one >way of preventing anybody from ever logging in on this account. I guess, Yang is using a machine running SYSV and this machine uses /etc/shadow. In that file, you'll find an entry for user 'bin' with a password like the ones we are used to ... -ws -- siebeck@infoac.rmi.de (Wolfgang Siebeck)
pim@cti-software.nl (Pim Zandbergen) (05/27/91)
siebeck@infoac.rmi.de (Wolfgang Siebeck ) writes: >rickert@mp.cs.niu.edu (Neil Rickert) writes: >>In article <27017@adm.brl.mil> e910276@dal1.kaist.ac.kr (KiChang Yang) writes: >>> bin:*:2:1::/bin:/bin/csh >>>Could you tell me what this symbol means? >I guess, Yang is using a machine running SYSV and this machine >uses /etc/shadow. In that file, you'll find an entry for user 'bin' with a >password like the ones we are used to ... At least on this System V machine, an 'x' is placed in the /etc/passwd file if the encrypted password is actually located in /etc/shadow. A '*' definitely freezes an account. -- Pim Zandbergen domain : pim@cti-software.nl CTI Software BV uucp : uunet!mcsun!hp4nl!ctisbv!pim Laan Copes van Cattenburch 70 phone : +31 70 3542302 2585 GD The Hague, The Netherlands fax : +31 70 3512837
rvp@softserver.canberra.edu.au (Rey Paulo) (05/27/91)
In article <1991May25.153939.13870@mp.cs.niu.edu> rickert@mp.cs.niu.edu (Neil Rickert) writes: > > It doesn't mean anything in particular. It represents the encrypted password. >It happens that no encrypted password can ever be '*', so this is just one >way of preventing anybody from ever logging in on this account. > > If for some reason I want to suspend a user from logging in, I might just >prefer to put 'SUSPEND' in this field, as another way of preventing logins. > Yes, that's right. It is also more secure if you can include characters in this field which don't belong to the encrypted alphabet. One of these characters is '*'. -- Rey V. Paulo | Internet: rvp@csc.canberra.edu.au University of Canberra | I am not bound to please thee with my answer. AUSTRALIA | -Shylock, in "The Merchant of Venice" ------------------------------+----------------------------------------------
gwyn@smoke.brl.mil (Doug Gwyn) (05/27/91)
In article <27017@adm.brl.mil> e910276@dal1.kaist.ac.kr (KiChang Yang) writes: > bin:*:2:1::/bin:/bin/csh >Could you tell me what this symbol means? All it means is that no encrypted password can possibly match it. In other words, there is no valid password for accessing that account. (It's a "system" account, not assigned to a human user.)
subbarao@phoenix.Princeton.EDU (Kartik Subbarao) (05/27/91)
In article <1991May27.024122.1255@csc.canberra.edu.au> rvp@softserver.canberra.edu.au (Rey Paulo) writes: >Yes, that's right. It is also more secure if you can include characters in >this field which don't belong to the encrypted alphabet. One of these >characters is '*'. Doesn't matter, so long as it is not 13 letters long. -Kartik -- internet% ypwhich subbarao@phoenix.Princeton.EDU -| Internet kartik@silvertone.Princeton.EDU (NeXT mail) SUBBARAO@PUCC.BITNET - Bitnet
jag@hpcuhc.cup.hp.com (Janice Gee) (06/01/91)
>>Recently, I found this '*' curios symbol in /etc/passwd. >>For example, >> bin:*:2:1::/bin:/bin/csh >>Could you tell me what this symbol means? On some systems (i.e. HP trusted systems), the password field contains only a *, and passwords are stored in a separate file, /.secure/etc/passwd. +-----------------------------------------------------------------------------+ | MAILING ADDRESS: PHONE: | | Janice Gee (408)447-0898 | | MS 47LC TELNET (within HP): | | Hewlett Packard 1-447-0898 | | 19447 Pruneridge Ave. FAX: | | Cupertino, CA 95014 (408)447-0336 | +-----------------------------------------------------------------------------+
aeba-im-o-e2@berlin-emh1.army.mil ( IM EMAIL ASST SYS ADMIN) (06/04/91)
>From: KiChang Yang <e910276@dal1.kaist.ac.kr> >Subject: What does '*' symbol in /etc/passwd means? > >I'm much interested in UNIX system. >Recently, I found this '*' curios symbol in /etc/passwd. >For example, > bin:*:2:1::/bin:/bin/csh >Could you tell me what this symbol means? Someone answered that '*' might be a shadow password; It could be. Also, could be a convention for locking the login. If the superuser had typed in the '*', then noone can log in as bin. I know of several systems that used the '*' symbol to lock logins. "used" is past tense because they ran into problems using it as it is a UNIX metacharacter. Ken Gibson _______________________________________________________________________ | SGT Kendrick J. Gibson aeba-im-o-e2@berlin-emh1.army.mil | | Asst. System Administrator; U.S. Army Berlin Electronic-mail Host | | I'd rather be telecommuting. ETS/AUTOVON: 332-6714 |
zfgo01@hgo7.hou.amoco.com (F. G. Oakes) (06/06/91)
aeba-im-o-e2@berlin-emh1.army.mil ( IM EMAIL ASST SYS ADMIN) writes: >>From: KiChang Yang <e910276@dal1.kaist.ac.kr> >>Subject: What does '*' symbol in /etc/passwd means? On the version of UNIX I'm familiar with (SVR3), the password field in /etc/passwd is 13 characters in length, including the 2 characters of 'salt'. I've heard the practice of replacing this field with an '*' as 'starring-out' the password, making it impossible for someone to login to that ID since the password encryption mechanism is guaranteed to fail. I've routinely made this field "*LOCKED*" or "*NO LOGIN*" to achieve the same purpose. -- ============================================================================ zfgo01@hgo7.hou.amoco.com (Glen Oakes)
jeffe@eniac.seas.upenn.edu (george) (06/06/91)
:I've heard the practice of replacing this field with an '*' as 'starring-out' :the password, making it impossible for someone to login to that ID since the :password encryption mechanism is guaranteed to fail. I've routinely made :this field "*LOCKED*" or "*NO LOGIN*" to achieve the same purpose. of interest.. no entry in the password field ( "*", null, random characters ) "locks" the account if the user has enabled no-password rlogin via a .rlogin entry. I suppose this is obvious, but I had to try it to find out. In this case you can lock the user out by corrupting his home directory entry as well as his password. -based on ten minutes of exhaustive testing on a sun4. -- -george george@mech.seas.upenn.edu
aeba-im-o-e2@berlin-emh1.army.mil ( IM EMAIL ASST SYS ADMIN) (06/12/91)
>>Also, could be a convention for locking the login. If the superuser >>had typed in the '*', then noone can log in as bin. I know of several >>systems that used the '*' symbol to lock logins. "used" is past tense >>because they ran into problems using it as it is a UNIX metacharacter. ^^^^^^^ a lie ^^^^^ A few people have asked me to be specific about what problems were had. Well, I lied. The problem was not due to the fact that '*' can be special. After checking with the person that told me not to use '*' in the password field, I find that the real reason was that the security scripts in Hayden's UNIX System Security by Kochan and Wood would choke on the '*'. flames to, Ken Gibson _______________________________________________________________________ | SGT Kendrick J. Gibson aeba-im-o-e2@berlin-emh1.army.mil | | Asst. System Administrator; U.S. Army Berlin Electronic-mail Host | | I'd rather be telecommuting. ETS/AUTOVON: 332-6714 | DISCLAIMER: My employer has used brainwashing techniques on me; I might share opinions with them.
rvp@softserver.canberra.edu.au (Rey Paulo) (06/14/91)
In article <27176@adm.brl.mil> aeba-im-o-e2@berlin-emh1.army.mil ( IM EMAIL ASST SYS ADMIN) writes: >>>Also, could be a convention for locking the login. If the superuser >>>had typed in the '*', then noone can log in as bin. I know of several >>>systems that used the '*' symbol to lock logins. "used" is past tense >>>because they ran into problems using it as it is a UNIX metacharacter. > ^^^^^^^ a lie ^^^^^ > >A few people have asked me to be specific about what problems were had. >Well, I lied. The problem was not due to the fact that '*' can be special. >After checking with the person that told me not to use '*' in the password >field, I find that the real reason was that the security scripts in Hayden's >UNIX System Security by Kochan and Wood would choke on the '*'. > The reason why '*' is used to lock login is because '*' is not in the encrypted alphabet of the crypt algorithm. Hence, it is impossible for the encryption program to generate a string with a '*'. -- Rey V. Paulo | Internet: rvp@csc.canberra.edu.au University of Canberra | I am not bound to please thee with my answer. AUSTRALIA | -Shylock, in "The Merchant of Venice" ------------------------------+----------------------------------------------
frechett@spot.Colorado.EDU (-=Runaway Daemon=-) (06/14/91)
In article <1991Jun14.002427.6120@csc.canberra.edu.au> rvp@softserver.canberra.edu.au (Rey Paulo) writes: I just recently spent a significant amount of time figure out why crypt does what it does and I believe I can add a bit here. > >The reason why '*' is used to lock login is because '*' is not in the >encrypted alphabet of the crypt algorithm. Hence, it is impossible for >the encryption program to generate a string with a '*'. There is a bit more to it than just the fact that * is not in the encryption charcter set (which is true). Valid characters are [a-zA-Z/.]. But if I were to use any string in /etc/passwd with a lenght != 13 bytes it will be invalid. The nuts at work commonly use name:PASSWD GOES HERE:etc:etc:etc.... . This string cannot possibly be generated by crypt(3) and this is why. In the internals of crypt(3) it takes as input a 10 byte word and 2 bytes of salt. The salt is generally chosen randomly and it consists of two of the characters from the valid charcters mentioned above. The salt choses 1 of 4096 different slight modifications in the standard DES encryption scheme. The word and salt are fed in and crypt(3) outputs the salt as the first two characters of the encrtyped passwd and then 11 more bytes of truely encrypted data. For fun.. look at the string in /etc/passwd that is your encrypted passwd, change it.. then change it back. Look again at the string; it will be different due to a new randomly chosen salt. Also, crypt(3) is not decryptable in that once you have an encrypted word there is no way to return the original string. The only way to decrypt is actually to encrypt a guess and compare with what you already have. An example: (>=+=>crypt.pl Enter <key> <salt> =>blueish aB Crypt is: aB6YSC2UZBGII Note aB is in encrytion Enter <key> <salt> =>blueish Z. Crypt is: Z.0iioX3H3zoo Enter <key> <salt> =>blueish Z.0iioX3H3zoo and this is why.. This is how ^^^^^^^^^^^^^ login checks your passwd. You would take this from /etc/passwd Crypt is: Z.0iioX3H3zoo Two more notes.. 1. I say crypt(3) because crypt(1) is totally different. 2. crypt(3) is purposely designed to take a HUGE portion of CPU when encrypting which makes passwd cracking very slow and fairly visible. If I just run one guess through every line of the /etc/passwd file on my DEC5500 (about 28 Mips) it hangs about every 5 seconds for up to 20 seconds.. The machine just can't afford to keep the process in memory all the time. > >-- >Rey V. Paulo | Internet: rvp@csc.canberra.edu.au >University of Canberra | I am not bound to please thee with my answer. >AUSTRALIA | -Shylock, in "The Merchant of Venice" >------------------------------+---------------------------------------------- ian -=Runaway Daemon=- (UNIXOPS University of Colorado at Boulder)
dattier@vpnet.chi.il.us (David W. Tamkin) (06/15/91)
frechett@spot.Colorado.EDU, whose name seems to be Ian Frechette, wrote <1991Jun14.051958.17564@colorado.edu>, which had a lot of really good information but a couple things unfortunately he typed it a bit too quickly. | There is a bit more to it than just the fact that * is not in the encryption | charcter set (which is true). Valid characters are [a-zA-Z/.]. Valid characters are those fifty-four plus [0-9], totaling sixty-four. That is why there are 4096 possible pairs if you randomly make two selections from the entire set with order counting. (The salt may consist of two identical characters [there's a 1 in 64 chance of that] and order *does* count here, so even though there are only 2016 distinct doubletons in a set of sixty-four elements, there are 4096 possible salts). | For fun.. look at the string in /etc/passwd that is your encrypted passwd, | change it.. then change it back. Look again at the string; it will be | different due to a new randomly chosen salt. By "change it" Ian must have meant to change your password and to change it back (something any user can do), not to change the encrypted string in /etc/passwd. If your system uses a shadow file, the same thing will happen, but you won't be able to see it unless you have read permissions on the shadow file. Otherwise, thank you for a very informative explanation. David Tamkin PO Box 7002 Des Plaines IL 60018-7002 dattier@vpnet.chi.il.us GEnie:D.W.TAMKIN CIS:73720,1570 MCIMail:426-1818 708 518 6769 312 693 0591 "Parker Lewis Can't Lose" mailing list: flamingo-request@esd.sgi.com (reflector) flamingo-request@mcs.com (digest)
mouse@thunder.mcrcim.mcgill.edu (der Mouse) (06/18/91)
In article <1991Jun14.051958.17564@colorado.edu>, frechett@spot.Colorado.EDU (-=Runaway Daemon=-) writes: > Two more notes.. > 1. I say crypt(3) because crypt(1) is totally different. > 2. crypt(3) is purposely designed to take a HUGE portion of CPU when > encrypting which makes passwd cracking very slow and fairly > visible. If I just run one guess through every line of the > /etc/passwd file on my DEC5500 (about 28 Mips) it hangs about > every 5 seconds for up to 20 seconds.. The machine just can't > afford to keep the process in memory all the time. Then this is a deliberate crippling of your crypt(3) library routine, or your machine is severely overloaded. There is nothing sufficiently intrinsically difficult about it to justify this sort of (lack of) speed. On a Sun SPARCserver 470, for example, I have seen code that runs at about 1000 encryptions per second, sustained. (I think this machine is supposed to be very roughly comparable to your DEC5500; my hazy memory says Sun claims it's in the low tens of MIPS....) (And yes, you're entirely right in your note (1). crypt(3) is a slightly tweaked DES; crypt(1) is a one-rotor Enigma machine.) der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu