| |
| ▲ | hrmtst93837 an hour ago | parent | next [-] | | This is security theater. Masking sudo input does nothing against keyloggers, shoulder-surfing, or anyone reading your terminal, and pretending password length is the deciding leak ignores the much larger attack surface around a compromised box. If password length is where your threat model gets scary you've already lost. | |
| ▲ | 9dev 15 hours ago | parent | prev | next [-] | | Yet somehow, none of the other high security tools I have ever interacted with seem to do this for some reason. No auditor flags it. No security standard recommends hiding it. But SUDO is the one bastion where it is absolutely essential to not offer hiding keystrokes as an obscure config option, but enable for everyone and their mother? | | |
| ▲ | 13 hours ago | parent | next [-] | | [deleted] | |
| ▲ | creatonez 14 hours ago | parent | prev [-] | | And once you start adding these accessibility problems, people will respond by using weaker passwords. |
| |
| ▲ | baq 13 hours ago | parent | prev | next [-] | | > Because to hell with UX when it comes to security. I don’t think you have any idea how wrong you are. | |
| ▲ | plorkyeran 7 hours ago | parent | prev [-] | | Bad security UX that results in users bypassing security mechanisms entirely is probably the single biggest source of real-world security problems. |
|
| |
| ▲ | mikkupikku 14 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 12 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 7 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 15 hours ago | parent | prev | next [-] | | I would be worried more about leaking the timing of the key presses. | |
| ▲ | gzread 15 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 15 hours ago | parent [-] | | It narrows down the brute force domain by several orders of magnitude | | |
| ▲ | gzread 15 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 13 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 12 hours ago | parent [-] | | Bruteforce search in increasing length order will find the password in within 1% of the same amount of time |
| |
| ▲ | themafia 12 hours ago | parent | prev [-] | | > is about 1% smaller Isn't it 10%? | | |
| ▲ | gzread 12 hours ago | parent [-] | | If there are 9 different characters that can be in a password. |
|
| |
| ▲ | 15 hours ago | parent | prev | next [-] | | [deleted] | |
| ▲ | emil-lp 15 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 12 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. |
|
|
|
|
