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.
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.
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.
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.
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 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.
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.
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.
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.
> 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
Those care about quickly sending compact messages over the network, but most of them do not create a sparse in-memory representation that you can read on the fly. Especially in javascript.
This lib keeps the compact representation at runtime and lets you read it without putting all the entities on the heap.
Amazon Ion has some support for this - items are length-prefixed so you can skip over them easily.
It falls down if you have e.g. an array of 1 million small items, because you still need to skip over 999999 items to get to the last one. It looks like RX adds some support for indexes to improve that.
I was in this situation where we needed to sparsely read huge JSON files. In the end we just switched to SQLite which handles all that perfectly. I'd probably still use it over RX, even though there's a somewhat awkward impedance mismatch between SQL and structs.
You really cannot see? The experience is vastly inferior: the required dongles have a huge list of annoyances, and you either cannot charge at the same time or have to use an ever more finicky splitting dongle.
> Without something like UCP, you are stuck doing [...] crawling.
I don't work in the area, but isn't this by design? Of course shops want to be discoverable by Google, but stopping competities from crawling and undercutting them is also very important.
Maybe this is different now that Amazon is the gatekeeper which can (ab)use this information anyway, and the incentive for shops to enable competing marketplaces is greater than frustrating competitors
I'm significantly younger but also programmer for two decades since my early teens and am experiencing something similar. CC is so freeing in that it makes those "nice but no time" ideas into reality by doing it next to your main project, almost feels like a drug.
It suddenly turns that dead time while you're waiting for CI, review or response into time where you can work on the fun or satisfying side projects by firing up a few prompts, check an iteration or 2, and then pause again until the next time or while the agent is doing its thing
I work in the customs industry. What you are describing was a common scheme (DDP Incoterms) to evade the tariffs (partially), and there is a carve out of the refunds that explicitly says DDP will not be refunded. So there's s chance you get nothing back.
Also contractually you didn't pay the duties so you wouldn't get refunds.
I am sure Ukrainians who built said nukes wouldn't have much problems figuring it out and building own nuclear program.
Instead believing in bright and peaceful future USA, France and UK promised. As Ukrainian who lived in Ukraine in 90s that felt like being on a frontier of the modern world, giving up the nukes. Oh, how full of hope we were.
