All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Multiple VPS provider storing root passwords in plain text?
houston713
Member
I have 7 different VPS providers and while looking through the backend of one of them I realized they store my root password in plain text.... I was baffled because I mean, this is like 2026 and storing a password in plain text is like 2003 levels of stupidity.
Realizing that most of the VPS providers I have except for maybe two of them use this same back end with different themes I checked on those and yup. Also storing passwords in plain text.
Am I nuts to think this is uh, nuts or is this just a fact of life with these VPS providers using this same hosting management package? I use a cert for SSH so the root password could not be used to get to a remote shell.... but if the VPS provider is ever compromised then they certainly could use it to get to a local shell.
Mind you I run a service that stores plain text passwords in a vault, but I never transmit that password to the front end, ever again. I get why you have to sometimes store plain text passwords but this feels, wrong.
Comments
What VPS control panel they use? Virtualizor or something else?
So you also have node-level root access with them?
Yeah. And half of them also email your original password to you and allow you to see your password in the panel. This is why everyone should immediately change the root password on your VPS as soon as you get it.
No, of course not. The concern is that some VPS provider gets caught up in a zero day or fails to patch a venerability before someone else gains node-level access.
Pretty much nailed it. Virtualizor... even on the website for the panel the first freaking screenshot they show that they can show the root password.
Am I taking crazy pills? Is this not just really, really bad?
If a provider sends you an email with the password (which almost every single one does), there isn't really any way around 'storing' the password in plaintext. Even if the provider doesn't "store" the default password in their database, it still exists in email logs.
We allow users to provide an SSH key. If they don't provide an SSH key, we generate a secure password on our end and email it to them. There isn't really a better option if a user doesn't provide an SSH key.
I would make a new user account with sudo privileges and disable the root account.
Easiest and best option imo
I get it for automation on the first setup the password needs to be stored and sent out. Would standard practice not be to create a temporary password that is expired on first login or require reset?
I just do not understand why is the root password being stored at all outside of the VPS.
With OVH, they send a temp password link that will expire in 7 days and require you to change the password on first login.
That is the correct way to do it. When installing an OS via a template, the provider can easily require a password change after the first login. And if the customer is installing directly via ISO, they'll have to manually set a new password anyway during setup. Sadly, most hosts do not care about security (neither do most customers).
I have ~40 and I can't think of any off the top of my head that don't let me see the (original) root password in plaintext.
I've never used Virtualizor, but their method is probably more old style.
With Virtfusion (what I use), when you install an operating system and don't select an SSH key, the root password is generated and emailed to you. The email logs Virtfusion stores automatically redacts the password from the logs so you can't see it in the logs. The passwords are stored encrypted in the database (AES-256-CBC I think via laravel encrypt function?) and requires the systems secret app key (and maybe one other thing) to decrypt. There's no way to get the password on the client or admin web UI side after the initial install. It can be retrieved via CLI commands from the master server via the local database. Of course this is void if you install using an SSH key or install your OS manually.
Does this work? Let me try it on my new VPS. Because I'm also wary root password can be reset easily from whatever panel, hopefully this will make it harder.
There are plenty of solutions to this problem. Some customers prefer receiving a non-root login, some prefer a password that expires, some prefer none of the above. The bottom line is, in the context of an unmanaged service, it's the customer's responsibility to harden their machine and choose how they want to deal with it. Any security conscious user should be using SSH keys anyway, and not relying on their provider to 'securely' delete their default credentials.
lol it’s still possible for anyone with hypervisor-level access to do whatever they want eg. boot into rescue mode. Locking the root account only adds a bit of inconvenience; it doesn’t make the system invincible.
Indeed. FDE is better, but even that's not bulletproof. However, it will still help significantly against automated exploitation, since most script kiddies are not going to attempt to directly mount each VM image.
By far the best virtualization-based solution is a TEE like AMD SEV-SNP with remote attestation, although even that can be bypassed with physical access in the right situations.
Of course, there are ways around it. That is why some prefer getting a dedicated server or colo own servers or even getting their own private cage.
That's just plain wrong (or incompetent). One could perfectly well use symmetric encryption with a fixed provider password (even staff doesn't need to know) and decrypt for emailing. Plus one could apply the same key to the password the user enters and compare it against the encrypted stored user password.
And that would be what I'd consider minimal but at least not ridiculously insecure. If a panel doesn't provide even that it should be thrown in the trash bin.
And as a security-conscious user, are you going to take your provider's word for it? Or are you just going to use an SSH key?
Passwords delivered via email are inherently insecure, no matter how you slice it. You can encrypt at rest all you want, but the moment that password hits an email, it's likely traveling through third-party services like Amazon SES, Mailgun, Postmark, etc. It's sitting in their logs, in transit, and ultimately in the user's inbox in plaintext. The provider's storage is one small link in a much longer chain that nobody fully controls. Calling a provider "incompetent" for not encrypting a password that's about to be sent in a plaintext email is missing the forest for the trees.
We don't even store the password after the initial email is sent, but it still exists in plaintext in several places, which is out of our control.
Easiest solution, change the root password on the VPS's shell. Never change a root password in the provider's dashboard. Because if you enter it there, they can intercept and store the password for themselves.
Changing the password directly on the shell, the provider is not going to know what the password is set to.
The provider may have an SSH key installed, that allows them to login and then set the root password back to what is in the dashboard. I suppose that's a possibility.
If they don't have an SSH key they can always boot the VPS in single-user mode and reset the root password that way.
But that just seems to be an extreme.
Biggest lesson - always reset your password. Whatever password a provider gives you, whether that is a dedicated server, VPS, shared hosting account, reseller account, whatever - change it. This way you know who all has the password to your account.
There comes a point where security is left to the owner of the account. If they don't want to insure security by changing their password - there's just really nothing providers can do.
And seriously people!!! Use a password manager!! I don't care what password manager you use, any will work. The provider's password reset function is not a solution to your own incompetence. Whether it's your NetFlix password, your web hosting account password, or your Whataburger account password - you ALWAYS need to have a means of recalling your current password! You don't go "Garsh! I need to log into my account, I'll use the password reset function to get a password to log into my account!" It's absolutely mind-boggling to me at how many people don't know the passwords to their own accounts.
how could the TEE be bypased with physical access, i thought the idea with SEV is that the ram encryption key is not in memory and can't be accesed
You'd think, but apparently it can still be bypassed and AMD, Intel, and Nvidia are all hiding behind claims that they never intended for their TEE implementations to be secure against a physical attacker (despite pretty much everyone treating it as if that was the case and them correcting no one).
https://tee.fail/
Mentally strong people do not change root password after getting the same over email. Jokes aside if you looking for secure cloud infrastructure then let isn't the marketplace. The term low end is pretty much self explanatory. Need good security go with giants comes with free automatic bill generator that gives surprise mofo vibes.
Who uses password these days?
We don't send root passwords. We don't know your root password.
Our clients set their own randomly generated root password via the Cloud Portal using Cloud-init.
Our Cloud Portal doesn't store the root password.
That is so wild thank you for this post/info!! so disappointing!!!
I've always used a disposable password when signing up and then changed it immediately.
SolusVM at point stored root passwords in plain text in its database. Does it still do this?
Providers asking for root password should not be a thing.
User gives them a .pub. Provider installs it. Gives user sudo. Why does the provider having a root password even need to be a thing?
Source: Trust-me-bro