391–400 of 421 posts
Earlier quoted context omitted.
Why is it better to have a nopassword admin account when using a machine remotely? The point of SSH is to resist mitm attacks, right? If someone could watch my keystrokes, I think I'd have bigger problems!
This resists scenarios where the machine you are running SSH from is compromised, and has a keylogger or something similar installed. SSH can't protect you from a local attacker (in fact, the SSH client binary itself could be the compromised part).
Earlier quoted context omitted.
You can tell if you input something or not, based on the blinking cursor, in which case it is not "frozen".
I mean a trivial solution to all of these work around a could have been each keystroke registers a single asterisk that goes away after a delay. You wouldn't reveal the length and you'd had a standard way of informing the user that their keystroke was registered.
Earlier quoted context omitted.
I'd be even happier if everyone adopted the old school Lotus 1-2-3 password behavior. I was much too young to use it myself, but I saw other people log in and it was amazing. The glyphs denoting hidden password characters changed on every keystroke to indicate you were typing. And IIRC, they were cool characters like Egyptian hieroglyphs too. (Presumably this wasn't some hash of your actual password - that would actu…
You're thinking of Lotus Notes, a completely different product. IIRC, originally it echoed one glyph per character typed, but later it definitely echoed 1 to 3 glyphs at random so it wouldn't leak your password length. The password thing was pretty cool, but it's literally the only good thing about Lotus Notes, which was the most archaic and primitive piece of commercial GUI software I've ever used in 45 years of sof…
Earlier quoted context omitted.
The number of times I’ve attempted to use Ctrl-U in a Python shell only to discover it doesn’t work…
Haven't seen this - shouldn't this always work on unixy platforms? If using readline/editline it works, and if built without it also works.
Earlier quoted context omitted.
> You obviously can't run unix_chkpwd against a local account without root. Wrong. At least check before you say something is obvious. > No, it's very simple. Even more wrong: https://github.com/linux-pam/linux-pam/issues/778#issuecomme... > feels like arguing with an LLM I could say the same about you, repeatedly and confidently asserting falsehoods.
No, I'm right. You can't run unix_chkpwd against a local account without root because you won't be able to access /etc/shadow to get the hash. If you think you can, explain how. Otherwise you have to use the setuid version which won't let you run it directly. And I just removed the delay using my method. Perhaps try checking something yourself?
> You can't run unix_chkpwd against a local account without root because you won't be able to access /etc/shadow to get the hash.
unix_chkpwd can access /etc/shadow because it is suid.
> Otherwise you have to use the setuid version which won't let you run it directly.
Haha you mean this?
$ unix_chkpwd
This binary is not designed for running in this way
-- the system administrator has been informed
> Perhaps try checking something yourself?
I have. You haven't.
printf 'hunter2\0' | unix_chkpwd yourusername nullok; echo $?Somebody tell Apple to fix the login screen for MacOS as well. If your password is longer than the incredibly narrow box, you do not get any additional feedback that your characters are being entered. Combine that with a flaky keyboard (say from a single grain of dust where it shouldn’t be) and you get a very annoying login experience. Over and over…
Earlier quoted context omitted.
As a general rule, if you have an adversary that cares that much you’re probably doomed. Presumably they’re capable of buying a $5 wrench to physically use against you.
Unless they want to compromise you secretly.
Or just plugging a device into your laptop while you’re not looking and stealing all your session state for browsers.
Earlier quoted context omitted.
If the hash changes after every character, doesn't that make it possible for someone to determine your password one character at a time if they know what each hash was? I'm guessing that wasn't in the threat model at the time.
Hmm. Let's say you have 64 possible characters you can use in a password and four different images. You look over someone's shoulder and see that they go "RGBYYBRYG". What this means is that you can now reduce your search space to approximately 16^9 passwords instead of 64^9 passwords. Which is probably very helpful if you have stolen the password hash, but not if you have to guess it by entering the password manuall…
Earlier quoted context omitted.
Doesn't really matter, the IME shows the input until you confirm which kanji you want.
When the IME inserts the character, it'll be made up of multiple bytes because of the nature of UTF-8, so it may appear as multiple asterisks regardless.
At the very least, all GNU tools put a lot of focus on localization support, and I hope sudo-rs is the same.