> easier to turn echo on and off than to echo asterisks.

One implies the other. You turn echo off. Then you write asterisks.

> Not for security.

Consider the case of copy and pasting parts of your terminal to build instructions or to share something like a bug report. Or screen sharing in general. You are then leaking the length of your password. This isn't necessarily disastrous for most use cases but it is a negative security attribute.

▲

mikkupikku 16 hours ago | parent | next [-]

> One implies the other. You turn echo off. Then you write asterisks.

That's not how it works. Sudo turns off echo but otherwise keeps the terminal in it's normal cooked canonocal mode, meaning sudo only sees what you've entered after you hit enter. To print asteriks as you type requires putting the terminal in raw mode, which has the addition consequence of needing to implement shit like backspace yourself. Still a UX win worth doing, but it's pretty clear that skipping that and just disabling echo is an easier lazier implementation.

▲

themafia 14 hours ago | parent [-]

You're correct, but, the echo and canonical mode flags are literally in the same termios structure member. One is no more complicated to change than the other. You can also easily switch to character at a time read() which makes handling backspace, erase or kill exceedingly simple.

I still doubt the claim the scheme employed by sudo was done because it "was easier."

	▲	mikkupikku 8 hours ago \| parent [-]
		The first is like 3 lines of code, to get the attrs, disable the echo flag then set the attrs again. The second is.. I don't know probably about twenty lines of code to handle the primitive line editing yourself and also asterisk printing. In my view, this is enough of a difference to motivate a conclusion that the first is good enough. Also note that this decision was made back in the early 70s when login was first implemented, and it established a convention which was very easy and convienent to carry forward to su and later sudo.

▲

uecker 17 hours ago | parent | prev | next [-]

I would be worried more about leaking the timing of the key presses.

▲

gzread 16 hours ago | parent | prev [-]

Leaking the length of your password is about as bad for security as leaking the fact that you have a password, or that you use sudo.

▲

ikari_pl 16 hours ago | parent [-]

It narrows down the brute force domain by several orders of magnitude

▲

gzread 16 hours ago | parent | next [-]

No, it doesn't. The set of all passwords of exactly length N is about 1% smaller than the set of all passwords up to and including length N.

▲

adrian_b 14 hours ago | parent | next [-]

The point is that you know that the password is not longer than N.

This indeed reduces the search domain by many orders of magnitude, i.e. by more than an order of magnitude for each character that you now know that it is not used by the password.

Knowing the length of the password does not matter only in antediluvian systems, which had severe restrictions on the length of a password, so you already knew that the password is no longer than, e.g., 8 characters.

	▲	gzread 13 hours ago \| parent [-]
		Bruteforce search in increasing length order will find the password in within 1% of the same amount of time

▲

themafia 13 hours ago | parent | prev [-]

> is about 1% smaller

Isn't it 10%?

	▲	gzread 13 hours ago \| parent [-]
		If there are 9 different characters that can be in a password.

▲

16 hours ago | parent | prev | next [-]

[deleted]

▲

emil-lp 16 hours ago | parent | prev [-]

That's obviously false. It narrows it down less than a factor the length of the password, so unless your password is several orders of magnitude, it lowers narrows by a factor of ~8.

	▲	adrian_b 14 hours ago \| parent [-]
		That is obviously true, not false. If you know that a password is no longer than, e.g., 10 characters, that narrows down the search domain by many, many orders of magnitude, in comparison with the case when you did not know this and you had to assume that the password could have been, e.g. 18 characters long. If you test the possible passwords in increasing length, then knowing the length would not shorten much the search, but not knowing the length may prevent an attempt to search the password by brute force, as such an attempt would fail for longer passwords, so it is not worthwhile to do unless success is expected. With modern hashing schemes, which require both a lot of time and a lot of memory for each tested password, even one extra character in the password can make the difference between a password that can be cracked in a useful time and one that would take too much time to crack, so knowing the length can be very important for the decision of an attacker of trying the exhaustive search approach. Knowing the length is less important only for the users who are expected to choose easy to guess passwords, as there are much less of those than the possible random passwords.