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

This is such a good decision. It's one of those things that's incredibly confusing initially, but you get so used to it over the years, I even forgot it was a quirk.

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.

 help



I also think it is a good decision. Nevertheless it breaks the workflow of at least one person. My father's Linux password is one character. I didn't knew this when I supported him over screen sharing methods, because I couldn't see it. He told me, so now I know. But the silent prompt protected that fact. It is still a good decision, an one character password is useless from a security standpoint.

If it breaks the workflow of one person but makes it better for many more, it's likely a worthwhile tradeoff.

Just add an option to let holding space keep my feet warm. It only needs a few extra lines that won't change.

How much would unknown password length protect against bruteforcing a 1 character password?

This has always been an option and your dad can just flip the default back to not show it

I may or may not use a single char password on a certain machine. This char may or may not be a single space. It may or may not be used in FDE. It's surprising what (OS installers) this breaks.

> It is still a good decision, an one character password is useless from a security standpoint.

Only if length is known. Which is true now. So it opens the gates to try passwords of specific known length.


If you are brute forcing passwords, knowing the length only reduces the number of passwords to try by like 1 hundredth.

Drats, you're right. I thought it'd be worse, but the ratio seems to only depend on the number of letters in your character set: 1/count(letters in alphabet).

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


I’ve occasionally contemplated using some non-ASCII character like • or š in a password, but have backed off for fear of needing access from a device that doesn’t support input of those characters.

Its funny how a single japanese symbol would be harder to crack than the anglicized name for it

Do we know if the asterisks count Unicode code points rather than bytes?

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.

Most software, traditional sudo included, would respect the LC_CTYPE being set to an UTF-8 (or any of the older multi-byte encodings), and do proper character counting.

At the very least, all GNU tools put a lot of focus on localization support, and I hope sudo-rs is the same.


Having LC_CTYPE bit set to utf8 would be my worry. Would suck to not be able to logging because the LC* lang changed.

Hmmm, hopefully sudo-rs respects LC* env vars. I recall reading a few years back that some Rust Unix tools skipped that and won big on benchmarks until folks realized they weren’t handling NC localization properly.


It also give you the possibility of filtering out which ones are worth cracking and which ones not

It could also give useful priors for targeted attacks, "Their password is 5 characters, and their daughters name is also 5 characters, let's try variations of that".

Some system accessible to hackers who can see the length of the password /and/ having a single 5 char password has a security of a key under a doormat.

Maybe this is far fetched, but you could get an LLM-based auto-research system to extract these potential relationships

Yes… We're in the same room as the target… Let's look at their screen and see how long their password is.

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.


And just sticking to counting, a not exceptionally well-trained ear could already count how many letters you typed and if you pressed backspace (at least with the double-width backspace, sound is definitely different)

Yeah I recall that there was an attack researchers demonstrated years back of using recordings of typing with an AI model to predict the typed text with some accuracy. Something to do with the timings of letter pairings, among other things.

93% - 95% accuracy and it wasn't even a good quality recording

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

https://arxiv.org/abs/2308.01074


Notably, I believe this has to be tuned to each specific environment. The acoustics of your keyboard are going to be different from mine. Which is not much of a barrier, given a long enough session where you can presumably record them typing non password-y things.

"Let's look at their screen and see how long their password is." This article is about silent sudo.

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.


How is learning only the length of the password better than watching someone type it?

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.


I tend to agree, and I work in security.

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.


On the other hand streaming is way, way more common nowadays.

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

Not sure about that. I'm no expert but for high risk scenarios one might have to worry about binoculars from the building opposite your window, power line monitoring, and timing attacks. All scenarios where the attacker cannot see your hands/keyboard.


Typed passwords can be reliably determined only through timing, so exposing the timing of the input can be exploited. e.g. screen sharing, or anyone who can see your screen



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

Search: