dce@smsc.sony.com (David Elliott) (11/14/90)
We have a complaint that our system (like most versions of Unix) doesn't handle users who like to type their password immediately after their login. Specifically, if a user tries to do this, some or all of the password they type is displayed on the screen, and then this data is ignored by getpass(), which flushes the input before it reads. What I would like to know is if there is a good reason for the current behavior, and if changing this behavior might in some way compromise the security of the system.
speelmo@bronze.ucs.indiana.edu (Lance Speelmon -- UCS) (11/14/90)
In article <1990Nov13.182623.18967@smsc.sony.com> dce@smsc.sony.com (David Elliott) writes: >We have a complaint that our system (like most versions of Unix) >doesn't handle users who like to type their password immediately after >their login. Specifically, if a user tries to do this, some or all of >the password they type is displayed on the screen, and then this data >is ignored by getpass(), which flushes the input before it reads. > >What I would like to know is if there is a good reason for the current >behavior, and if changing this behavior might in some way compromise >the security of the system. The machines that we have here also act the same way. I don't think that there is any way to change that. I could be wrong though. ============================================================================ Lance Speelmon | University Computing Services speelmo@bronze.ucs.indiana.edu | Network Operations Center ============================================================================
jik@athena.mit.edu (Jonathan I. Kamens) (11/14/90)
In article <1990Nov13.182623.18967@smsc.sony.com>, dce@smsc.sony.com (David Elliott) writes: |> ... if a user tries to do this, some or all of |> the password they type is displayed on the screen, and then this data |> is ignored by getpass(), which flushes the input before it reads. |> |> What I would like to know is if there is a good reason for the current |> behavior, and if changing this behavior might in some way compromise |> the security of the system. The flushing of typeahead is meant to prevent people from doing exactly what you describe. Allowing the first characters of your password to be displayed on the screen as you type them is a Bad Idea (tm) and a clear security problem. If the login program doesn't accept input typed before echoing is turned off, then people have an incentive not to type any input before echoing is turned off. -- Jonathan Kamens USnail: MIT Project Athena 11 Ashford Terrace jik@Athena.MIT.EDU Allston, MA 02134 Office: 617-253-8085 Home: 617-782-0710
jik@athena.mit.edu (Jonathan I. Kamens) (11/14/90)
In article <71572@iuvax.cs.indiana.edu>, speelmo@bronze.ucs.indiana.edu (Lance Speelmon -- UCS) writes: |> The machines that we have here also act the same way. I don't think |> that there is any way to change that. I could be wrong though. If you really want to change it, which (as I said in my previous posting) is probably a bad idea, it is easy to do so as long as you have source code. You change the getpass() routine in the C library so that it uses TIOCSETN instead of TIOCSETP when doing the ioctl to turn off echoing. If you don't have source code, it is still possible to change it if you know what you're doing and you have unstripped binaries. If you want to change individual programs, you load them into adb, find the getpass() routine, find the call to ioctl, and change the TIOCSETP constant to TIOCSETN. If you want to change it for everything, you do the same thing on the C library. -- Jonathan Kamens USnail: MIT Project Athena 11 Ashford Terrace jik@Athena.MIT.EDU Allston, MA 02134 Office: 617-253-8085 Home: 617-782-0710
rwaters@jabba.harris-atd.com (Ralph Waters) (11/14/90)
In <1990Nov13.233329.8736@athena.mit.edu> jik@athena.mit.edu (Jonathan I. Kamens) writes: >If the login program doesn't accept input typed before echoing is >turned off, then people have an incentive not to type any input before echoing >is turned off. Using a system that always has type-ahead can be habit forming. Many of us who used VAX/VMS before UNIX have become used to the type-ahead, that it is hard to remember not to type too fast for the UNIX machine. -- -- Ralph Waters Internet: rwaters@jabba.ess.harris.com Harris Corporation - GISD Melbourne, Florida
wb8foz@mthvax.cs.miami.edu (David Lesher,,255RTFM,255rtfm) (11/14/90)
>Using a system that always has type-ahead can be habit forming. Many of us >who used VAX/VMS before UNIX have become used to the type-ahead, that it is >hard to remember not to type too fast for the UNIX machine. Yes, but you get positive feedback..... Wait a second or so, and you get in. Hurry, and you have to stop, explain to the password policeman where the fire is, pay the ticket, and THEN go back and do it again. -- A host is a host from coast to coast.....wb8foz@mthvax.cs.miami.edu & no one will talk to a host that's close............(305) 255-RTFM Unless the host (that isn't close)......................pob 570-335 is busy, hung or dead....................................33257-0335
herrickd@iccgcc.decnet.ab.com (11/14/90)
In article <1990Nov13.235307.9263@athena.mit.edu>, jik@athena.mit.edu (Jonathan I. Kamens) writes: > In article <71572@iuvax.cs.indiana.edu>, speelmo@bronze.ucs.indiana.edu (Lance Speelmon -- UCS) writes: > |> The machines that we have here also act the same way. I don't think > |> that there is any way to change that. I could be wrong though. > > If you really want to change it, which (as I said in my previous posting) is > probably a bad idea, it is easy to do so as long as you have source code. You > change the getpass() routine in the C library so that it uses TIOCSETN instead > of TIOCSETP when doing the ioctl to turn off echoing. But this does not fix the problem, only changes it. You need to also dig into the program that reads the username and turn off echo so the beginning of the password does not appear on the terminal. > > If you don't have source code, it is still possible to change it if you know > what you're doing and you have unstripped binaries. If you want to change > individual programs, you load them into adb, find the getpass() routine, find > the call to ioctl, and change the TIOCSETP constant to TIOCSETN. If you want > to change it for everything, you do the same thing on the C library. > > -- > Jonathan Kamens USnail: > MIT Project Athena 11 Ashford Terrace > jik@Athena.MIT.EDU Allston, MA 02134 > Office: 617-253-8085 Home: 617-782-0710 dan herrick herrickd@astro.pc.ab.com
tif@doorstop.austin.ibm.com (Paul Chamberlain) (11/15/90)
jik@athena.mit.edu (Jonathan I. Kamens) writes: > The flushing of typeahead is meant to prevent people from doing exactly what >you describe. Allowing the first characters of your password to be displayed >on the screen as you type them is a Bad Idea (tm) ... What do you think of turning off echo at the "login:" prompt and not flushing characters at the passwd prompt. It would be a very slight inconvenience to those who depend on seeing echo when they type their user name but it can't make much difference since they already type their password without looking. You might adopt the habit (as I do anyway) of pressing enter before you type your login name if there is a possibility of unseen keystrokes preceding your arrival. Paul Chamberlain | I do NOT represent IBM. tif@doorstop, sc30661 at ausvm6 512/838-7008 | ...!cs.utexas.edu!ibmchs!auschs!doorstop.austin.ibm.com!tif
les@chinet.chi.il.us (Leslie Mikesell) (11/15/90)
In article <1990Nov13.233329.8736@athena.mit.edu> jik@athena.mit.edu (Jonathan I. Kamens) writes: > The flushing of typeahead is meant to prevent people from doing exactly what >you describe. Allowing the first characters of your password to be displayed >on the screen as you type them is a Bad Idea (tm) and a clear security >problem. If the login program doesn't accept input typed before echoing is >turned off, then people have an incentive not to type any input before echoing >is turned off. Hmmm, then one might think the correct approach would be for getty to turn off echo as soon as it sees the <return> terminating the login entry. Better yet would be a sensible get-in program combining the functions of the traditional getty and login. This would allow taking input in raw mode and echoing only what you want to echo without regard to timing (and some other possibilities like hashing the passwd file while no one is on-line with a long-distance call and allowing multiple backspace/erase characters). Has anyone done this? If you are providing a service that people are not obligated to use, screwing up their attempts to log in will just provide them with an incentive to go elsewhere. Les Mikesell les@chinet.chi.il.us
lerman@stpstn.UUCP (Ken Lerman) (11/15/90)
In article <1990Nov13.233329.8736@athena.mit.edu> jik@athena.mit.edu (Jonathan I. Kamens) writes: ->In article <1990Nov13.182623.18967@smsc.sony.com>, dce@smsc.sony.com (David Elliott) writes: ->|> ... if a user tries to do this, some or all of ->|> the password they type is displayed on the screen, and then this data ->|> is ignored by getpass(), which flushes the input before it reads. ->|> ->|> What I would like to know is if there is a good reason for the current ->|> behavior, and if changing this behavior might in some way compromise ->|> the security of the system. -> -> The flushing of typeahead is meant to prevent people from doing exactly what ->you describe. Allowing the first characters of your password to be displayed ->on the screen as you type them is a Bad Idea (tm) and a clear security ->problem. If the login program doesn't accept input typed before echoing is ->turned off, then people have an incentive not to type any input before echoing ->is turned off. -> ->-- ->Jonathan Kamens USnail: ->MIT Project Athena 11 Ashford Terrace ->jik@Athena.MIT.EDU Allston, MA 02134 ->Office: 617-253-8085 Home: 617-782-0710 Is there any reason why one couldn't build a login program which always has echo turned off (and did a manual echo)? I understand that the echoing would be slower, but the problem of echoed passwords would be solved. Would that be acceptable? Ken
dce@smsc.sony.com (David Elliott) (11/16/90)
In article <1980.2741165d@iccgcc.decnet.ab.com>, herrickd@iccgcc.decnet.ab.com writes: |> In article <1990Nov13.235307.9263@athena.mit.edu>, jik@athena.mit.edu (Jonathan I. Kamens) writes: |> > In article <71572@iuvax.cs.indiana.edu>, speelmo@bronze.ucs.indiana.edu (Lance Speelmon -- UCS) writes: |> > |> The machines that we have here also act the same way. I don't think |> > |> that there is any way to change that. I could be wrong though. |> > |> > If you really want to change it, which (as I said in my previous posting) is |> > probably a bad idea, it is easy to do so as long as you have source code. You |> > change the getpass() routine in the C library so that it uses TIOCSETN instead |> > of TIOCSETP when doing the ioctl to turn off echoing. |> |> But this does not fix the problem, only changes it. You need to also |> dig into the program that reads the username and turn off echo so the |> beginning of the password does not appear on the terminal. Jonathon's solution really doesn't fix the "problem" for us, since we're using SVR4, though the idea is sound. Even modifying ttymon (SVR4 version of getty) doesn't quite solve the problem correctly. After all, not every login requires a password, so you have to make sure to put the tty back correctly. Also, there's nothing that says that ttymon/getty has to execute login, so you have to solve that peoblem. Oh, and you have to deal with the case where the line already had echo turned off in the first place. It seems to me that to really fix this right (assuming it's a correct thing to "fix" in the first place) you need to write a ttymon/getty with the login session handling integrated into it, or move all prompting into login. My solution so far has been to tell the people that asked to use xdm when they use X. This fixes the problem in that specific case. -- ...David Elliott ...dce@smsc.sony.com | ...!{uunet,mips}!sonyusa!dce ...(408)944-4073 ..."Help me! Moon-men have my socks... over..." - Al
geoff@edm.uucp (Geoff Coleman) (11/17/90)
From article <1990Nov13.233329.8736@athena.mit.edu>, by jik@athena.mit.edu (Jonathan I. Kamens): > In article <1990Nov13.182623.18967@smsc.sony.com>, dce@smsc.sony.com (David Elliott) writes: > |> ... if a user tries to do this, some or all of > |> the password they type is displayed on the screen, and then this data > |> is ignored by getpass(), which flushes the input before it reads. > |> > |> What I would like to know is if there is a good reason for the current > |> behavior, and if changing this behavior might in some way compromise > |> the security of the system. > > The flushing of typeahead is meant to prevent people from doing exactly what > you describe. Allowing the first characters of your password to be displayed > on the screen as you type them is a Bad Idea (tm) and a clear security > problem. If the login program doesn't accept input typed before echoing is > turned off, then people have an incentive not to type any input before echoing > is turned off. > But isn't AIX supposed to be a more secure UNIX. It does allow type ahead on the login and accepts it. I wonder if anyone has logged this as a bug. I'm at my quota for the week already. Geoff > -- > Jonathan Kamens USnail: > MIT Project Athena 11 Ashford Terrace > jik@Athena.MIT.EDU Allston, MA 02134 > Office: 617-253-8085 Home: 617-782-0710
dce@smsc.sony.com (David Elliott) (11/17/90)
In article <5798@stpstn.UUCP> lerman@stpstn.UUCP (Ken Lerman) writes: >Is there any reason why one couldn't build a login program which >always has echo turned off (and did a manual echo)? I understand that >the echoing would be slower, but the problem of echoed passwords would >be solved. Would that be acceptable? Yes, except that most of the time it isn't login that prompts for and reads the login. Instead, it's usually getty or ttymon, depending on the system. I say "most of the time" because I believe that most people get their username right the first time, and thus only give the password to login.
paul@actrix.co.nz (Paul Gillingwater) (11/18/90)
I waited several days in case someone else pointed this out, but nobody did, so here goes. The original message content indicated that it was a problem for users that they would start typing in their password too soon after their login name. To me, this implies a performance problem. Remember, the login: prompt comes from the getty. When the getty returns from its read with the login name, it invokes the login program with the user name as a parameter. What I think is happening is that the login program is taking at least a second or two to respond, because it has to be loaded off disk. Setting the sticky bit on login might help (although most UNIX will only keep it on swap, rather than locked in core). Another kludgey solution might be to start a daemon that keeps login in core, by feeding it input. This will save considerably on the startup time. -- Paul Gillingwater, paul@actrix.co.nz