[comp.lang.c] Reading a keystroke w/o echo

azarian@hpcc01.HP.COM (Randy Azarian) (05/23/91)

I am trying to write some C code that will be able to be portable to a number
of platforms (Unix, MVS, DOS, MPE) without modification of any kind.  I/O will
be nothing fancy, using printf's and the like.  

I need to accept a user password (that won't echo to the screen).  So what I 
am looking for is an ANSI-C routine that will accept a keystroke without 
echoing it to the screen.

Does anyone know of such a function or a way to fool stdin/stdout to 
accomplish the same thing?

junki@lut.fi (Juha Nurmela) (05/24/91)

Randy Azarian writes:

>I need to accept a user password (that won't echo to the screen).  So what I 
>am looking for is an ANSI-C routine that will accept a keystroke without 
>echoing it to the screen.
>
>Does anyone know of such a function or a way to fool stdin/stdout to 
>accomplish the same thing?

Simple solution... Portable ?

puts("Please dim Your monitor with knob called brightness.");
puts("Then key Your passwd terminating with ENTER and readjust the knob");
gets(password);
puts("\n\n\n\n ...50 times ... \n");

juha nurmela

-- 
         juha nurmela, Adr. 54430 Hujakkala, Finland. Tel. 953 78022
                  eiku: skinnarilank. 28d10, Tel. 953 26292

gwyn@smoke.brl.mil (Doug Gwyn) (05/24/91)

In article <990007@hpcc01.HP.COM> azarian@hpcc01.HP.COM (Randy Azarian) writes:
>I am trying to write some C code that will be able to be portable to a number
>of platforms (Unix, MVS, DOS, MPE) without modification of any kind.  ...
>I need to accept a user password (that won't echo to the screen).

But that's a contradictory set of requirements.
Isn't this is the FAQ yet?

jlg@cochiti.lanl.gov (Jim Giles) (05/25/91)

In article <1991May23.184302.13918@lut.fi>, junki@lut.fi (Juha Nurmela) writes:
|> [...]
|> puts("Please dim Your monitor with knob called brightness.");
|> puts("Then key Your passwd terminating with ENTER and readjust the knob");
|> gets(password);
|> puts("\n\n\n\n ...50 times ... \n");

Sun workstations don't have a brightness control knob.

J. Giles

mouse@thunder.mcrcim.mcgill.edu (der Mouse) (05/25/91)

In article <24450@lanl.gov>, jlg@cochiti.lanl.gov (Jim Giles) writes:
> In article <1991May23.184302.13918@lut.fi>, junki@lut.fi (Juha Nurmela) writes:
>> puts("Please dim Your monitor with knob called brightness.");
>> puts("Then key Your passwd terminating with ENTER and readjust the knob");
>> gets(password);
>> puts("\n\n\n\n ...50 times ... \n");

> Sun workstations don't have a brightness control knob.

Some of ours do.  Every Sun I have ever seen (of those that have
graphics screens, of course) has a brightness control of some sort; in
some cases it is just a bare potentiometer shaft, in others it is a pot
shaft with a knob on it, and on yet others it is a thumbwheel sort of
thing - sort of like a knob of which only one side is accessible.  But
every single Sun monitor I've ever seen has a brightness control
somewhere, and some of them even have a knob on it.

Perhaps there are some that don't.  I haven't seen an example of every
type of Sun in existence.  But I am familiar with the -3/50 (mono),
-3/60 (mono), -3/60 (color), -3/160 (mono), SLC (mono), SS1+ (mono),
SS1+ (color), and have used a -4/110 (mono).  Every one of them has/had
a brightness control.

I restrict myself to those with graphics screens because you say
"workstations".  But you bring up a good point; I have seen dumb-ascii
terminals that hide their brightness control faily effectively, though
I can't recall having seen one utterly without such a control.

					der Mouse

			old: mcgill-vision!mouse
			new: mouse@larry.mcrcim.mcgill.edu

TGREENIN@ESOC.BITNET (05/27/91)

In article <1991May23.184302.13918@lut.fi>, junki@lut.fi (Juha Nurmela) says:
>Simple solution... Portable ?
>
>puts("Please dim Your monitor with knob called brightness.");
>puts("Then key Your passwd terminating with ENTER and readjust the knob");
>gets(password);
>puts("\n\n\n\n ...50 times ... \n");


Sorry, this just won't work with Teletypes. What you should do is

1. Get the user to check noone is looking.
2. Accept the password and wind the carriage back one line
   (if appropriate).
3. Output a carriage return [:r] followed by sufficient characters
   e.g. '*'s to cover the password.
4. Return step 3, using different characters ('#','@','%' etc.)
   until the password is totally obliterated, the paper has a hole
   worn in it etc. (this can be quite tedious on a 110 baud TTY).
5. If you want a *truly* secure routine, then prompt the user to
   remove the ribbon (if appropriate) and burn it after the program
   has finished running. You may also consider getting him to wipe
   the keyboard clean to get rid of fingerprints on the keytops.

Seriously, folks, this approach was used (other than step 5) on a
CDC Cyber system I used to program on at the University of Manchester
in the early 80's. Mind you, I can't figure how to solve it for using
punched cards as an input medium.

Hope this helps. It's simple, cheap, efficient etc.

Tim Greening-Jackson
E.S.O.C., 6100 Darmstadt, (What used to be West) Germany.

dbrooks@penge.osf.org (David Brooks) (05/28/91)

Note headers: stage 1 of moving this to an appropriate group.

In article <91147.164007TGREENIN@ESOC.BITNET> TGREENIN@ESOC.BITNET writes:
>[re silly ways of obscuring passwords when you can't turn off echo]
>
>Sorry, this just won't work with Teletypes. What you should do is
>
>1. Get the user to check noone is looking.
>2. Accept the password and wind the carriage back one line
>   (if appropriate).
>3. Output a carriage return [:r] followed by sufficient characters
>   e.g. '*'s to cover the password.
>4. Return step 3, using different characters ('#','@','%' etc.)
>   until the password is totally obliterated, the paper has a hole
>   worn in it etc. (this can be quite tedious on a 110 baud TTY).
>
>Seriously, folks, this approach was used...on a
>CDC Cyber system I used to program on at the University of Manchester
>in the early 80's.

Grrmph.  Hardly what *I* would call secure.  The timesharing system at
Cambridge University (late 60's) accepted your username then typed:

******** <return> SSSSSSSS <return> HHHHHHHH <return>

and THEN you entered the password.  Most effective, especially if the
password contained only S's and H's.

I may have the S's and the H's a about f.

> Mind you, I can't figure how to solve it for using
>punched cards as an input medium.

Use a non-verifying punch to begin with.  Patch your OS so that it diverts
the appropriate cards into the alternate output hopper.  Keep a small fire
burning in that hopper.  Works for me.

>Tim Greening-Jackson
>E.S.O.C., 6100 Darmstadt, (What used to be West) Germany.

They moved it?

-- 
David Brooks				dbrooks@osf.org
Systems Engineering, OSF		uunet!osf.org!dbrooks

rda614j@monu6.cc.monash.edu.au (Tooraj Enayati) (05/28/91)

In article <24450@lanl.gov> jlg@cochiti.lanl.gov (Jim Giles) writes:
>In article <1991May23.184302.13918@lut.fi>, junki@lut.fi (Juha Nurmela) writes:
>|> [...]
>|> puts("Please dim Your monitor with knob called brightness.");
>|> puts("Then key Your passwd terminating with ENTER and readjust the knob");
>|> gets(password);
>|> puts("\n\n\n\n ...50 times ... \n");
>
>Sun workstations don't have a brightness control knob.
>
>J. Giles

Why not use getpass()? It's much easier.
Here is man entery for getpass. It's should be available 
under most Unix systems.
-----------------------------------------------------------------
man getpass
 
GETPASS(3-ucb)         September 27, 1988          GETPASS(3-ucb)
 
NAME
     getpass - read a password
 
SYNOPSIS
     char *getpass(prompt)
     char *prompt;
 
DESCRIPTION
     Getpass reads a password from the file /dev/tty, or, if that
     cannot be opened, from the standard input, after prompting
     with the null-terminated string prompt and    disabling
     echoing.  A pointer is returned to a null-terminated string
     of at most 8 characters.

[some stuff deleted] 
--------------------------------------------------------------------
Tooraj

-- 
Tooraj Enayati e-mail address: rda614j@monu6.cc.monash.edu.au  | One planet
         Third year of B. Computing (Digital Technology)       | one people 
    Monash University, Caulfield Campus, Melbourne, AUSTRALIA  |   why...
     

sarima@tdatirv.UUCP (Stanley Friesen) (05/29/91)

In article <91147.164007TGREENIN@ESOC.BITNET> TGREENIN@ESOC.BITNET writes:
>Sorry, this just won't work with Teletypes. What you should do is
>
>1. Get the user to check noone is looking.
>2. ...
>5. If you want a *truly* secure routine, then prompt the user to
>   remove the ribbon (if appropriate) and burn it after the program
>   has finished running. ...

And, if the Teletype has a built-in paper tape punch, have the user make
sure it is turned off!

Seriously, I once walked into a public computer center and found a strip
of punched paper tape laying about.  When I checked out its contents it
was somebodies login - including password (and carriage returns and over-
strikes).

Luckily for that user I am a fairly considerate person - I destroyed the
tape and did not do anything nasty to his account.

Password security is *not* a trivial job.  [Just think about logging in
over a network with a packet monitor on it].
-- 
---------------
uunet!tdatirv!sarima				(Stanley Friesen)