Hide password

Your method doesn't work: it requires the user to press the enter key for each character.
Moreover, a cleared screen might reappear on some OS when scrolling up.

no, you can simply create a loop (getchar in memory but it goes back) that waits for just 1 character, whatever it may be. You then handle that character (enter or not) afterwards.

Je suis désolé, mais je ne peux pas accéder aux sites web ou fournir de contenu provenant de liens externes. Cependant, si vous avez un texte spécifique que vous souhaitez traduire, veuillez le copier ici et je me ferai un plaisir de le traduire pour vous.

You are missing a basic concept in C...
Standard input functions (getchar(), ...) do not read from the keyboard but from its buffer. However, for a character to enter the keyboard buffer, you must press the enter key.
The only way is to switch to raw mode () as Dal mentioned.

Ah there, I think that's it: readKey. (It's been 5/6 years, huh... and now I work a lot on Windev T_T)
It returns the integer value of the key pressed (after that, you just have to refer to ASCII).

Writing a * is not much more complicated than setting the terminal to raw.
With your first link, you set the terminal to raw. As soon as you read the character entered by the user, you display a '*'. Nothing more.

Hi fiddy,

When allowing the user to input something, it's also nice to let them erase their input :-), and therefore to handle the backspace key so that it deletes the previously entered character (the asterisk), potentially up to the first asterisk, and manage the data accordingly... and also handle the enter key, of course.

So, if we want to properly manage this type of user interface, we need to go a bit further.

fgets used in the first link doesn't allow for this, as it only handles a stream and waits for ENTER (or EOF).

I think getchar could be used, with line buffering disabled (by playing with ICANON) in addition to echo, and send \b as shown in the second link to erase the displayed asterisk.

In short, we can do without ncurses, but it’s not trivial (with ncurses or not, by the way), to manage "asterisks", instead of simply returning nothing.


Dal

[Dal],
You're forgetting a detail.
I'm okay with handling the backspace key. But it needs to be done in both cases (with star display or without). Indeed, in raw mode, each backspace will produce a character in the string.

No, if only the echo is disabled, the terminal works without echo but with line buffering, and therefore the backspace key is handled (like the enter key) without you having to manage it yourself (as proposed in the code on SO, here https://stackoverflow.com/questions/1196418/getting-a-password-in-c-without-using-getpass-3).

It is only if you want to "see stars" that you need to disable line buffering, also disabling canonical mode, as proposed in my adapted code here: https://forums.commentcamarche.net/forum/affich-27337373-masquer-mot-de-passe#13.


Dal

But then, it's simpler to just cancel the echo on the terminal, to avoid having to display the stars and manage everything that comes with it, and just do as described in the first link posted:

https://stackoverflow.com/questions/1196418/getting-a-password-in-c-without-using-getpass-3

It's also safer, apparently, because a person looking at the screen won't be able to count the stars and deduce the number of characters in the password.


Dal

it's easier to just cancel the echo on the terminal, so you don't have to display the stars and manage everything that comes with it
In raw mode, backspace displays a character. So this will cause a star to be displayed. But it remains consistent with the input of the character into the character string. If you handle backspace, you will have to do it for both variants. But I admit it will be a bit simpler in the variant without display.

For safety, I agree. There's no contest :-).

By passing the appropriate parameters to the termios struct, you can finely control the behavior of the console, and set the c_lflag field so that ECHO is removed while maintaining ICANON.

https://pubs.opengroup.org/onlinepubs/7908799/xsh/tcsetattr.html
https://pubs.opengroup.org/onlinepubs/7908799/xsh/termios.h.html

This excerpt from man 3 tcflow is clearer on the matter:

Canonical and noncanonical mode The setting of the ICANON canon flag in c_lflag determines whether the terminal is operating in canonical mode (ICANON set) or noncanonical mode (ICANON unset). By default, ICANON set. In canonical mode: * Input is made available line by line. An input line is available when one of the line delimiters is typed (NL, EOL, EOL2; or EOF at the start of line). Except in the case of EOF, the line delimiter is included in the buffer returned by read(2). * Line editing is enabled (ERASE, KILL; and if the IEXTEN flag is set: WERASE, REPRINT, LNEXT). A read(2) returns at most one line of input; if the read(2) requested fewer bytes than are available in the current line of input, then only as many bytes as requested are read, and the remaining characters will be available for a future read(2). In noncanonical mode input is available immediately (without the user having to type a line-delimiter character), and line editing is disabled.

Thus, by keeping the "canonical mode", backspace, enter, etc., behave normally, even though echo is removed, because the terminal continues to process lines.

Regarding security, it’s more than just using the stty system command (which has the same level of complexity), but it can be subject to workarounds, as shown in my proof of concept here https://forums.commentcamarche.net/forum/affich-27337373-masquer-mot-de-passe#24


Dal

... who finds that reading this topic is becoming complicated.

Good idea not to display the stars.
However, the use of system("stty -echo"); should be banned as it poses security issues and it's not even posix.
But if these limits don't bother you, there's an even simpler solution with the getpass() function that will do what you want directly ;-).
And just for your information, be careful with fgets(), the '\n' will be stored in your pass string if there's room for it.

Yes, as Fiddy said, calling an external command is not great.

Here is your code with the correction on the string retrieved by fgets suggested by Fiddy:

$ cat aadilove.c #include <stdio.h> #include <stdlib.h> #include <string.h> int main(void) { char passe[11]; char *p; printf(" Password: "); /* after this line every typed character * should be hidden, unless a user * has substituted the stty command */ system("stty -echo"); fgets(passe, sizeof(passe), stdin); if ((p = strchr(passe, '\n')) != NULL) *p = '\0'; /* switch back to normal mode */ system("stty echo"); printf("\nYou typed %s, but nothing " "was supposed to display upon entry\n", passe); return 0; }

Here is a "normal" execution of this code:

$ gcc -Wall aadilove.c -o aadilove $ ./aadilove Password: You typed toto, but nothing was supposed to display upon entry

And here’s an example of what a user, even a non-privileged one, can do with this code (in this case, with the sh - Bourne Shell, adapt for another shell how environment variables are handled):

$ whereis stty stty: /bin/stty /usr/src/bin/stty $ echo $PATH /sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin:/usr/X11R6/bin:/home/ccm/bin $ pwd /usr/home/ccm/temp/testcommandsub $ PATH=/usr/home/ccm/temp/testcommandsub:$PATH $ export PATH $ echo "echo 'hello'" > stty ; chmod +x stty $ ./aadilove hello Password: toto hello You typed toto, but nothing was supposed to display upon entry 

You should at least put the full path of stty ("/bin/stty" in my case) in your system command. This is not practical, because one could imagine that a system places it elsewhere. Then, you are also not safe from this command being replaced by another that performs tricks (that will be more difficult), or potential vulnerabilities of this command.


Dal

Exactly the security flaw I was thinking of.

You should at least provide the full path of stty
It doesn't change anything ^^. Just 6 more characters to type (not counting the enter key ^^) to bypass the call to /bin/stty. And we can start playing with the PATH again. Although it seems to me that this trick has been fixed in kernels above 2.4. It's better to use the exec() family.
Or even better, your program above :-)