SauRoNZA
Honorary Master
@umamankandla not sure exactly what you are doing but odds are you can probably get away with an AWS free-tier account to do it.
South Africa’s biggest forum. Discuss, discover, and connect with thousands of members.
Not a big supporter of baldie and free-tiers won't work in any case, but really appreciate the suggestion!@umamankandla not sure exactly what you are doing but odds are you can probably get away with an AWS free-tier account to do it.
Not a big supporter of baldie and free-tiers won't work in any case, but really appreciate the suggestion!
I do not think it's too much work and then you worryWhy do you think it won’t work?
The devil you know and all that, if it’s good enough for the biggest companies in the world to use then it must be pretty good…certainly better than any local VPS solution.
Even if you had to pay a little bit, probably the same price or cheaper than VPS.
Oracle and Azure also an option.
Thanks for confirming that it wasn't one of our team who acted in a way that is questionable, how ever it did highlight what we as hosts have long overlooked.I actually wasn't using Absolute Hosting and was actually joking about your "confirmation"...I was using another provider where this came up and I was truly shocked. One thing I can respect is your transparency, but it is shocking that this seems to be industry standard.
I guess what added fuel to the fire was the fact that there's articles about DoD being hacked, but hacking any service provider seems just as easy - bribe a support agent to get the root login because seemingly very few people know how unsecure servers are when hosted by another company.
You may be one of the exceptions when it comes to making security "top priority" but I find it hard to believe other companies share that enthusiasm or maybe even know how.
So please accept my apology if it seems I was attacking you, you weren't the provider(s) I was using.

I hope the guilty provider sees your post and can take note of what service and support should look like. I for one applaud it.Thanks for confirming that it wasn't one of our team who acted in a way that is questionable, how ever it did highlight what we as hosts have long overlooked.
I suppose it's easy to overlook something like this when a feature is there to make our lives easier in the instances where we need to provide support to our clients, how ever as you mentioned its a point of issue and one that needs to be addressed.
As I mentioned in a previous response, we've now applied an interim fix and removed the service password from the services management page as per below.
View attachment 1582762
In the coming weeks we'll add a feature to the client service area that will allow clients to reveal a service password to our support staff as to allow them access where support requires these credentials in order to log into a clients VPS and provide assistance.
The credentials will only be available by default for a period of 1 hour, or until the client removes access to the password.
At the time of revealing credentials an email will be sent to the client confirming that credentials have been shared along with the IP address of the logged in user that initiated the request, and the same event logged within our logs, and upon completion another email confirming that access revoked.




Correct.It is best practice to use RSA/SSH keys so no passwords are exposed/stored![]()
I like the approach to protect the client's password from the support user.A quick update on the issue reported by the op about his current / previous VPS host.
We acknowledge that the ability for support staff to see a clients service password may present a security risk and as such we have now worked on a solution that I think puts our clients at ease.
By default all staff are unable to view any service password unless a client has granted permission for that password to be shared from within the client service area.
When the password is shared an email is sent to the client notifying them that their password has been shared with support, and this includes the linked service and originating IP that initiated the change.
Additionally, these actions are logged for auditing purposes.
By default access to view the password will automatically expire within an hour unless the client revokes access.
Some screenshots showing the changes and features within the client service area.
Screenshot of what support staff see when viewing the service page
View attachment 1603586
View of the share password feature available to clients from the product management page.
View attachment 1603584
Confirmation that the service password has been shared
View attachment 1603580
Screenshot showing copies of the emails sent to the client when password has been shared or access revoked.
View attachment 1603578
Thanks for the feedback. As per prior response WHMCS doesn't store its service passwords in plain text.I like the approach to protect the client's password from the support user.
I assume it's still stored as plaintext in the database? So in the event of a data leak, clients are at risk, right?