Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> 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.



> 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.


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."


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.


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


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.


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


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.


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.


Bruteforce search in increasing length order will find the password in within 1% of the same amount of time


> is about 1% smaller

Isn't it 10%?


If there are 9 different characters that can be in a password.


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.


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.


Well yes, but now that you get feedback while you type, it's much easier to have a longer password, because typos are much easier to spot and fix.

I generally use a (unique) 50-ish character passphrase anywhere I need to actually type it myself (and 64-character completely random ones elsewhere) and before this change, the passwords on my linux machines were shorter than that because it was impossible to spot/fix typos.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: