New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Comments
If I remember correctly, Virtualizor redacts root passwords from logs. Storing the password is opt-in feature configurable in Master Settings (which means that provider have to enable it).
Only place that virtualizor for some reason stores the password in, is WHMCS Password field of the service. But this field is encrypted.
Not sure why their module updates the password there when user changes it on the dashboard (but only from the one included in WHMCS). Password field itself is required for provisioning.
As a rule of thumb, you should always change the root password. Even Vultr stores the root password that the server was launched with.
I've never heard of a compromise over it specifically, but no reason to expect it couldn't happen.
I've seen in previous leaks that the Virtualizor DB contains the email log that gets sent to the customer, which includes the root password.
Have you considered changing the root password immediately after provisioning each VPS? The initial password supplied is what's usually stored by the control panel for reset purposes. Once you change it, the stored value becomes obsolete for actual server access. It's still poor practice for them to store it plaintext, but this mitigates your direct risk significantly.
Have you considered changing the root password immediately after provisioning each VPS? The initial password supplied is what's usually stored by the control panel for reset purposes. Once you change it, the stored value becomes obsolete for actual server access. It's still poor practice for them to store it plaintext, but this mitigates your direct risk significantly.
Well most billing systems such as WHMCS store them in database encrypted, you can't decrypt the password without configuration cc_ hash, but it will be visible in the frontend in the password field. This is why most on delivery leave a remark in the email, a reminder to change your root key.
Some like it for comfort, while others simply just change the root key once in the box to secure it, however you will always receive email with your password on delivery unless you specifically (when available) enter an SSH into a box and the delivery detects if that box is filled, send no pass.
With that said, its kind of standard, I have had VPS with several providers and Dedicated servers, and you always get an YOUR SERVER IS READY with all the information. I've had 2 of them where I am to set the password myself, it handles the cloud-init but I can't confirm if what I enter is being stored or not ;D..
RULE is SIMPLE
Just always step 1, 2FA your account step 2, ensure to change your root key on delivery, when you change your root in your box, you know its definitely safe.
Wait, there are people who do not change the root password once the server is deployed? Seriously?
Am I misunderstanding something here or do people really mean that there are vps's out there still running with the root password that was delivered in a plain text email from the provider or even worse, shown as plain text in the panel?
Hi,
we have every week customers who have trouble to login.
We DO write into the accessmail that all servers are delivered with key auth enabled only.
We DO write that they can download the private key from the clientarea.
In the clientarea you have a button right at the first page, next to the start/stop buttons with "redeem password".
The result:
We are explaining every week why we do NOT work with password. And we explain why we do NOT help the customer to sabotage himself activating for him password auth. We have to explain why we expect customers who rent their own, self-managed server, to bring at least some minimal amount of know-ledge OR being at least motivated to learn it. We even created an FAQ entry about this. And we have to accept complaining customers about how rude we are that we make it hard for them and that virtually every hoster they ever worked with is much better with this.
As a result, i can understand every hoster who do not want to have this kind of support workload / drama and simply publish the root password in plaintext in the email, in youtube, on reddit, on X, facebook and of course instragram and what ever other fancy stuff is out there to make sure that everyone is happy.
So honestly i am not sure if this is a problem with hosters, adjusting to obvious customer needs or with customers obviously lacking of knowledge to administrate the self-managed servers they just rented....
For us, its fine. I take here the lesser evil and accept the workload on support side but this way filter out at least some of the customers we actually do not really want to give access to our infrastructure.
But i can understand that other providers will do it another way, because of the simple fact that a lot of customers are trained by big VPS hosters to receive their password in the news paper. At least the cloud hyperscaler dont do that. So there is some hope for the future that future generations will expect key auth and be naturally able to handle it. Which is in fact currently simply not the case.
Many providers only care about profit and completely ignore security. While the biggest players usually don't have these issues, it's still shocking that some major companies still send passwords in plaintext via email.
Ultimately, unless you're paying for a managed service, the provider isn't responsible for your security,it’s on the user to have the necessary knowledge.
If you want to stay safe, change your password immediately, disable root access, and encrypt the disk with your own key. Most importantly, disable password login entirely and use only SSH keys while keeping the server updated.
last advice, if you can, just don't expose your SSH port to public
I don’t think I could ever have a B2C business. The amount of entitled people that exist on this planet is just too great. My respect goes out to providers, and other companies too, that do not become embittered in such an environment.
Perhaps a CLI tools will be more suitable?
1. Make portable binary for cli tools
2. Send email to client containing url to download the binary and magic-link/token
3. Client download the binary, execute it with magic-link
4. The binary generate ssh key(ed25519), create printable pdf containing qr code of the private key (mandatory to be printed &laminated). Then, asked the client to encrypt the key using password
5. Asked the client to put in the password, if successful, delete the unencrypted private key and send the public key to the server
Yes bro, client not capable of reading will go through all of that hops. Please.
😂 Then they shouldn't use unmanaged service. This is something teenagers should be able to do. Might as well offer faxed password
Virtfuuuusion has embedded SSH public key generator that works client-side (JS), I am aware of at least one case of it being used by a customer that later opened ticket asking for a help using pubkeys
Hosts should add FAQ section for 🔰. It's a great investment.
Guys, understand the fact that most will not care/understand most of these aspects.
Agreed, password should not be stored in plain text.
All that said, what to do with the average Joe? as not all are power users like most of you.
I will put aside the fact that most billing panels have limitations, that is one problem, and if not stored encrypted, that is an issue true.
Now, back to Joe.... - really nice fella
Joe is a nice fella, will open 4 tickets as he fails to understand the activation of OTP based 2FA ( scan the damn qr code and after that activate your account to log in, furthermore he will never save the backup codes ), that should be the bare minimum today, I will not even start on webauthn/fido2 or other complex password-less security logins/or other methods.
I will post here the 99.9% of the general cases from users.
He wishes to get a VPS/VDS for he's stuff.
Goes to: my-preferd-pvs-provider.com and buys one.
He's skills barely reach the level of apt install plex.
After 3 hours with an AI he manages to set it up.
end of example.
You really think that not sending him the password via mail is an option - again, not saying it is a good thing, it is not, yet, can you imagine 1000 Joes opening tickets saying:
I don't have a password, how the fuq to log in? are you idiots?
Fact that some / most of you value this makes me have hope in humanity, and I thank you for it.
For average use case, sending him temp links, ssh pre-installed keys or other more secure yet complex setups is a no go. - unfortunately.
I get the fact that in 2026 most/all should do ssh keys or more secure login setups, and I am 100% with you on that, yet reality is not that. It is still User + password aka Joe.
We have a few tutorials in the knolagebase for customers, yet almost non read them, they will just open a ticket. ( not saying they are the best, yet with no feedback they will not get any better )
If a provider chooses to go the correct way, he will cut 99.9% of its customer base.
Sending an e-mail with the login details is mandatory in my view, storing that password in the database encrypted is also mandatory, but whatever above this will be..... unpractical in my view for the 99.9%
What the customer does to protect he's/she/it system, that is up to him. But forcing him is..... well, unpractical/none-double.
Operators/hosting will adjust to whatever the majority asks eventually as they need to stay in business, yet complexity is not part of that majority, yet.
I am saying that this is not a provider only problem or lack of care.
@host_c I don't think everyone are born capable of setting up their keys. It's learned.
If the average joe are incapable of learning something new, offering emailed password seems to be the right option. But, I think there should be option to use private keys too.
Most people need a step-by-step examples, like tutorial video shot on bandicam or unregistered hypercam
Agreed.
I actually know when 30% of the 99.9% will use keys for example
, after their first vps hack. Then they will search for alternatives.
For example we have the option for ssh keys, yet the use case is very low.
I believe that in a few years this will change, as more and more people start to get more aware that a password is not enough today, even if it is 64 characters wide.
I'm going to echo what @rcy026 says here. But also with a non-sarcastic "of course they do!"
Everyone should change the password to any account as soon as they get access into the service. Especially if the service sends you a password. And the closer to the service, the better option it is to change the password (i.e. don't change your hosting password through WHMCS, change it from the control panel, or from shell.
With our hosting customers, we tell them in our welcome letter to log into their control panel and change their password. Doesn't mean they'll do it, but frees us from any jurisdiction should our systems get compromised. "They hacked into your account, because you didn't change your password you say? Well, that's on you."
As far as our services having the initial password sent to us via email, I'm fine with that. Because as soon as I get that information, I log in and change the password. Is there a period of time when that information could get compromised? Sure. But it's unlikely. If providers want to do an SSH key only, I can do that as well.
But, obviously, not everyone is competent.
You can configure the templates to allow a time-limited single login at the point the email is sent. From the user's perspective, they have X hours to SSH in, and as soon as they get in, they're provided with a prompt from PAM to enter a new password. Doing that makes the security equivalent to that of an OTP.
@host_c, I have never ever consciously (or on low consciousness) set root password when initializing server, unless the stupid panel demands it. In fact, I use
4096 RSAkey when I made my first vps purchase, which I regret becauseECDHis better.Is it not possible with whmcs?
The security of your server doesn’t really depend on whether credentials are sent or stored in plain text.
That only becomes an issue if you’re neglecting basic server security. As others have mentioned, this is a “lowendbox” scenario—some folks seem to expect the provider to be a hero who does everything, including remembering your password for you, which, let’s face it, happens a lot. That’s also why most providers keep it showing in the client area by design.
But that doesn’t mean the tools to implement best-practice security aren’t available—they’re included in almost every billing system and control panel that providers use today.
Our advice for clients concerned about this: almost every control panel and billing software today provides tools to secure your account. Of course, no system is 100% secure or flawless. However, most attacks don’t happen via the billing software itself—they mostly target your VM first or the virtualization panel. So your first steps should be: enable 2FA everywhere including your own email address that you used to signup with to that provider, use SSH keys, and implement a strong firewall strategy. After that, add to it by hardening your OS according to best practices.
Once you’ve done that, whether the provider stores passwords in plain text or not becomes largely irrelevant—your OS won’t even be using them.
So even if someone somehow obtained them, they wouldn’t be able to exploit them. Just our two cents.
ECDSA is better in almost every way, but technically speaking, RSA 4096 has marginally better resistance against cryptographically-relevant quantum computers than ECDSA (the CRQC requires 3n+1 qubits for n-bit RSA, vs 6n qubits for n-bit ECC). Not that it matters all that much, since it's used as a signature and thus isn't at risk of retroactive decryption.
Right, thank you for correcting me crypto.stackexchange moderator!
I guess I should be using 2**14 bit RSA key.
What's your take on ed25519 compared to these?
Ed25519 is definitely the best all-around, but it's still ECC so strictly speaking, it's slightly more vulnerable to a CRQC (it would take 1536 logical qubits to break Ed25519 vs 12289 logical qubits to break RSA 4096 using the 6n vs 3n + 1 estimates). But all the benefits Ed25519 has (superior side-channel resistance, faster generation, more lightweight, smaller private key and signature) make it worth it.
Looking into the current research, apparently better bounds have been found by Chevignard et al in 2025, requiring only n/2 + o(n) logical qubits. For that, the researchers estimate only 1730 logical qubits to factor a 2048-bit semiprime (I'm not an expert at all so I'm not sure how to calculate o(n) which would be needed to determine how this research would apply to a 4096-bit RSA key). According to Craig Gidney, this technique, although it requires very few logical qubits, does exclude non-negligible overheads including fault tolerance overheads, routing overheads, and magic state distillation overheads. It's possible that the 2019 estimate of 3n + 1 or the 2024 estimate of 1.5n is still more realistic.
Those researchers looked into DLP as well, but not ECDLP. The state of the art from Jaques et al showed 2124 qubits required to break a 256-bit ECC key (like Ed25519), but with a significantly lower gate count. The discovery from Chevignard et al does not apply to ECDLP since it uses integer arithmetic tools that don't exist in elliptic curve groups (RNS and Chinese remaindering). That doesn't mean there aren't possible ways to further reduce the logical qubit count for ECDLP, though. But ignoring the overheads and high gate count, this 2025 research does tip the scale in favor of 256-bit ECDLP actually being harder to solve than 2048-bit semiprime factorization. 4096-bit semiprimes would still be harder, though.
tl;dr as far as quantum computing is concerned, the state of research is in flux. If confidentiality matters, you have to use a PQC (like ML-KEM). When you're only dealing with signatures, you can pretty much ignore the thread of CRQCs until "Q-day" (the day they are finally relevant), in which case Ed25519 is better (smaller, secure against side-channel attacks, etc.).
Edit: I got curious: https://crypto.stackexchange.com/q/119423/54184
I still prefer RSA keys, generally. I'm not convinced the curves aren't compromised.
@yoursunny are you familiar with these matters?
Right
Yeah. First time purchaser usually don't expect things that come with unmanaged service and would forgot password on server with root access.
Although, it would be helpful if the host provide hardened image/cloud-init
Not all ECC has unexplained curve parameters. Curve25519 (behind x25519 and Ed25519), for example, has a safe curve: https://safecurves.cr.yp.to/
Compare Curve25519 (y^2 = x^3 + 486662x^2 + x modulo p = 2^255 - 19) with the government standard NIST P-256 (y^2 = x^3 - 3x + 41058363725152142129326129780047268409114441015993725554835256314039467401291 modulo p = 2^256 - 2^224 + 2^192 + 2^96 - 1, where that long number is the SHA-1 digest of an unexplained seed that the NSA generated). The former is not going to have a cooked curve, but the latter might (although there are reasons to believe that's infeasible). You should feel comfortable with some curves even if you aren't comfortable with all.
And even if Curve25519's parameters look strange, they're actually not random at all. It's a standard construction called a Montgomery curve in the form y^2 = x^3 + Ax^2 + x. While A = 486662 might seem random, it's actually one of only three possible values for A that hold all the necessary security properties (the other two being 358990 and 464586). Since the other two have prime factors smaller than 2^252 (which would be an issue in the unlikely situation that the secret key is identical to the prime), Bernstein, the author of the curve, went with A = 486662. And then p = 2^255 - 19 is just a prime of the appropriate size. There's a whole paper introducing the curve: https://cr.yp.to/ecdh/curve25519-20060209.pdf.
In the paper, Bernstein explains the design of Curve25519. He wanted to optimize globally for the following characteristics:
From those quite defensible constraints (all of which improve security, performance, and ease of safe optimization), the curve parameters y^2 = x^3 + 486662x^2 + x modulo p = 2^255 - 19 emerged quite naturally. This makes it quite trustworthy.
But if you want to be safe, ditch pure-RSA and go with ML-KEM. No need to stay vulnerable to quantum computers.
Not to my knowledge.
The only think I see in WHMCS is a text field for user and password.
WHMCS is, in my view, 10 years behind what the industry needs today, as a whole concept of the app.
Blesta is nice-ish, but has a munch smaller user base and echo-system.
We don't have webauth/fido2 by default in whmcs, not even for admin part. The Yubico module in WHMCS is an extremely old implementation, we tested it, no-go.
Being one of the biggest ( and oldest ) billing panels specialized for hosting, they literally suck. why??? because the app itself houses your users, passwords, provisioning modules settings, apy key's for whatever, payment gateways and so on, yet the app is a decade behind whatever you consider modern by today standards security wise. - I actually see and treat it as a security risk in my infrastructure.
On a yearly basis we passed 2000 USD with them, and that is for whmcs alone plus the other plugins we pay for. Now at that price-point I do expect a "leader" in this business to actually give something in return, at least security wise.
They just built code over code on an old logic, rather then to redo-it from 0 with modern tools. If you check their forum, you will agree with me on this, and security is not their only issue.
I would be the happiest fella to not know/see/have access to the user's password/login and so on.
The idea of others to give the fella a download link that expires in x days with the key or password for that matter is awesome, yet that is not built in in WHMCS by default, and it should be WHMCS's problem to make it so, not a 3'rd party app or custom development.
I get that there are modules, ok, yet, then I am bound to x times y companies to monitor for fuckups, data breaches, security exploits and so on.
Not all of us as operators are also coders to develop custom plugins, then to modify them on a monthly/quarterly/when needed basis with each upgrade to the panel or other.
By 2026 security should be pretty straight forward, yet it is not. We have standards but we lag implementations.
I also have a problem of scripting stuff into an already made app, why?? because then I will have to babysit that each time I have an upgrade of the app, and then what am I? a software company or a hosting company? babysitting a panel for what you pay for should not be my problem sincerely, If it is my custom setup then yes, but if it is a sold app by an established company then definitely no. - ( see the irony here? users mock providers as they have to babysit their bought services sometimes, providers babysit their software for what they pay for so they can provide to user's )
Now regardless of what others think of me, I actually value the security of the accounts of my customers, yet as others I am bound to what I get in return from my software supplier, and it is not the cheapest or shittiest on the block.
I am looking into HostBill, WISECP, ClientExec, yet I did not fall of my chair for the moment.
Each one excels in something and sucks in other parts. Yet I find HostBill the most go to for the moment.
Sorry if I routed the discussion a bit off course.