systemd-ask-password echos password as asterisk (*) chars while decrypting LUKS partition

[rootkea]

Submission type

• Bug report

systemd version the issue has been seen with

systemd 232

Used distribution

Debian

In case of bug report: Expected behaviour you didn't see

systemd-ask-password should echo nothing by default.

In case of bug report: Unexpected behaviour you saw

Password gets echoed to screen as asterisk (*) characters. Echoing asterisk characters on screen is not at all consistent behavior with the traditional *Nix password handling. Here is the screenshot [0].

In case of bug report: Steps to reproduce the problem

I have encrypted swap and /home. When the system starts it asks password to
decrypt swap. The password doesn't get echoed at all. Totally expected
behavior.

But then it loads the kernel and systemd takes over. And systemd-ask-password
(I think as plymouth is not installed) asks the password to decrypt /home. And
this time password gets echoed to screen as asterisk (*) characters.

[0] https://imgur.com/bC4AF6H

[poettering]

press TAB to turn off echoing. Or press "backspace" as first key, which works too.

[rootkea]

@poettering Thanks! I know about TAB and BACKSPACE use to turn off the password echo.

The question is shouldn't the echo be turned off by default? i.e. may be use TAB and BACKSPACE to turn on the echo. But by default let's keep it off.

This makes the UI consistent with all other password handling in *nix systems e.g. sudo etc.

[poettering]

This makes the UI consistent with all other password handling in *nix systems e.g. sudo etc.

well, but giving feedback makes it consistent with password handling almost anywhere else...

Note that boot-time password prompts are a special case: they are often interleaved with other boot-time logging output, hence giving immediate feedback is a good thing, to show that something is happening...

[rootkea]

well, but giving feedback makes it consistent with password handling almost anywhere else...

Yes, you are right. But giving feedback while handling password is a GUI thing.

Almost all (actually, I am unaware of one which doesn't beside ask-password) of the CLI tools e.g. login, cryptsetup, sudo etc. have the convention to echo nothing while handling passwords.

giving immediate feedback is a good thing, to show that something is happening...

Yes, it is. But may be not for the CLI tool handling password. But if desired as a "feature", a key (e.g. TAB) can be configured to turn on the feedback.

I rest my case. ;)

[poettering]

Yes, you are right. But giving feedback while handling password is a GUI thing.

UI is UI. Good UI is good UI. Regardless if console or not.

Quite frankly I am pretty sure most console tools give no feedback because it requires more work to do, not because it was really a good idea.

[lo48576]

Feedback on CLI usually leave information about user password (i.e. we can know password length from Password: *** on terminal).
This is insecure, and I think this is the main reason why sudo, cryptsetup and other tools disables feedback on CLI.
On the other hand, GUI password dialog (and feedback "●" symbols) will disappear immedeately after user press Enter key, so in this case feedback will be less insecure.

Is password handling consistency more important than providing secure default?

[ilf]

I second this proposal. By default, console password prompts should not give feedback. A user option to enable that is perfectly fine.

[refi64]

Can you really determine much from password length though? A 15 character length password would take at least a thousand years to crack, and a good 10 character password would take around half a dozen years. If your password's secure, knowing the length won't help too much.

[ilf]

@kirbyfan64 Your argument works the other way around, too: If an attacker can observe that an entered and accepted password is only a handful of characters, it can be a serious incentive to brute-force it.

But even with 15 or 20 characters: Revealing the exact amount of characters drastically reduces the number of potential combinations.

[thorsummoner]

for googlers landing here, sudo's password feedback is toggled with the setting "pwfeedback", https://superuser.com/questions/1404382/disable-feedback-when-typing-password-at-a-sudo-prompt

I would like to know how to disable password feedback on luks prompt as well

[rootkea]

I would like to know how to disable password feedback on luks prompt as well

Currently, it seems that there is no way to achieve that permanently. Though you can turn off the echo temporarily each time you enter password on luks prompt by pressing TAB or BACKSPACE

It would have been great if the default behavior would have been to NOT echo or if the user could permanently set their choice by, say, editing a conf file.

[suddenlyfleck]

I agree with rookea: It would be great if the default behavior would be to not echo asterisks.

[keszybz]

Nowadays if allow people to look over your shoulder when entering a password, then you lost already: a serious attacker can covertly record your hands and keyboard and use machine-learning-enhanced algorithms to recover the password. Determining the password length would be even easier, that would be possible even from a sound recording without direct visibility. So protecting just the display of the length of password on screen doesn't make a big difference.

The current default is a reasonable tradeoff between easy of use and security. But we'd accept a patch to make this configurable if somebody wants to invest their time into this.