Hacker News Reader

Comment by ahofmann | Hacker News Reader

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.

View on HN

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.

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

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

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.

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.

Reply on news.ycombinator.com