> RustDesk still does not support encrypted connections when self hosting
Not true at all. RustDesk connections are fully encrypted even when using a self-hosted server. What is not supported are encrypted direct endpoint-to-endpoint connections not going through a server at all, because that's not a use case RustDesk is designed for. The feature is intended for testing, which is why it's disabled altogether by default.
If your use case is focused on direct connections without a server, RustDesk is the wrong tool for the job. It's an open-source self-hostable analog to Teamviewer, the server is inherent to the design.
anakaine 13 minutes ago [-]
So, to have end to end encryption you need to do something like:
Client -- Relay Server -- Host
That's certainly less than ideal since many remote desktop session will not be using a middle-age server but rather be direct between client and host.
SubiculumCode 1 days ago [-]
I think you bring up a fine point. Most applications have encryption built in and transparent to the user. While technical IT people in charge of infrastructure will not make this assumption, it is not unreasonable, at the same time, for small business / individual users, to not understand or know of this limitation.
VNC does not, for example, and you need to set up port forwarding through ssh.
X2Go does....but I don't trust it terribly. So, RustDesk..what do you need to wrap it in? ssh?
I really want a better solution that VNC/X2Go..especially since I use hardware accelerated apps that need to use VGL to operate correctly (but underwhich operation is quite buggy).
aruggirello 7 hours ago [-]
RustDesk already encrypts connections going via Relay. Encryption is missing in direct IP to IP connections only - but you could set up an SSH tunnel, or a SOCKS or HTTPS proxy though.
Another valid alternative is Xpra, and it does support Wayland too - but doesn't reach feature parity with X11. Like RustDesk, Xpra is similarly feature-rich and mature, it too can take advantage of SSH tunnels, SOCKS or HTTPS proxies etc.
And then there's TeamViewer and AnyDesk - both of which are paid, with a free tier for evaluating or personal use - RustDesk is younger, but feature-wise they're quite similar.
Finally, you could set up wireguard that will happily encrypt your connection with very little overhead - regardless of your chosen remote desktop solution.
NewJazz 19 hours ago [-]
You could wrap in a wireguard tunnel.
dj0k3r 1 days ago [-]
Tailscale, or any encrypted mesh overlay is perfect for this. Infact I prefer it that way. Rustdesk can do what it does best at its core.
preisschild 1 days ago [-]
I disagree, modern software should make encrypted connections over something like HTTP3 or QUIC directly so true secure end to end connectivity works. This would make VPN software such as tailscale obsolete.
mnahkies 1 days ago [-]
One of my primary use cases for tailscale/VPN is that I can happily run stuff (grafana, gitea, etc) and not have to be panicked about monitoring for CVEs - I serve it all over HTTPS but I don't want to put it on the public internet if I don't need to.
preisschild 10 hours ago [-]
I just have envoy proxy with the oauth + jwt filter in front of those services. Envoy does the oidc flow with pocket-id so I can use passkeys for authN. Envoy validates the resulting token and does authorization via ACL. Envoy then sends an authorization bearer jwt with the oidc id_token jwt to the backend (for example grafana). Grafana parses and validates the jwt and sets claims as userinfo (username, groups, email).
I think such setups are at least as secure as having tailscale in front of it and they are web standards conform. I dont need a client app like tailscale, I can just use my normal browser and internet conn.
I always make sure envoy/all other apps are on the latest security patcb anyways.
mnahkies 9 hours ago [-]
It's funny you say that, as one of my weekend projects today is setting up https://www.authelia.com/ to achieve the same.
I probably won't allow everything through it (eg: postgres, clickhouse etc can stay on tailscale), but I've been stumbling into use cases where I want to share things with friends or colleagues, and I don't want to put them on my tailnet.
ZoomZoomZoom 13 hours ago [-]
Secure and censorship-resistant connectivity is very hard. We should compartmentalise and not expect everything to reimplement and maintain their own version of it and focus on specialised solutions that actually work.
What all user-facing software should have is a minimal-overhead connection option to improve performance inside user's tunnel of choice.
Pure QUIC gets blocked easily, SSH requires wrapping, even Tailscale mimicry is basic and they still ignore simple protocol improvements available.
elevation 1 days ago [-]
I'm also in favor of adding encrypted connections to RustDesk, not to replace tailscale, but as a part of this complete breakfast. Tailscale provides mutually authenticated, authorized L3 access. TLS can be configured to provide mutually authenticated L4 access. With a little OIDC/webauthn setup, both L3/L4 support device attestation, meaning there's no way to connect without e.g. a yubikey (or perhaps an enrolled TPM.)
thatfunkymunki 1 days ago [-]
agreed, zero-trust solution with proper endpoint security and PKI is superior to transport encryption and insecure protocols
jcelerier 1 days ago [-]
so without tailscale or any other intermediary turn service how does my computer behind a NAT connect to another computer behind another NAT
preisschild 1 days ago [-]
Ideally using ipv6 without NAT, but yeah hole punching or quic address discovery like iroh does works too
LoganDark 18 hours ago [-]
and how do you discover the ipv6 address? memorize it? many ISPs don't listen to informational documents listing all the problems with random dynamic prefixes.
jcgl 15 hours ago [-]
Dynamic DNS is fine for many use-cases.
LoganDark 13 hours ago [-]
I suppose, but then everybody else knows your IP too, which nullifies one of the benefits of IPv6.
preisschild 9 hours ago [-]
You can use either iroh directly or do it like them with dns via pkarr and use mainline DHT and ed25519 public keys that you can share via separate channels
Doesn't Iroh do that? It would be great to go back to the peer to peer days, but with security.
marshray 1 days ago [-]
So I'm supposed to set up PKI before I can open a remote console connection?
Please just make it work seamlessly with my existing SSH credentials. Like SFTP.
kaoD 16 hours ago [-]
You don't need PKI.
Nothing prevents RustDesk from implementing TLS TOFU (see e.g. Gemini Protocol), which offers the same security guarantees as SSH TOFU.
preisschild 1 days ago [-]
You could just make use of public oidc/oauth2 providers like Google/Github/Microsoft/Cloudflare Generic OIDC or heck, even your bluesky account via ATProto oauth
But yeah, you could also make use of your ed25519 ssh public key as client certificate and accept based on fingerprint like ssh
teekert 19 hours ago [-]
Tailscale also protects against login attempts.
javier2 15 hours ago [-]
managing the certificates safely is too much of a hassle. especially if i dont want to accessible on public internet.
innocent_name 1 days ago [-]
>does not support encrypted connections when self hosting
Factually incorrect. If you self host a relay/coordination server - encryption works as documented.
guiambros 21 hours ago [-]
Only if you use a relay server. Direct connections in a local network are not encrypted, and RuskDesk doesn't plan on implementing it [1].
Would be nice if they did support that, but on a LAN you can always encrypt at layer 3 with WireGuard.
trueno 18 hours ago [-]
their reply in that issue:
"We don’t plan to implement this directly, as it is designed for test initially, we do not recommend using RustDesk with a public IP alone, that's also why direct ip access is turned off by default.
For security and privacy, we strongly advise using it in combination with a VPN—the VPN tunnel already provides end-to-end encryption, so additional encryption within RustDesk is unnecessary in that setup.
That said, we welcome community contributions!
Many users express interest or share feedback—but very few take the next step and submit a pull request.
If you’re able to help, your PR would be greatly appreciated! "
LoganDark 18 hours ago [-]
> That said, we welcome community contributions! Many users express interest or share feedback—but very few take the next step and submit a pull request. If you’re able to help, your PR would be greatly appreciated!
hate this. "we don't want this on principle... but we would accept it if you did it yourself!" just say you don't feel like it! don't act like it's a bad thing except for when somebody else does it for you, that's just dishonest.
trueno 17 hours ago [-]
yeah it's definitely confusing messaging i can't imagine being a community contributor there and saying "ok im gonna help implement this thing that they just described as not a good fit for their thing". i think being under resourced or whatever or just not having anyone on the team that would be able to pull this off is a fine thing to be forward about, but it gets confusing because they kinda frame it like it's the wrong thing to do then leave the door open for someone else to do it. if they didn't beat around the bush perhaps they'd have encryption on this already.
LoganDark 17 hours ago [-]
I prefer when projects say "we don't have the resources for this but we agree it would be nice" because then I actually feel like it would be worth the PR. but this project makes me feel like they don't want the change which means I don't want to put in the work
17 hours ago [-]
embedding-shape 12 hours ago [-]
> hate this. "we don't want this on principle... but we would accept it if you did it yourself!" just say you don't feel like it! don't act like it's a bad thing except for when somebody else does it for you, that's just dishonest.
What is there to hate here, I don't understand?
They first provide a concise overview of the current situation. Then how they personally feel about it. Finally they leave it open and end it with "If you want it badly enough, we'll accept outside contributions for it".
They're not saying that they're against the feature in principle, they're saying that they themselves don't plan to spend time implementing it, but if users really want it and contribute the feature itself, they'll be happy to maintain it once merged.
This seems like the ideal solution? What would be better here?
cge 5 hours ago [-]
They comment years after immediately closing the bug as wontfix, vaguely talk about users for expressing interest in features while not being willing to open a PR, when people in the thread had actually been asking, over a long period of time, whether they would accept a PR or were just opposed to the feature outright, and say they would welcome community contributions even though they think the feature is unnecessary. Then they immediately lock the issue and delete at least one comment.
I certainly interpreted the response as meaning that anyone actually trying to implement the feature would find the PR an exercise in frustration. It may be there were some cultural confusions about context and implication, but considering that they locked the issue, people weren't exactly encouraged to ask for clarification. And the developers have a sketchy enough reputation already from other incidents.
embedding-shape 5 hours ago [-]
> It may be there were some cultural confusions [...] And the developers have a sketchy enough reputation already from other incidents.
Yeaah, both these points kind of makes it clear that both you and the author might have previous history with the history that goes beyond the messages that were referenced, and I don't have that context at all. I have no idea what "previous incidents" you might be referring to, so with that said I'll say that everything I've previously stated only been based on the text of that particular issue, nothing else. Based on the text from the issue alone, seems they're open to have the feature proposed as a PR to them, then if they typically reject any PRs, I have no idea about.
LoganDark 5 hours ago [-]
First they say they do not want the feature: "we do not recommend using RustDesk with a public IP alone, that's also why direct ip access is turned off by default."
Then they say you should contribute it. It's mixed messaging, it seems like they're trying to hide "won't implement this" behind "this is a bad idea in general". They should just say they won't implement it and that they're open to contributions, not that it's a bad idea and that they "strongly" recommend against it, but that maybe if someone opens a PR anyway they'll consider it.
embedding-shape 5 hours ago [-]
> First they say they do not want the feature: "we do not recommend using RustDesk with a public IP alone, that's also why direct ip access is turned off by default."
Massive misunderstanding from your perspective if this is your take away. They're saying that based on the current state of the program, they don't recommend that particular approach. Nowhere in that quote of yours, does it give an indication that they don't want that feature. The only thing unambiguous from that quote, is that due to the current state of the program, they don't recommend that approach, and explains why one of the defaults is like it is.
If they didn't like the idea, or didn't want the feature, they'd say so, but they do not say that out loud, so why would you assume so?
LoganDark 5 hours ago [-]
there is another interpretation indeed, that is simply: "the Direct IP feature wasn't designed to be secure so we don't recommend using it right now, but if you contribute improvements we might accept them"
but I think it's phrased pretty stupidly, especially by pointing out to the askers that "very few" submit a pull request. that's just, shaming? "stop asking, do it yourself" which I hate just as much as hiding your real response behind recommendations.
embedding-shape 5 hours ago [-]
> but I think it's phrased pretty stupidly, especially by pointing out to the askers that "very few" submit a pull request. that's just, shaming?
That's is a statement of truth though? "Many ask, none provide, you want it, you contribute it" seems to be the vibe, which is completely understandable and also expected in FOSS. It's not hostile or shaming for the sake of shaming.
Yes, I guess you can see it as "shaming", but no I don't think it's bad. Users ask for stuff, you don't want to spend the time implement it, so you tell them to implement it themselves, and you'd accept it if they wanted it upstream to make it available for all. Isn't this the ideal scenario?
I still don't understand what you think would be better here? Saying "No, we don't want that" even if they're OK with the feature existing? Or saying "Yes, we don't need it, but we'll put aside our needs just for you" would have been better?
LoganDark 4 hours ago [-]
> That's is a statement of truth though? "Many ask, none provide, you want it, you contribute it" seems to be the vibe, which is completely understandable and also expected in FOSS. It's not hostile or shaming for the sake of shaming.
I understand a lot of projects take this attitude but that doesn't mean it's always deserved.
> Yes, I guess you can see it as "shaming", but no I don't think it's bad. Users ask for stuff, you don't want to spend the time implement it, so you tell them to implement it themselves, and you'd accept it if they wanted it upstream to make it available for all. Isn't this the ideal scenario?
I think it's upsetting here. Not "bad", not even necessarily inappropriate or disproportionate but upsetting. Not because I wanted them to do the work for me but because I would have wanted to feel actually welcome to do the work myself instead of made to feel like it would be a further annoyance.
This kind of attitude from the project genuinely makes it feel like if I opened a PR, it would sit and rot just like the many issues have. It does not make me feel like they are actually interested in the problem or empathize with their users whatsoever, so what motivation would they have to accept the work even if it was done for them?
> I still don't understand what you think would be better here? Saying "No, we don't want that" even if they're OK with the feature existing? Or saying "Yes, we don't need it, but we'll put aside our needs just for you" would have been better?
Did you not see the example I already posted elsewhere in the thread? Here it is again: I prefer when projects say "we don't have the resources for this but we agree it would be nice"
Here, they aren't agreeing with it whatsoever, they just say they don't have it and that they don't recommend using the related features and that they won't consider it without a pull request. That's basically "we don't have this, won't build this and won't consider user requests" and it has absolutely nothing positive for the people who would build such a PR.
As much as they technically don't need such things because they're perfectly clear and if you don't like it you can suck it up or fork or quit computing to go live on a farm, do you not see how their response could have been better? They could be encouraging people to submit PRs but instead they're shaming people for not doing it. That response would only be deserved towards people who genuinely have expressed that they want it for free, but nobody has expressed this and yet they are still taking this attitude. It's disappointing and does not foster a culture of genuine contribution, just a culture of "stop being entitled"
embedding-shape 2 hours ago [-]
> Here, they aren't agreeing with it whatsoever
Yeah, that's the core difference in our readings I think, the mere fact that they say openly they welcome someone contributing the feature, does mean they agree with it, why offer to accept such a contribution otherwise? Are they lying/not being honest, and the PR would just sit there without being accepted.
It's clear you think so, and it does feel like you have past experience with the project so I guess that is what it is. I don't have your past experience, so I don't know, but hits me as strange to ask for contributions for a feature you don't actually want, I don't understand why'd they do that.
> They could be encouraging people to submit PRs
The text I read, gave me the impression they are encouraging people to submit PRs, but maybe there is something between the lines I'm missed when I read it.
wooben 1 days ago [-]
Your statement is not entirely accurate. This only applies when using Direct IP Access on local networks, which is off by default. Their justification and invitation to PRs is the final comment [1] on the issue you linked. Why are you leaving this information out of your comment?
It may only apply to Direct IP Access, but isn't that what many would expect (not trusting middleman to be secure?)
innocent_name 1 days ago [-]
Have you tried reading the docs?
>RustDesk is a single open-source application (AGPL) with its own architecture. Clients connect outward to an ID/rendezvous server, which brokers a peer-to-peer or relayed session. Per the RustDesk documentation, traffic is end-to-end encrypted (built on NaCl)
SubiculumCode 1 days ago [-]
Not yet...good to chastise me on this, but in my defense, I am at work, and am just trying to get a sense of this, as I would like to move away from VNC.
preisschild 1 days ago [-]
I still think its an essential feature for self-hosting, but they seem to be open to PRs so what is the problem?
nextaccountic 1 days ago [-]
[dead]
throwaway27448 1 days ago [-]
What is rustdesk and how is it distinct from vnc?
Edit: i appreciate the explanations; thank you.
pizza234 1 days ago [-]
VNC and RustDesk are both remote desktop solutions, however, Rustdesk is considerably more performant than the VNC family, because the latter primarily sends framebuffer updates, while the former can use modern video codecs and temporal compression to encode screen changes much more efficiently.
shock 1 days ago [-]
> Rustdesk is considerably more performant than the VNC family
It consumes, on the client, 800%-1200% CPU AND 8%-10% GPU decode on my NVIDIA card. I opened a bug and they transformed it into a discussion, without any response.
LoganDark 3 hours ago [-]
Performant does not mean it uses less resources, it means it makes better use of the resources
anakaine 6 minutes ago [-]
Better is subjective. What is the bottleneck or resource allocation you're trying to overcome?
Going on what the poster above says about CPU and memory - if the network speed or bandwidth allocation is the bottleneck, then trading CPU and memory utilisation increases for lower bandwidth is likely acceptable. If, however, the device is low end and tying up memory and CPU with compression would lead to sluggish or impaired task performance but the network has adequate overhead for lower levels of compression or higher levels of data transfer then higher network utilisation would be preferable.
Different tools, different use case scenarios.
embedding-shape 12 hours ago [-]
> they transformed it into a discussion, without any response
How dare they.
diego_moita 1 days ago [-]
I just have one word for you: TightVNC.
That's what made me uninstall RustDesk.
pizza234 1 days ago [-]
I have three words for you: read the docs.
If you're experiencing a bug that pegs you're CPU, fair enough. But RustDesk is video-stream based (in many formats), while TightVNC is image(-region) based. This is actually similar to why you watch movies in, say, H.264 rather than Motion JPEG¹.
¹=similar, not same.
diego_moita 9 hours ago [-]
> I have three words for you: read the docs.
No, thanks.
As they say: "the proof of the pudding is in the eating". So I used both applications and TightVNC is just a lot better, particularly in constrained remote VMs.
Docs are cheap, performance is what matters.
5 hours ago [-]
embedding-shape 5 hours ago [-]
> Docs are cheap, performance is what matters.
How do you know if the performance you get is the expected, unless you read the docs or at least look at what others get on similar platforms/environments/specs?
> TigerVNC was originally based on the (never-released) VNC 4 branch of TightVNC.
It seems to be popular, that’s why I’m asking.
diego_moita 9 hours ago [-]
Thanks, I never tried it. Will try.
Funny thing is that the document where they'd explain their reasoning to fork TightVNC returns 404.
vablings 1 days ago [-]
Well first there was TeamViewer which was VNC with more bells and whistles then it became enshittified. Then anydesk came along and ate up teamviewer then that became enshittified, Now we have rustdesk which seems to hopefully be a bit more immune to being enshittified.
If you already use VNC this is not something for you
mschild 1 days ago [-]
RustDesk is also open source including the server so you can fully self-host.
pyramidless_cle 1 days ago [-]
That's not really true for quite some time now. Both client and the free server depend on a separate submodule that has no LICENSE file whatsoever. Because of that RustDesk is stuck in a limbo somewhere between open source, source-available and closed source. Also, the whole management of the project seems questionable. Also for some features a dll blob which is not open source is required with no source disclosed at all.
I like that their server is just a single Go binary, but then they go and ruin that with a Node.js web UI and.. PostgreSQL?! Seems like complete overkill. I wonder what gripping limitations they faced with SQLite that they decided it needed PostgreSQL.
opello 19 hours ago [-]
It looks like PostgreSQL is optional and SQLite is the default.
SQLite is still the default backend. Postgres is optional.
pyramidless_cle 12 hours ago [-]
Seems like that is just a server implementation that requires you to use stock RustDesk clients. So you can't really have a fully opensource RustDesk-like system without requiring a substantial chunk of unlicensed source code as well as a closed source dll blob(s).
I just glanced over the repo, deployment and comments around it and it seems like unconstrained AI slop or at least the project seems to be led by a person which can't use AI effectively for the purpose of software engineering.
topspin 1 days ago [-]
I've noticed that RealVNC has hidden their formerly free VNC desktop client, now called RealVNC Classic Viewer, behind an enterprise subscription login, and replaced it with a different cloud first thing, RealVNC Connect Viewer, that requires a login to at least obtain, and is anemic in terms of features.
Not that RealVNC is VNC. However, enshittification has clearly taken another scalp.
rcxdude 1 days ago [-]
VNC is one way of doing remote GUI access (well, more a family of different protocols and products with different capabilities and tradeoffs). RustDesk is just another product that does the same thing but doesn't have a specific connection to VNC as a protocol so e.g. doesn't have to handle legacy authentication modes and stream formats. In my experience most remote access solutions beat VNC for performance, for example.
OsrsNeedsf2P 1 days ago [-]
Rustdesk is amazing. I was using it just 2 days ago and ran into this hiccup, so it's a pleasure to see it resolved
boardwaalk 1 days ago [-]
Is there a reason to use this over something like Sunshine/Moonlight?
himata4113 1 days ago [-]
rustdesk just works, moonlight and sunshine is janky as hell outside the local network due to the fact it uses like 5 different streams.
noahbp 8 hours ago [-]
From personal experience, Moonlight is pretty slow and high latency. Even Microsoft's RDP is better.
kelvie 6 hours ago [-]
I don't understand how this can be, you can play competitive games over moonlight/sunshine, and I really don't recall being able to come close to that latency on RDP (though I haven't tried in about a decade)
SubiculumCode 1 days ago [-]
I had a heck of a time ever getting that to work. Also, can that support multiple concurrent users?
pineapplepizza6 24 hours ago [-]
[dead]
aborsy 1 days ago [-]
I have used Remmina over SSH and Tailscale (and generally don’t trust remote desktop tools), which is mentioned in various places by my operating system provider.
How does RustDesk compare with that?
fsh 1 days ago [-]
It's not VNC-based, so the performance is much better. It also supports multiple monitors.
aborsy 1 days ago [-]
Thanks!
GNOME Remote Login runs an RDP server, and RDP indeed isn’t fast enough, although is TLS-encrypted.
SubiculumCode 20 hours ago [-]
Isnt the issue with the latter is tha tyou need a local session first before you can connect?
manav 1 days ago [-]
Does my screen have to be on?
NoboruWataya 1 days ago [-]
I have a Raspberry Pi hooked up to my TV and whenever I need to control it from my laptop (getting and interacting with the same screen on my laptop that I see on my TV) I have been using VNC. It is quite slow. Would this work better for that use case or is it really intended for something different? (And if the latter are there better solutions than VNC for what I want to do?)
c-hendricks 1 days ago [-]
Yes this will give you similar results.
There's VNC and VNC-likes (rdp, steam link, rustdesk, etc) which all do similar: stream a screen, allow remote keyboard/mouse, maybe redirect sound, maybe use video encoders.
There's also things like deskflow, which allow you to use one keyboard/mouse and control with multiple machines.
NoboruWataya 1 days ago [-]
Thanks! I will check it out then.
Kavelach 1 days ago [-]
If you can look at your TV instead of your laptop, I highly recommend using KDE Connect
andai 1 days ago [-]
Menu css looks a bit dodgy with the notification at the top:
Does it framebuffer grab the current session and inject input events?
jchw 1 days ago [-]
Usually the way to be able to even get the login screen is to use DRM/KMS based capture and use uinput for device emulation. It doesn't strictly need root but it does need privileges a user wouldn't have, like access to the DRM card nodes and uinput device. Sunshine does it this way.
It entirely sidesteps the problem of X vs Wayland, although this does mean the unattended physical seat can be physically taken over while you are remote.
codedokode 1 days ago [-]
As I remember, generic DRM interface allows only writing to a framebuffer and not reading from someone's else framebuffer. Do they use some vendor-specific APIs?
jchw 13 hours ago [-]
Not that I'm aware of. I'm on my phone right now but any KMS driver that supports KMS and dma-bufs should work.
The basic idea is to enumerate the CRTCs to get the relevant framebuffer plane resources and then use dma-buf exports to pass them to an encoder. Reality can be a bit more complex due to the existence of overlay planes but that's the idea.
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.
bilkow 1 days ago [-]
> 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.
> assuming you can test an average of 1 password per μs (you probably can't, as passwords are usually stored using key derivation functions
You are not (usually) in control of what services use to encrypt your password, and most software in the world uses a basic hash like MD5 or SHA-256 rather than a key derivation function, meaning you are wildly, wildly underestimating the number of guesses per second here. To suggest that passwords are "usually" stored like that is just wildly incorrect. Only well-educated, high-quality engineers who care about security, a vanishingly tiny portion of the industry, even think about things like this. I still run into government services that e-mail me my password in plaintext.
---
Sorry, but edit attaching a reply to another comment here because HN rate-limits me:
> This is just completely false.
My mid-tier laptop GPU can crack the usual wordlist in under 12 hours against MD5 (46 billion guesses per second), or about 3 days against SHA-256 (6.5 billion guesses per second). A desktop 4090 would likely crack SHA-256 in under a day (on average).
I make claims with confidence because I am speaking about facts. Why are you making claims with confidence when you have no idea what you're talking about? The quality of discourse on this site is so, so low.
wavemode 1 days ago [-]
What you said:
> A modern consumer GPU can crack "four random English words" in a day
What you're saying now:
> My mid-tier laptop GPU can crack the usual wordlist in under 12 hours against MD5 (46 billion guesses per second)
So your response to the plain mathematical fact that, no, your consumer GPU cannot crack "four random English words" in a day, is that your consumer GPU can crack four words chosen from a list of a few thousand, in a day. Followed by personal attacks. Okay.
BenjiWiebe 24 hours ago [-]
Well, there could be quite a range of performance between a mid-tier laptop GPU (his consumer GPU), the average consumer GPU, and the average (gamer's) consumer GPU.
1 days ago [-]
drdexebtjl 1 days ago [-]
Great, then use 5 words instead.
Trying to pick a strong password assuming the service you’re signing up for doesn’t care about security is pointless. You’ll be pwned regardless of what you do.
mr_mitm 1 days ago [-]
> most software in the world uses a basic hash like MD5 or SHA-256 rather than a key derivation function
For passwords? Where do you get that information?
applfanboysbgon 1 days ago [-]
Experience? Looking at codebases? The one in question does, in fact, use SHA-256. HN is a bit of a bubble because there's a large demographic of FAANG-tier employees here who work at big tech or unicorn startups, but most software in the world is not made by FAANG or unicorn startups, and the standards are way, way lower than you might think they are if you're used to living in this bubble. For software development practices in general, not just password storage. I think it's taken for granted that every single person on HN uses VCS, but even that is a luxury in many real-world working environments outside of SV.
Even if only 10% of the services you use use MD5/SHA-256 (although I certainly would expect it to be >50% if we could do a large-scale study), why accept your password being easily compromised 10% of the time?
pbhjpbhj 12 hours ago [-]
>why accept your password being easily compromised 10% of the time?
Those services using md5 aren't doing important things, I hope, so the password for that service hardly matters.
If it does matter, then user long passwords/phrases and rotate every time (or find a better supplier).
tredre3 1 days ago [-]
> 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.
applfanboysbgon 1 days ago [-]
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.
strbean 1 days ago [-]
Seems like the only real issue here is that rustdesk uses SHA256 instead of argon2.
tialaramex 1 days ago [-]
> 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.
minitech 1 days ago [-]
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…
> A modern consumer GPU can crack "four random English words" in a day.
This is just completely false.
Fidelix 1 days ago [-]
Did you even check what hash they are using?
applfanboysbgon 1 days ago [-]
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.
XorNot 1 days ago [-]
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.
LoganDark 18 hours ago [-]
> 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.
throwaway27448 1 days ago [-]
> 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.
applfanboysbgon 1 days ago [-]
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.
throwaway27448 1 days ago [-]
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.
applfanboysbgon 1 days ago [-]
> 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.
strbean 1 days ago [-]
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)...
throwaway27448 1 days ago [-]
This is a non-issue with a password manager
XorNot 1 days ago [-]
"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.
throwaway27448 1 days ago [-]
> And yet the issue in question is about someone who refuses to adapt it.
Does this person exist?
pineapplepizza6 24 hours ago [-]
[dead]
SXX 1 days ago [-]
Btw does RustDesk support microphone input passthrough from client to the host yet?
So far it's only feature I found missing compared to proprietary solutions.
j_aime 23 hours ago [-]
Unfortunately, no, it's not working. I use Rustdesk all the time. I've found a way, but it's really stupid. I have a GL.iNet Comet to manage my headless machine. That unit supports microphone passthrough. I send my mac's mic through that to ubuntu. It's an awful solution hah, but it works. I'm able to use dictation through that on Ubuntu. I didn't buy the comet specifically for mic use. I found out after the fact that it was able to do it.
GlacierFox 1 days ago [-]
Does this work without a screen on the remote machine? I have a server with SSH access if like to view for bespoke tasks now and then.
j_aime 23 hours ago [-]
I've been using rustdesk for years. I love it.
ranger_danger 8 hours ago [-]
The problem I have with RustDesk is that self-hosting the server forces you to accept zero authentication (meaning anyone can use it to host streams for free), so you end up having to run it through a VPN which also decreases performance and latency, and makes it unusable as an easy IT help tool like people have been doing with VNC since forever (unless you relegate to using the slower public server controlled by who knows what).
And since the paid pro version does have authentication, I think it's unlikely to ever show up in the free version.
aspbee555 1 days ago [-]
RustDesk works so much better and easier than vnc and other vendored solutions. No need to open ports, no need for vpn, it just works, no account BS, no vendor lock in BS.
I have used RustDesk for years, also run my own lookup/relay server so I do not need to rely on the public lookup server
While everything else gets enshitified RustDesk just keeps getting better
SubiculumCode 1 days ago [-]
Without self-hosting, how can I be sure that the middleman server layer won't affect my security?
wartywhoa23 1 days ago [-]
Definitely a lifesaver for tech support!
And the fact it's self-hosted is priceless.
zuzululu 1 days ago [-]
wonder if it can support gaming and sounds too ?
akaykhan 9 hours ago [-]
[flagged]
superkuh 21 hours ago [-]
This depends on libdrmtap "A (LLM AI coded) zero-dependency C library for DRM/KMS framebuffer capture on Linux" https://github.com/fxd0h/libdrmtap which doesn't actually seem to give remote access so much as remote access to the screen visuals. The other hard parts of remote access on the various waylands are still left up to more proprietary, per wayland compositor, custom extensions not in wayland core or exposed by the kernel. That is, not universal.
husky8 22 hours ago [-]
Kvm companies shutter
7bit 1 days ago [-]
Okay. The feature I'm waiting for is the self-hosted web client.
maxlin 15 hours ago [-]
Rustdesk has been a nice alternative/replacement for Anydesk, I use both 10+ times a day. Was having issues getting any remote desktop working yesterday with my Orange Pi 5, so good to see this very issue being solved. It does sound like Wayland has some design issues in how difficult this has been though. If a piece of software needs to do this, it shouldn't be so obnoxiously difficult, as I've heard this is a major PITA with OBS too.
12 hours ago [-]
Kelteseth 1 days ago [-]
Funny that the video in the blog post still needs X. I will see myself out....
Fidelix 1 days ago [-]
No need to announce
pudgywalsh 1 days ago [-]
They've been working on Wayland for what, nearly 20 years now, and it still has not reached feature parity with 1996 Windows NT?
cryo32 1 days ago [-]
To be completely fair it's 2007 Windows NT they haven't caught up with.
magicalhippo 24 hours ago [-]
Windows NT4 (1998) had officially support for Terminal Services, so RDP[1].
That's kinda the point though, no? Wayland creators threw out the baby with the bath water, and thus it's taken ages to get fairly basic functionality, like what RustDesk announced here, working on the Linux Desktop.
cryo32 15 hours ago [-]
Yes that. Also it's quite a mess, which makes stuff like this much harder than it should be.
I'm still using X11 on my Linux box and am quite happy with it.
pineapplepizza6 24 hours ago [-]
[dead]
senectus1 20 hours ago [-]
oooh any chance it can be integrated into guacamole?
zuzululu 1 days ago [-]
so this means I can be on a vacation, turn on my ubuntu desktop remotely, login and control it ? I have a strong need for this as my desktop is also a server
amelius 1 days ago [-]
You can already do this with VNC or Xpra (the latter is a screen/tmux for graphical applications).
zuzululu 1 days ago [-]
so whats the edge that rustdesk that offers ? gaming ?
yjftsjthsd-h 1 days ago [-]
Performance, at any rate. VNC is fine but can be laggy.
Fnoord 20 hours ago [-]
I ran Wayland over Waypipe over WireGuard (Tailscale, in my example), and it worked very well. That over a 1 gbit fiber... shared with whole building/office. In fact, I ran remote AOSP this way.
Now, VNC might actually also work very well over WireGuard or SDN based on WireGuard. Since VNC was designed for LAN, in a time where LAN was the common use case.
For me, low latency is from the past. I always got either wired, Wi-Fi, LTE, or Starlink.
amelius 14 hours ago [-]
VNC works fine.
VorpalWay 1 days ago [-]
For a remote Linux system you can also do a lot over plain SSH as well.
shevy-java 1 days ago [-]
Is Wayland finally feature complete to xorg or are they still refusing to?
ChocolateGod 13 hours ago [-]
Wayland does not implement a print server or drawing API no.
Not true at all. RustDesk connections are fully encrypted even when using a self-hosted server. What is not supported are encrypted direct endpoint-to-endpoint connections not going through a server at all, because that's not a use case RustDesk is designed for. The feature is intended for testing, which is why it's disabled altogether by default.
If your use case is focused on direct connections without a server, RustDesk is the wrong tool for the job. It's an open-source self-hostable analog to Teamviewer, the server is inherent to the design.
Client -- Relay Server -- Host
That's certainly less than ideal since many remote desktop session will not be using a middle-age server but rather be direct between client and host.
VNC does not, for example, and you need to set up port forwarding through ssh. X2Go does....but I don't trust it terribly. So, RustDesk..what do you need to wrap it in? ssh?
I really want a better solution that VNC/X2Go..especially since I use hardware accelerated apps that need to use VGL to operate correctly (but underwhich operation is quite buggy).
Another valid alternative is Xpra, and it does support Wayland too - but doesn't reach feature parity with X11. Like RustDesk, Xpra is similarly feature-rich and mature, it too can take advantage of SSH tunnels, SOCKS or HTTPS proxies etc.
And then there's TeamViewer and AnyDesk - both of which are paid, with a free tier for evaluating or personal use - RustDesk is younger, but feature-wise they're quite similar.
Finally, you could set up wireguard that will happily encrypt your connection with very little overhead - regardless of your chosen remote desktop solution.
I think such setups are at least as secure as having tailscale in front of it and they are web standards conform. I dont need a client app like tailscale, I can just use my normal browser and internet conn.
I always make sure envoy/all other apps are on the latest security patcb anyways.
I probably won't allow everything through it (eg: postgres, clickhouse etc can stay on tailscale), but I've been stumbling into use cases where I want to share things with friends or colleagues, and I don't want to put them on my tailnet.
What all user-facing software should have is a minimal-overhead connection option to improve performance inside user's tunnel of choice.
Pure QUIC gets blocked easily, SSH requires wrapping, even Tailscale mimicry is basic and they still ignore simple protocol improvements available.
https://app.pkarr.org/
https://www.iroh.computer/blog/v1
basically an embedded tailscale.
Please just make it work seamlessly with my existing SSH credentials. Like SFTP.
Nothing prevents RustDesk from implementing TLS TOFU (see e.g. Gemini Protocol), which offers the same security guarantees as SSH TOFU.
But yeah, you could also make use of your ed25519 ssh public key as client certificate and accept based on fingerprint like ssh
Factually incorrect. If you self host a relay/coordination server - encryption works as documented.
[1] https://github.com/rustdesk/rustdesk/issues/3714#issuecommen...
"We don’t plan to implement this directly, as it is designed for test initially, we do not recommend using RustDesk with a public IP alone, that's also why direct ip access is turned off by default.
For security and privacy, we strongly advise using it in combination with a VPN—the VPN tunnel already provides end-to-end encryption, so additional encryption within RustDesk is unnecessary in that setup.
That said, we welcome community contributions! Many users express interest or share feedback—but very few take the next step and submit a pull request. If you’re able to help, your PR would be greatly appreciated! "
hate this. "we don't want this on principle... but we would accept it if you did it yourself!" just say you don't feel like it! don't act like it's a bad thing except for when somebody else does it for you, that's just dishonest.
What is there to hate here, I don't understand?
They first provide a concise overview of the current situation. Then how they personally feel about it. Finally they leave it open and end it with "If you want it badly enough, we'll accept outside contributions for it".
They're not saying that they're against the feature in principle, they're saying that they themselves don't plan to spend time implementing it, but if users really want it and contribute the feature itself, they'll be happy to maintain it once merged.
This seems like the ideal solution? What would be better here?
I certainly interpreted the response as meaning that anyone actually trying to implement the feature would find the PR an exercise in frustration. It may be there were some cultural confusions about context and implication, but considering that they locked the issue, people weren't exactly encouraged to ask for clarification. And the developers have a sketchy enough reputation already from other incidents.
Yeaah, both these points kind of makes it clear that both you and the author might have previous history with the history that goes beyond the messages that were referenced, and I don't have that context at all. I have no idea what "previous incidents" you might be referring to, so with that said I'll say that everything I've previously stated only been based on the text of that particular issue, nothing else. Based on the text from the issue alone, seems they're open to have the feature proposed as a PR to them, then if they typically reject any PRs, I have no idea about.
Then they say you should contribute it. It's mixed messaging, it seems like they're trying to hide "won't implement this" behind "this is a bad idea in general". They should just say they won't implement it and that they're open to contributions, not that it's a bad idea and that they "strongly" recommend against it, but that maybe if someone opens a PR anyway they'll consider it.
Massive misunderstanding from your perspective if this is your take away. They're saying that based on the current state of the program, they don't recommend that particular approach. Nowhere in that quote of yours, does it give an indication that they don't want that feature. The only thing unambiguous from that quote, is that due to the current state of the program, they don't recommend that approach, and explains why one of the defaults is like it is.
If they didn't like the idea, or didn't want the feature, they'd say so, but they do not say that out loud, so why would you assume so?
but I think it's phrased pretty stupidly, especially by pointing out to the askers that "very few" submit a pull request. that's just, shaming? "stop asking, do it yourself" which I hate just as much as hiding your real response behind recommendations.
That's is a statement of truth though? "Many ask, none provide, you want it, you contribute it" seems to be the vibe, which is completely understandable and also expected in FOSS. It's not hostile or shaming for the sake of shaming.
Yes, I guess you can see it as "shaming", but no I don't think it's bad. Users ask for stuff, you don't want to spend the time implement it, so you tell them to implement it themselves, and you'd accept it if they wanted it upstream to make it available for all. Isn't this the ideal scenario?
I still don't understand what you think would be better here? Saying "No, we don't want that" even if they're OK with the feature existing? Or saying "Yes, we don't need it, but we'll put aside our needs just for you" would have been better?
I understand a lot of projects take this attitude but that doesn't mean it's always deserved.
> Yes, I guess you can see it as "shaming", but no I don't think it's bad. Users ask for stuff, you don't want to spend the time implement it, so you tell them to implement it themselves, and you'd accept it if they wanted it upstream to make it available for all. Isn't this the ideal scenario?
I think it's upsetting here. Not "bad", not even necessarily inappropriate or disproportionate but upsetting. Not because I wanted them to do the work for me but because I would have wanted to feel actually welcome to do the work myself instead of made to feel like it would be a further annoyance.
This kind of attitude from the project genuinely makes it feel like if I opened a PR, it would sit and rot just like the many issues have. It does not make me feel like they are actually interested in the problem or empathize with their users whatsoever, so what motivation would they have to accept the work even if it was done for them?
> I still don't understand what you think would be better here? Saying "No, we don't want that" even if they're OK with the feature existing? Or saying "Yes, we don't need it, but we'll put aside our needs just for you" would have been better?
Did you not see the example I already posted elsewhere in the thread? Here it is again: I prefer when projects say "we don't have the resources for this but we agree it would be nice"
Here, they aren't agreeing with it whatsoever, they just say they don't have it and that they don't recommend using the related features and that they won't consider it without a pull request. That's basically "we don't have this, won't build this and won't consider user requests" and it has absolutely nothing positive for the people who would build such a PR.
As much as they technically don't need such things because they're perfectly clear and if you don't like it you can suck it up or fork or quit computing to go live on a farm, do you not see how their response could have been better? They could be encouraging people to submit PRs but instead they're shaming people for not doing it. That response would only be deserved towards people who genuinely have expressed that they want it for free, but nobody has expressed this and yet they are still taking this attitude. It's disappointing and does not foster a culture of genuine contribution, just a culture of "stop being entitled"
Yeah, that's the core difference in our readings I think, the mere fact that they say openly they welcome someone contributing the feature, does mean they agree with it, why offer to accept such a contribution otherwise? Are they lying/not being honest, and the PR would just sit there without being accepted.
It's clear you think so, and it does feel like you have past experience with the project so I guess that is what it is. I don't have your past experience, so I don't know, but hits me as strange to ask for contributions for a feature you don't actually want, I don't understand why'd they do that.
> They could be encouraging people to submit PRs
The text I read, gave me the impression they are encouraging people to submit PRs, but maybe there is something between the lines I'm missed when I read it.
1 - https://github.com/rustdesk/rustdesk/issues/3714#issuecommen...
>RustDesk is a single open-source application (AGPL) with its own architecture. Clients connect outward to an ID/rendezvous server, which brokers a peer-to-peer or relayed session. Per the RustDesk documentation, traffic is end-to-end encrypted (built on NaCl)
Edit: i appreciate the explanations; thank you.
It consumes, on the client, 800%-1200% CPU AND 8%-10% GPU decode on my NVIDIA card. I opened a bug and they transformed it into a discussion, without any response.
Going on what the poster above says about CPU and memory - if the network speed or bandwidth allocation is the bottleneck, then trading CPU and memory utilisation increases for lower bandwidth is likely acceptable. If, however, the device is low end and tying up memory and CPU with compression would lead to sluggish or impaired task performance but the network has adequate overhead for lower levels of compression or higher levels of data transfer then higher network utilisation would be preferable.
Different tools, different use case scenarios.
How dare they.
That's what made me uninstall RustDesk.
If you're experiencing a bug that pegs you're CPU, fair enough. But RustDesk is video-stream based (in many formats), while TightVNC is image(-region) based. This is actually similar to why you watch movies in, say, H.264 rather than Motion JPEG¹.
¹=similar, not same.
No, thanks.
As they say: "the proof of the pudding is in the eating". So I used both applications and TightVNC is just a lot better, particularly in constrained remote VMs.
Docs are cheap, performance is what matters.
How do you know if the performance you get is the expected, unless you read the docs or at least look at what others get on similar platforms/environments/specs?
https://tigervnc.org/
> TigerVNC was originally based on the (never-released) VNC 4 branch of TightVNC.
It seems to be popular, that’s why I’m asking.
Funny thing is that the document where they'd explain their reasoning to fork TightVNC returns 404.
If you already use VNC this is not something for you
https://github.com/UNITRONIX/BetterDesk#prerequisites
I just glanced over the repo, deployment and comments around it and it seems like unconstrained AI slop or at least the project seems to be led by a person which can't use AI effectively for the purpose of software engineering.
Not that RealVNC is VNC. However, enshittification has clearly taken another scalp.
How does RustDesk compare with that?
GNOME Remote Login runs an RDP server, and RDP indeed isn’t fast enough, although is TLS-encrypted.
There's VNC and VNC-likes (rdp, steam link, rustdesk, etc) which all do similar: stream a screen, allow remote keyboard/mouse, maybe redirect sound, maybe use video encoders.
There's also things like deskflow, which allow you to use one keyboard/mouse and control with multiple machines.
https://files.catbox.moe/d5ztxi.jpg
Does it framebuffer grab the current session and inject input events?
It entirely sidesteps the problem of X vs Wayland, although this does mean the unattended physical seat can be physically taken over while you are remote.
The basic idea is to enumerate the CRTCs to get the relevant framebuffer plane resources and then use dma-buf exports to pass them to an encoder. Reality can be a bit more complex due to the existence of overlay planes but that's the idea.
https://github.com/LizardByte/Sunshine/blob/master/src/platf...
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.
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...
You are not (usually) in control of what services use to encrypt your password, and most software in the world uses a basic hash like MD5 or SHA-256 rather than a key derivation function, meaning you are wildly, wildly underestimating the number of guesses per second here. To suggest that passwords are "usually" stored like that is just wildly incorrect. Only well-educated, high-quality engineers who care about security, a vanishingly tiny portion of the industry, even think about things like this. I still run into government services that e-mail me my password in plaintext.
---
Sorry, but edit attaching a reply to another comment here because HN rate-limits me:
> This is just completely false.
My mid-tier laptop GPU can crack the usual wordlist in under 12 hours against MD5 (46 billion guesses per second), or about 3 days against SHA-256 (6.5 billion guesses per second). A desktop 4090 would likely crack SHA-256 in under a day (on average).
I make claims with confidence because I am speaking about facts. Why are you making claims with confidence when you have no idea what you're talking about? The quality of discourse on this site is so, so low.
> A modern consumer GPU can crack "four random English words" in a day
What you're saying now:
> My mid-tier laptop GPU can crack the usual wordlist in under 12 hours against MD5 (46 billion guesses per second)
So your response to the plain mathematical fact that, no, your consumer GPU cannot crack "four random English words" in a day, is that your consumer GPU can crack four words chosen from a list of a few thousand, in a day. Followed by personal attacks. Okay.
Trying to pick a strong password assuming the service you’re signing up for doesn’t care about security is pointless. You’ll be pwned regardless of what you do.
For passwords? Where do you get that information?
Even if only 10% of the services you use use MD5/SHA-256 (although I certainly would expect it to be >50% if we could do a large-scale study), why accept your password being easily compromised 10% of the time?
Those services using md5 aren't doing important things, I hope, so the password for that service hardly matters.
If it does matter, then user long passwords/phrases and rotate every time (or find a better supplier).
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.
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 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...
This is just completely false.
Plenty of sentence passwords meet that but now the probability space has exploded.
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.
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.
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.
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.
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.
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)...
That phrase will pass almost every single password requirement, and no one is going to crack it by brute force dictionary attack.
Does this person exist?
So far it's only feature I found missing compared to proprietary solutions.
And since the paid pro version does have authentication, I think it's unlikely to ever show up in the free version.
I have used RustDesk for years, also run my own lookup/relay server so I do not need to rely on the public lookup server
While everything else gets enshitified RustDesk just keeps getting better
And the fact it's self-hosted is priceless.
[1]: https://en.wikipedia.org/wiki/Remote_Desktop_Protocol
I'm still using X11 on my Linux box and am quite happy with it.
Now, VNC might actually also work very well over WireGuard or SDN based on WireGuard. Since VNC was designed for LAN, in a time where LAN was the common use case.
For me, low latency is from the past. I always got either wired, Wi-Fi, LTE, or Starlink.