[Feature Request] Let the user set his own cpanel password

[TommyK]

As it works now the system can reset the cPanel password and send it to the customer by mail. The customer cannot set his own password from Hostbill.

One of the most wanted features from our clients is that they want to set their own password, and they have a hard time understanding why we aren't able to provide a function for that seamingly easy task.

So why aren't we doing it from cpanel? We want to have a working password stored in Hostbill so we can log in to any customers cpanel with ease, and therefore we need to set the new password from Hostbill to keep them synced.

From a security standpoint one could argue that it's actually more safe to let the customer set their own password than getting it sent by mail. There should be a minimum strength for the passwords.


EDIT: Suggestion on how it could work, please add if you have ideas on how it should work.

1. Customer clicks "Change password" at the cpanel account detail page.
2. Customer enters the password twice and are forced to use a strong password.
3. System responds with a "Check your mail to confirm your password change" and logs the password change request.
4. User clicks link in the mail, password is changed and system responds "Password changed"
5. System sends  a mail without the password confirming the change.

If the link are not clicked within a set amount of time (ie 1 hour), the verification code is deleted from the system and change is not done.

[nibb]

You are crazy  if you want something like that build into hostbill.

From a security stand of point you are asking for a lot of troubles.

Resetting and confirmation by email is the correct way to do it.

You should enforce security policies on your customers as provider, not the other way around. Give to much flexibility and you will reduce security.

[TommyK]

Please enlighten me where the risks to this are. To me it seems like a super bad idea to send any password by mail rather than let the clients set a strong password themselves.

The clients can already set their hostbill password, so how does it matter if they can set their own cpanel password as well?

[Lawrence]

Allowing customers to set their own passwords is fine, and this is a default feature of cPanel (If enabled), but I personally prefer the current system. I like the fact that customers can't reset their passwords through HostBill. The only place I want my clients logging into cPanel is through HostBill.

Everyone's user case is different, so I guess the best way to go about this is to have an option to have an option that allows you to turn on / off if users can change their passwords for their cPanel accounts.

[nibb]

Please enlighten me where the risks to this are. To me it seems like a super bad idea to send any password by mail rather than let the clients set a strong password themselves.

The clients can already set their hostbill password, so how does it matter if they can set their own cpanel password as well?

Lets assume you do not allow your customers to change their email account, not at least without doing this manually, via a ticket, etc.

If their account is hacked, lets say their hostbill account, they would reset the password, and the owner would get this email, alerting him of the breach. The hacker would not be allowed to change the email.

This is just one example, the think is that if this feature is exploted, a hacker could change all password on all your cPanel account, as opposed to resetting all of them. If the hack is a remote code, and they only explote this, the hacker will not get access to account, as opposed to the same feature which would allow them to trigger all password change.

Reset is less unsecure than change.

Personally, i prefer customers logging into cPanel to change password. Not from remote systems.

[TommyK]

If their account is hacked, lets say their hostbill account, they would reset the password, and the owner would get this email, alerting him of the breach. The hacker would not be allowed to change the email.

So, let the customer get an email that alerts them and also make them click a link to confirm the change. Fixed.

Personally, i prefer customers logging into cPanel to change password. Not from remote systems.

Does that alert the client of the breach?

I would say that the most probable cause for anyone to get into another ones hostbill is through a hijacked email account, so if they are inside hostbill you are already in a world of hurt and that wouldn't stop them from changing the password, then deleting it from the mail inbox, etc.

Everyone's user case is different, so I guess the best way to go about this is to have an option to have an option that allows you to turn on / off if users can change their passwords for their cPanel accounts.

I agree.

[thetrusteeco]

Hey TommyK,

You forgot to setup a Poll.  I added one for you.  And I think if it's optional, it's a good idea.

[TommyK]

Hey TommyK,

You forgot to setup a Poll.  I added one for you.  And I think if it's optional, it's a good idea.

Thank you, wasn't aware of it. 

[nibb]

Lawrence, if the customer email was hacked, then nothing would prevent this anyway, even without this feature, he could open a ticket and request the password, if the attacker has his email he can pretend to be the customer.

But what happens if this is not the case? If they got their FTP logins, which are the same as hostbill, or email account which are the same, or the system has a trojan, I mean you name it. Most people re use the same password. So lets assume they got into his hostbill account, because he left the browser open or someone got in, but does not have the email account of the customers.

Resetting the password here, is an extra layer of security, as opposed to logged person just being able to change the password. Also lets not forget that hostbill allows different persons with different permissions to log in.

That would prevent the attack.

But that was just one example on how reset is better vs change.

My point was in case of a remote exploit, like the recent hack which allowed to dump database. If you think this will be the first and last exploit, then good luck. Hostbill will have more exploits like any PHP and MYSQL software in the future. So if there is a remote trigger execution problem in the code, or someone doing some reverse SQL injections. Lets assume for one minute they can remotely exploit this hostbill features, the attacker does not even need to access your accounts, he just remotely changes the password of all your cPanel accounts. You get the point?

Now, if the same feature is hacked now, the attacker would still exploit this, but the effect would be he would be resetting hundreds or thousands of account, depending on the provider. This is far better then changing the password on all accounts to something the attacker can choose and getting all accounts hacked.

In the case of the reset, all customers would suddenly receive an email that their accounts was reset.

In the other case, they would probably receive nothing, neither you and all account password would be changed in the fly. Now if we add email notification to this, this does not change the security threat, they would all be notified but it would be already too late to do something about it as the accounts passwords were changed on the fly and the hackers compromised multiple accounts already. You would not have a one account breach, you would have a breach of 100%.


Now I understand you want this functionality but I don't see why its so bad, for someone:
1. Click reset
2. Click email link
3. Reset password

Vs:
1. Click change password, put what you want.

How much time would this save your customers? 30 seconds? And with a HUGE increase in reduced security.

Even cPanel suggests to disable the option to reset passwords on cPanel by email and I don't know a single provider has has this on, even while the feature is there, and you guys suggest is even worst.

Allow someone to change cPanel accounts passwords remotely, without even logging in, from a centralized database and software that stores all your accounts and logins.

I would never use this, and I just pointed out why this is reduced security. You are reducing security for flexibility. Sometimes we need to do this, but sometimes the reduced security has more cons than pros which is the case here. You are opening a huge vector attack on your system just to save a customers 30 seconds. Also, someone that resets their cPanel all the time is an idiot in the first place. Someone resetting  it once a year or once every 3 months because he forgets this logins, is fine. The features is supposed to be there for people that forget their passwords, if your customers cannot remember a password, they should a password manager.

So assuming this features is used by people that really need this because they forget their passwords, someone that forgets their passwords, would not have troubles taking 3 steps, vs one, and taking 30 more seconds to do this procedure which is not  something he does on a regular basis anyway.

Going out of topic, there as a company that charged for resetting cPanel accounts, I think it was like 1$ and it was a huge profit incomes for them. 2 points learned there:
1. Customers would not lose their passwords anymore.2
2. Customers actually paid for this because they knew it was their fault for losing it in the first place.
3. It was a huge source of income for the company.

That was out of topic but just to see how you can turn something into a business model, even something as small as passwords resets.

Going back on topic, even if this is optional. Why in the world would yo use it and make your install less secure? And even for those that do, my guess is that 1% would use something like this. I just don´t see any pros of this, vs saving the customer 30 seconds of time. Because the customer still can set whatever password he wants from cPanel if we go that route. Its not like he can't use his own password because he can.

[TommyK]

So lets assume they got into his hostbill account, because he left the browser open or someone got in, but does not have the email account of the customers.

Valid point. Added an extra step in my suggestion to remedy.

Resetting the password here, is an extra layer of security, as opposed to logged person just being able to change the password. Also lets not forget that hostbill allows different persons with different permissions to log in.

That would prevent the attack.

But that was just one example on how reset is better vs change.

My point was in case of a remote exploit, like the recent hack which allowed to dump database. If you think this will be the first and last exploit, then good luck. Hostbill will have more exploits like any PHP and MYSQL software in the future. So if there is a remote trigger execution problem in the code, or someone doing some reverse SQL injections. Lets assume for one minute they can remotely exploit this hostbill features, the attacker does not even need to access your accounts, he just remotely changes the password of all your cPanel accounts. You get the point?

Now, if the same feature is hacked now, the attacker would still exploit this, but the effect would be he would be resetting hundreds or thousands of account, depending on the provider. This is far better then changing the password on all accounts to something the attacker can choose and getting all accounts hacked.

In the case of the reset, all customers would suddenly receive an email that their accounts was reset.

In the other case, they would probably receive nothing, neither you and all account password would be changed in the fly. Now if we add email notification to this, this does not change the security threat, they would all be notified but it would be already too late to do something about it as the accounts passwords were changed on the fly and the hackers compromised multiple accounts already. You would not have a one account breach, you would have a breach of 100%.

There are already admin functions that do the password change without alerting the user, so I would guess they would use that instead of the user interface function. Also, as my suggestion is formulated at the moment, the user would still be alerted by mail if the password is changed and also have to verify that the change is wanted.

1. Click change password, put what you want.

This is not what I suggested, not even near.

How much time would this save your customers? 30 seconds? And with a HUGE increase in reduced security.

I have no problem if it so takes 5 minutes for the client to change password as long as he can do it. They are asking for it, so that is evidence enough it's needed for me. I do not agree it's a huge increase, I even argue it's better for them to not get a password sent by mail since this is stored in the database unecrypted (i presume) and in their mail box.

Also, someone that resets their cPanel all the time is an idiot in the first place. Someone resetting  it once a year or once every 3 months because he forgets this logins, is fine. The features is supposed to be there for people that forget their passwords, if your customers cannot remember a password, they should a password manager.

So assuming this features is used by people that really need this because they forget their passwords, someone that forgets their passwords, would not have troubles taking 3 steps, vs one, and taking 30 more seconds to do this procedure which is not  something he does on a regular basis anyway.

Remembering a 12 character random password is not easy, so calling them idiots because they don't remember is hardly the right thing. I have no idiots amongst my customers, they are lovely people of different backgrounds all helping me with food on the table. If they ask for something repeatedly that I can accommodate within reason, I try to help them.

Going out of topic, there as a company that charged for resetting cPanel accounts, I think it was like 1$ and it was a huge profit incomes for them. 2 points learned there:
1. Customers would not lose their passwords anymore.2
2. Customers actually paid for this because they knew it was their fault for losing it in the first place.
3. It was a huge source of income for the company.

That was out of topic but just to see how you can turn something into a business model, even something as small as passwords resets.

That seem like a very hostbillian thing to do. It's not for us.

Because the customer still can set whatever password he wants from cPanel if we go that route. Its not like he can't use his own password because he can.

No, not if we want to keep it synced with hostbill.


EDIT: Since I can't edit the OP, the new suggestion goes here;

Suggestion on how it could work, please add if you have ideas on how it should work.

1. Customer clicks "Change password" at the cpanel account detail page.
2. Customer enters the hostbill account password and the new cpanel password twice and are forced to use a strong password.
3. System responds with a "Check your mail to confirm your password change" and logs the password change request.
4. User clicks link in the mail, password is changed and system responds "Password changed".
5. System sends  a mail without the password confirming the change.

If the link are not clicked within a set amount of time (ie 1 hour), the verification code is deleted from the system and change is not done.

[tallship]

Hey TommyK,

You forgot to setup a Poll.  I added one for you.  And I think if it's optional, it's a good idea.

Wow, what a surprise! I had no idea that when I selected "it should be an option, or optional, or whatever, that all of the previous 8 voeters had chosen that exact same option lol.

Oh, by the way, thanks for adding the poll @Thetrusteeco on Tommyk's behalf

Look, people are stupid enough to use ewboontew, and the provider should be able to implement what he wants to obo his customers - no matter how stupid it is.

The biggest security issue is sending the info in clear text, of course. These password resets *should* occur within the client portal and be displayed so the customer can cut/paste, but that's not going to happen so we're stuck with sending pwds in clear text lol.

The second biggest security issue to allowing the user to set their passwords, and not enforcing so-called strong passwords, is, IMO, that people will get ahold of the user's account (usually this is a problem with their email accounts coz they pop over 110 and send via 25 - which is  just plain stupid anyway). This causes overhead in the form of admin hours whereby the provider must reset the users passwords restoring control to them, or stopping spammers from using the provider's infrastructure to send out 10,000 SPAMs a second - a common occurrence.

The best way is for the admins to reset those passwords, and reset them again when the user opens a live chat giving them the email passwords over that medium, in lieu of a more secure method, like doing it in a trouble ticket where an email is NOT sent to the user, so they have to login via https and then can cut/paste the pwd.

Just my two cents.