Posted by akersten 14 hours ago
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…
These servers I had an account setup too were, from what I observed, partially linked with the authentication mechanism used by the VPN and IAM services. Like they'd have this mandatory password reset process and sometimes sudo was set to that new password, other times it was whatever was the old one. Couple that with the high latency connection and password authentication was horrible. You would never know if you mistyped something, or the password itself was incorrect or the password you pasted went through or got double pasted.
I think this is a great addition, but only if it leads to redhat adopting it which is what they were running on their VMs.
Moreover, if someone can see the number of asterisks on the screen, what prevents them from seeing the actual keys that are being pressed?
But yeh, never thought this was a problem anyone else delt with. My passwords are all a variant of my on "master password" and sometimes forget which session I'm in so trying to save keystrokes, count backward to where I think the cursor should be.
All the movement commands I know work the same in the terminal on a default install of macOS as it does in the terminal on various Linux distros I use.
Ctrl+A to go to beginning of line
Ctrl+E to go to end of line
Esc, B to jump cursor one word backwards
Esc, F to jump cursor one word forward
Ctrl+W to delete backwards until beginning of word
And so on
Both in current versions of macOS where zsh is the default shell, and in older versions of macOS where bash was the default shell.
Am I misunderstanding what you are referring to by shell motions?
But you should not type sudo passwords on remote machine. Instead setup your machinr to have nopassword for special sdmin account and enable pubkey only authentication.
I personally use the pam ssh agent module for this, that way you can use agent forwarding with sudo.
If you are on a high latency ssh connection and your password does not register, you most likely mistyped it.
The passwords get updated irregularly with the org IAM so you aren't sure what the password even is. Pasting doesn't work reliably sometimes, if you're on windows you need to right click to paste in terminals, sometimes a shortcut works. Neither gives me any feedback as to what event was ever registered though.
As for security: 'shoulder surfing' may not be as much of a concern, but watching a livestream or presentation of someone who uses sudo will now expose the password length over the internet (and it's recorded for posterity, so all the hackers can find it later!). They've just introduced a new vulnerability to the remote world.
Besides, I can just amplify their stream to hear their keypresses.
It helps 99% of the user base and the security risk seems negligible.
In your specific example livestreams usually have audio so the length is already public.
Also, I think the vulnerability of knowing that someone's password is exactly 19 characters long is low enough to be worth the tradeoff. Especially since someone on a livestream can also figure that out by listening for the keypresses.
In the modern world there is no plausible scenario where this would compromise a password that wouldn't otherwise also be compromised with equivalent effort.
Only if length is known. Which is true now. So it opens the gates to try passwords of specific known length.
For ascii at 95 printable chars you get 0.9894736842. Makes intuitive sense as the "weight" of each digit increases, taking away a digit matters less to the total combos.
Maybe I'll start using one Japanese Kanji to confuse would be hackers! They could spend hours trying to brute force it while wondering why they can't crack my one letter password they saw in my terminal prompt. ;)
In the early days we all shared computers. People would often stand behind you waiting to use it. It might even not have a screen, just a teletype, so there would be a hard copy of everything you entered. We probably didn't have account lockout controls either. Knowing the length of a password (which did not tend to be long) could be a critical bit of info to reduce a brute force attack.
Nowadays, not so much I think. And if you are paranoid about it, you can still set it back to the silent behaviour.
Or, we could just look at the keyboard as they type and gain a lot more information.
In an absolute sense not showing anything is safer. But it never really matters and just acts as a paper cut for all.
> When trained on keystrokes recorded by a nearby phone, the classifier achieved an accuracy of 95%, the highest accuracy seen without the use of a language model. When trained on keystrokes recorded using the video-conferencing software Zoom, an accuracy of 93% was achieved, a new best for the medium.
Have you ever watched a fast touch typist, someone that does over 100 words per minute? Someone who might be using an keyboard layout that you're not familiar with? When the full password is entered in less than a second it can be very difficult to discern what they typed unless you're actually recording with video.
But sure, if you're watching someone who types with one finger. Yes, I can see that.
Besides, observe that several times and you might get close. Look at the stars several times and learn nothing beyond what you learned the first time.
This whole type of attack hinges on the user using weak passwords with predictable elements in any case.
This wasn't someone seeing Chesterton's fence and deciding to knock it down thoughtlessly. This is a change that someone can in fact think all the way through and say "yeah, this should be changed, it's an improvement and doesn't cause any meaningful reduction in security".
Or think of TEMPEST attacks
`sudo` and `login` are I think the only two tools I use that don’t provide any feedback.
Otherwise my entire life is behind a password database that lets me see my password in plaintext and otherwise shows the length of it as it’s typed. KeepassXC.
If knowing how the length of your password makes it easy to crack you probably have other problems
I thought that was kinda clever; it gives you feedback when your keystrokes are recognized, but it's just enough confusion to keep a shoulder surfer from easily being able to tell the length of your password unless you're hunt-and-pecking every single letter.
I'm guessing that wasn't in the threat model at the time.
(# available characters) ^ (password length)
to
(# available characters) * (password length).
If you were patient you could crack someone's passwords by hand.
Of course, once you do understand that it's just a password prompt, it's great. Completely confuses the hell out of any shoulder surfers, who will for sure think it's a confusing puzzle, and eventually they will get rate limited.
^1: Example of it in use: https://www.youtube.com/watch?v=FvT44BSp3Uc
> That way you can be certain whether or not you entered a character
They can also count the number of keystrokes they heard.
I've seen this demonstrated, using "Cherry" type keyswitches, with about a 75% success rate.
I also knew an old guy who could tell what an ASR33 or Creed teleprinter was printing just by the sound, with "good enough" accuracy, and copy RTTY by ear with "good enough" accuracy.
He didn't really talk about his time in the Royal Signals in the 50s and 60s very much.
You can no longer filter out power users of computers based on their choice of OS alone. :D
"That way you can be certain..." absolutely not.
What's the benefit of having a random character from a random set, instead of just a random character?
I think if I was new to Linux that would confuse the life out of me :)
> For a time, there was rich pickings in applications that accepted passwords in unbuffered mode. Many of them doing it so that they could echo "*" symbols, character by character, as the user typed. That simple feature looks cool, and does give the user feedback ... but would leak the keystroke rate, which is the last thing you want on password entry.
This was in response to keystroke timing defense on SSH. Does this feature still come with the risk of leaking keystroke timing to an attacker with recent OpenSSH/Dropbear versions? If so, it might be wise to keep it disabled on servers.