Should Enom remove this security hole?

[armstrong]

I reported this flaw to enom:

armstrong:When logged in to my reseller account, I can click "Download a complete sub-account list" (above link), and enom then gives me a complete list of subaccount info INCLUDING the current passwords. Can you see the security risk this entails? Please change your system so that password are not downloadable this way.
enom:To be able to dowload this report, you need to be logged into your account, so the only one who can get to this report must have your login and password.
armstrong:Correct. So now that i've downloaded it, what happens if one of my clients claims that someone gained unauthorized entry into his account? I'd be one of the suspects. Is there any reason at all for me to know what my sub-accounts' passwords are? I can't think of any. If they forget their password, then that's what the https://www.enom.com/help/sendpassword.asp feature is for.
enom:You can only view your retail sub account passwords. To be able to service your retail clients the password is provided. I'm sorry if this is not something you need, however many of our Resellers who service thier customers require this information to help support them.

What do you think?

 

[aazevedo]

I dont agree with downloading passwords as i think its an abuse of trust.
there are people that uses the same login and password for multiple sites, this can be very dangerous.

Also do they know that their password will be passed to others?

 

[Anthony]

Wow, that's a security hole that people definitely don't know about. Amazing.

 

[theparrot]

enom has a number of other large problems with the way they do the api security as well.


Best practices for passwords is that they are not even readable by the system admins, as they should never be stored in clear text, or even a reversable cipher.


They already have a feature to enter an account, so why would we need the passwords to service them?

 

[Mark]

Hmmm - I don't really use my Reseller account as a "Reseller" - But I can see your point .......

Can I throw a "What Happens if ?" question in ? - It will help me answer your poll ~

If one of your Sub Accounts was to order something and then "Chargeback" or default some other way - What happens then ? Does enom take the loss or you ??? -
If your Reseller Account is held responsible - I'd be able to see where this function would be helpful - If not .... Dunno ....

Please clarify - As I said , Don't really use mine as such - So I've only got access to my own accounts ~

 

[IAmAllanShore]

On a semi-side note: great reason not to have a standardized password as it would give said user access to any account that shares a username with your enom account.
And yes, I think they should remove that feature.
-Allan

 

[Riceman]

are the passwords in clear text? If so this is an issue

 

[RJ]

It could be trouble if someone got a hold of your reseller account, but I don't believe this is a security hole or a bug. Remember it's always been a fact that a reseller can access the accounts and domains of sub-retail accounts, and the system is setup that way for a reason. A reseller account basically has 100% control over their sub-retail accounts.

As a reseller, you are supposed to be managing and supporting your sub-retail accounts. Every automated notice comes from you and and those members are supposed to be coming to you for support (not enom). The API has some great features that even let resellers build their own interfaces to eNom and control their sub-retail accounts.

For these reasons, it's very important if you have a eNom retail account that you have gotten it from a trustworthy source. This does not apply to sub-reseller accounts.

 

[armstrong]

Control and accountability are two different things. As a reseller, I can already login to my account, then through that enter any of my retail sub-accounts and do whatever's necessary. enom's log will record that these changes were done using the parent reseller account. If instead changes were done by logging in as the retail account, then how is enom to know who made the changes - the parent reseller, or the retail account? If both of them deny it, then there's no way to prove who did what.

 

[Sabre]

IMO they should remove it, it is a castaphrophie waiting to happen ...

 

[SpareDomains]

I think for the reseller this is a convenient feature, however in the wrong hands could be misused I imagine.

 

[AdoptableDomains]

From a reseller account you can access a sub account with the resellers login. Hopefully this could be tracked to see who accessed it if something went wrong, somewhat like a master key in a hotel. I do think the personal login should be hidden from the reseller as long as they can gain access with the master login. resellers should have a way to reset or have a password mailed to the account owner, but should never be allowed to see it in plain text.

The way it is, and unscruplous reseller could pass on a login and password to anyone, and it may not be trackable back to them as doing so. I agree with the concern.

 

[theparrot]

Just in case my main point was missed, I am going to repeat it here.

If enom was following what are considered best practices in this area, even they would not be able to tell you what the password is. Passwords should be stored as a hash only. The clear text should not be even being stored, let alone retrievable by others.

 

[nomis135]

This is really a big bug .They should fix this as soon as possible.

 

[armstrong]

Just in case my main point was missed, I am going to repeat it here.

If enom was following what are considered best practices in this area, even they would not be able to tell you what the password is. Passwords should be stored as a hash only. The clear text should not be even being stored, let alone retrievable by others.

You're right. Remember the case of VY.com? The Netsol account was compromised because of plaintext storage of password & challenge/response codes. Even Namepros (thru VB) has a better password recovery mechanism, where you get emailed a link to change your password. The actual password is never recoverable.

In my exchange with enom, they said, "You can only view your retail sub account passwords." Uh, hello? After I view the password, I can login as the retail account and do anything I want.

Someone asked me what's the point of posting this loophole. Three things: first, so we all understand the risk of keeping domains in a retail enom account (and maybe move to a reseller account); second, with this issue out in the open, enom can't claim to not have known about the risks when the proverbial sh*t hits the fan; third, maybe enom (and other registrars) will read this and improve their security procedures.

 

[RJ]

I can't imagine that this is currently causing much problems because anyone with access to view those passwords already has complete access to those accounts anyway... BUT you make good points about traceability.

I guess when it comes down to it there is seldom a time when the parent reseller needs to know the actual password. A system like we have at NamePros would suffice. The user can retrieve his lost password himself through an automated system, or the admin (parent reseller) can have the option to reset the password on the account.

Reseller accounts are very powerful, and for good reason. Companies like namecheap.com and registerfly use the same types of reseller accounts that you have (with their own custom built API systems interfacing with it). I would not like to see eNom change the permission system at all, but I see the point of plain text passwords being a security concern.

 

[nicedomain4sale]

Oh no, that is really bad.

Your authority over the domain is not safe.

Oh my god, Enom should fixed that bug.

 

[armstrong]

survey says: 18-7 - remove this feature! Please listen to your clients, enom.

 

[webgear]

It's good this option to be removed becouse some unscrupulous can use it for himself and stole some domains...

 

[websoft]

this is terrible. what if someone turned on your computer and accessed that file!
why do people actually voted no?!