Hacker News Reader

Comment by applfanboysbgon | Hacker News Reader

It's open-source, so just build it yourself with the tiny change. Something this trivial could be done with a 30 second prompt at this point, so there's not even an excuse of "too much effort".

I will note that the XKCD password scheme being proposed there is, in fact, completely insecure. A modern consumer GPU can crack "four random English words" in a day. You can argue that it's the user's choice to be allowed to use insecure passwords, but arguing that that scheme is actually secure is just wrong.

View on HN

> A modern consumer GPU can crack "four random English words" in a day.

Let's run the math:

EFF's long wordlist[0] (the one used by Bitwarden's passphrase generator) has 7776 words, which is about 13 bits of entropy per word (log2(7776) = 12.92). A 4-word passphrase then has 51.7 bits of entropy, meaning there are 2^51.7 possible options for the passphrase, which is 3.66E15 possible options.

For reference, a password with all completely random characters and symbols, for each character you have 70 possibilities, or about 6 bits of entropy. An 8-character completely random password (no words or the usual patterns) then has about 49 bits of entropy, which is less than a 4 word passphrase.

About the time it takes to crack it, assuming you can test an average of 1 password per μs (you probably can't, as passwords are usually stored using key derivation functions[1][2] with work factors tweaked for current hardware) it would take ~116 years to crack it. I usually see 5-passphrase recommended nowadays, which would multiply the required effort by 7776.

Sure, a 16-character random password has a lot more entropy, but it's also a lot harder to interact with (reading, comparing, typing) if you end up needing to, and it's still easier to crack than an 8-word passphrase.

[0] https://www.eff.org/dice [1] https://en.wikipedia.org/wiki/Key_derivation_function [2] https://cheatsheetseries.owasp.org/cheatsheets/Password_Stor...

> A modern consumer GPU can crack "four random English words" in a day. [...] but arguing that that scheme is actually secure is just wrong.

Let me do just that!

This is a networked service. You send your password (or a hashed form) to it, and it validates it. You don't have the local hash to bruteforce it offline.

Even if we only consider the top 10k english words, it's 10000^4. It's going to take years to bruteforce this over a network because you'll go through so many rate-limits, cooldown periods, and outright bans that it's questionable whether it's even possible.

Virtually any password other than "password123" is fine if you're rate limited to a few guesses per day by a networked service. Passwords should be secure against the inevitable data breach when the service you're using loses their hashed password database, which happens on a routine basis.

Seems like the only real issue here is that rustdesk uses SHA256 instead of argon2.

> This is a networked service. You send your password (or a hashed form) to it

Hopefully neither. But given everybody involved in VNC seems to be the same batch of clueless morons who built all those PHP web forums twenty years ago with MD5 as the password hash, who knows what they cobbled together. Maybe an expert can chime in about what actually happens here?

Yes, for a sensible scheme this can't work.

I’m not an expert in RustDesk, but I did take a quick look at the code, and it’s filled with massive red flags like [1], where it appears the general mechanism is SHA256(SHA256(password++salt)++challenge). I can’t even tell if the whole thing is vulnerable to trivial MITM ([2] makes it sound like it might be; while investigating, I ran into the concerning comment [3], “fall back to non-secure connection in case pk mismatch”). I can’t find any actual documentation of the protocol and it’s a custom thing built on NaCl boxes, yikes. [4] generates a keypair on the fly for a new connection to sign the box containing the symmetric key generated at the same time…

I would recommend never using this software.

[1]: https://github.com/rustdesk/rustdesk/blob/7aa98d43cf1962a7a2... [2]: https://github.com/rustdesk/rustdesk/discussions/8392 [3]: https://github.com/rustdesk/rustdesk/blob/7aa98d43cf1962a7a2... [4]: https://github.com/rustdesk/rustdesk/blob/7aa98d43cf1962a7a2...

> A modern consumer GPU can crack "four random English words" in a day.

This is just completely false.

> the XKCD password scheme being proposed there

I proposed replacing the ridiculous checklist with zxcvbn.

I agree xkcd's scheme is a bad example and distracts from the real point, which is that a checklist is fundamentally bad, not that some specific password format should be allowed.

Did you even check what hash they are using?

SHA-256. Did you? My point isn't constrained to this exact service, though. My point is that the XKCD-style passphrase is in general not secure. If you make a habit of using it, assuming that the service in question will take care of securing it super duper safely on your behalf, you will get bitten when a service doesn't do this.

If character class constraints are enforced then that password becomes incredibly strong though - e.g. require a capital, and special characters and a number.

Plenty of sentence passwords meet that but now the probability space has exploded.

> A modern consumer GPU can crack "four random English words" in a day.

Sure, if you can rely on users using a specific format. The joy of the xkcd technique is you don't need to tell other people what yours is.

But, people just aren't going to remember strings of gibberish. Expecting users to do this is just silly.

The "joy of the XKCD technique" is that it prescribes a specific format millions of people will use, and it's so trivial to break that you can throw it into your cracking algorithm at virtually no cost.

If you were willing to use a bespoke, more secure variation of it, you could include a capital letter and a number rather than filing an issue on a repo insisting that you be allowed to use exactly the insecure variation.

I think you are both greatly overestimating the number of people who remember what xkcd is and their willingness to do what a webcomic prescribes uncritically. What you describe as "bespoke" is likely the normal way someone might use it: with their chosen format.

For instance, I have multiple separator characters, multiple beginning and end characters, and numbers places at specific places, and arbitrary casing. That may be overkill but it's still essentially the xkcd format.

> I think you are both greatly overestimating the number of people who remember what xkcd is and their willingness to do what a webcomic prescribes uncritically

XKCD's youtube videos get millions of views each. It is a very popular comic, and that particular password advice has spread beyond it.

> What you describe as "bespoke" is likely the normal way someone might use it.

And yet the issue in question is about someone who refuses to adapt it.

The user in question might have their own personal format that doesn't meet the RustDesk constraints. E.g. they may not use capitals, but use `word1$word2&word3@word4`.

Tayloring your format to the requirements of each site is a step towards defeating the utility of the system; now the user needs to remember some arbitrary hard-to-remember details for each password.

Although having a standard format for your passphrases across sites removes some of the advantages over just using the exact xkdc format (when one of your passwords is compromised and attackers can guess your custom format elsewhere now)...

This is a non-issue with a password manager

"Look up - there's 7 polywaffles in the sky!"

That phrase will pass almost every single password requirement, and no one is going to crack it by brute force dictionary attack.

> And yet the issue in question is about someone who refuses to adapt it.

Does this person exist?

Reply on news.ycombinator.com