6

On the mainframe OSes I was familiar with, and on UNIX to that day, when there is a prompt for a password in "text mode" (a command line session), the echo is suppressed, and there is no visual feedback for the entered characters at all. This makes it hard for an onlooker to figure out the number of characters in a password.

The first OS that I remember seeing a visual feedback (asterisks) when entering passwords, was MS-DOS. While it is more convenient for the user who types the password, it is arguably less secure. Nowadays the password fields in GUIs have visual feedback (bullets) by default, in applications (browsers) as well as in the system programs (graphical login screens); I'm not even sure if that's configurable.

What was the rationale for deciding to provide a visual feedback for password entry, and what OS was the first to feature this mode in a system program?

Improve this question
1
  • 1
    Comments are not for extended discussion; this conversation has been moved to chat.
    – Matt Lacey ♦
    Apr 23 '18 at 5:47
2

The question as phrased probably can't be answered, but a few related data points:

As mentioned in the comments, passwords on all IBM 3270-style terminals are usually entered in fields with an "invisible" attribute. In practice, that means you can see the cursor moving, and as the password field is usually below some other field, e.g. the username, it's also pretty easy to count characters. I would count this definitely under "visual feedback".

The NOS Interactive Facility would present a "character salad" on the teletype, which you'd then overtype with your password (see page 2-6). Which, like above, means you'd see the printing head move, so you could count characters, but you couldn't read the character you typed. I'd consider this as the same kind of "visual feedback". This may or may not be the system mentioned in the comments.

The manual is from 1979, but I would assume this feature was present in earlier versions as well.

Incidentally, the Plato System, which ran on NOS, and had a special video terminal, displayed one or two X for each character that you entered as a password. So this is a variant: visual feedback, but it doesn't allow an onlooker to count the characters in the password, but it also makes it harder for the user to verify if the password he types is correct.

In general, typing passwords only makes sense on multiuser timesharing systems, so the first such system (whatever it is) would provide a lower bound. Given that many teletypes had local echo, printing asterisks instead of chars (and removing them on backspace) makes more sense for videoterminals, so if you are applying stricter criteria, that's another bound.

The rationale for providing any kind of feedback for password entry should be pretty obvious: It makes mistakes less likely. So the design space is somewhere between "not implemented because there's always local echo, we must use some other way" over "let's provide an invisible attribute in our video terminal" to "all echoing is done by the host anyway, and we've plenty of memory, so why not make it more comfortable for the user?"

Improve this answer
4
  • Right, and what I'm asking is which (multiuser timesharing) system was the first to implement "all echoing is done by the host anyway, and we've plenty of memory, so why not make it more comfortable for the user". IMO, the idea that echoing can be "magic" requires some mental leap, and that makes it interesting who and when came up with it first.
    – Leo B.
    Apr 21 '18 at 17:09
  • 1
    There were plenty of systems that did something with passwords before that, so there certainly isn't some "magical leap" that about implementing this in a setting where echoing by the host happened to be the default - which came about by totally unrelated technical developments (more computing power in hosts, use of video terminals). Anyone who would have used some of the older systems that did something with passwords would have automatically thought about it, no magic required. So IMHO you are picking some totally random criterion and pretend it's somehow interesting, when it really isn't.
    – dirkt
    Apr 21 '18 at 17:44
  • Still, in UNIX it was never done, although echoing by the host happened to be the default since its beginning. One can say that UNIX was never about making it comfortable for the user in all regards including this one; then which system was?
    – Leo B.
    Apr 21 '18 at 17:51
  • 1
    It's a more or less random design decision by whoever implemented the password check. All systems include some means of making the password invisible, this was a clearly perceived necessity. Beyond that, it's a matter of taste. Just like many other things are a matter of taste.
    – dirkt
    Apr 21 '18 at 18:39
3

IITROS was a 1972-era Univac 1108 remote batch system using ASR 33 teletypes, written and hosted at the Illinois Institute of Technology. The teletypes had half-duplex acoustic coupler connections, so everything typed was locally echoed on that paper. To avoid the password being readable, it would print a bunch of characters (12?), CR, more characters, CR, a few more times to make a black blob on the line. You'd type your password on the blob, where it wouldn't be visible.

It also had a cute prompt: If it was waiting for input, it would periodically send an invisible character (I think it was NULL, but not sure) which would make the motor cycle and the typehead (the little cylinder that had the embossed characters) dip. It was like the machine was sitting there tapping it's foot waiting for you to pay attention...

enter image description here

Improve this answer
3
  • Nice photo, but the "character salad" variant had been covered in the previous answer.
    – Leo B.
    May 30 '18 at 5:19
  • The idea of "character salad" is not new; its usage for carbon copies of documents where the amount or the signature has to be hidden is older than computers. I've accepted the part of the answer that talks about the Plato system with its probabilistic echo.
    – Leo B.
    May 30 '18 at 5:38
  • 1
    Even today on socket connections, the idea of sending a NUL periodically could have some merit in cases where it wouldn't cause trouble. If an application can't otherwise ensure its connection will use TCP keep-alive with a timeout that would be reasonable for the application's purposes, it may have no way of discovering in timely fashion when its connection is broken. Sending anything over a broken connection may result in the host finding out about the connection loss much sooner than it otherwise would.
    – supercat
    May 30 '18 at 15:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.