Most hosting billing softwares(for example AWBS) write domain registrar (for example Directi, Enom etc.) password on a MySQL database without encrypted. If servers hacked when hacker can see domain registrar password and provider may be lost all of it's registered domains(I had saw a web site that is hacked and they had lost the control of their domains). This is more important thing. How can we encrypt this data(for example if we use AWBS)?

Ask the developer of the product to change how they are storing the information. Should not be difficult.

Ask the developer of the product to change how they are storing the information. Should not be difficult.

I have contacted with AWBS. They said to me: "If someone hacks your server they will have everything. Your website, your database, etc. Why are you only worried about your directi account? Why not secure your server?"

Our server is secure. If the server hacked when we can restore it from backup. But we cannot get back the registered domains. I think they don't understand this security issue and they are working unprofessional.

I have contacted with AWBS. They said to me: "If someone hacks your server they will have everything. Your website, your database, etc. Why are you only worried about your directi account? Why not secure your server?"

Our server is secure. If the server hacked when we can restore it from backup. But we cannot get back the registered domains. I think they don't understand this security issue and they are working unprofessional.
Did you ask them, specifically, if they store the registrar un/pw as plain-text in the database?

Because that is what you are claiming.

Did you ask them, specifically, if they store the registrar un/pw as plain-text in the database?

Because that is what you are claiming.

We had bought AWBS and tryed it. I can see our domain registrar password directly on the database. it had not be encrypted. I had told them this subject.

I think this is a problem that all systems face, MB, AWBS, ClientEXEC etc etc etc.

If you encrypt the password in the database, then someone hacks your server, they are going to have access to everything, including the decryption key.

If the passwords are stored ready to send the the registra, then they will still be able to register domains using the API. Really the problem is that no matter what system you use, the password is not going to be secure, atleast not 100%.

One good method of security for your main site, is to run it from a dedicated server, that has every port on the server closed except 80 and 443, and if you must the SSH port (i would recomend chaning it to a different port number).

If you can then sotlayer is great for this, as you can just have 80 and 443 open on your public interface, and still access the server for administration over the private SSL VPN interface.

When it comes down to it, once they have control of your server, they can access your password, no matter how it is encrpyted. as the decryption key needs to be sotred on the server so that the billing software can decrypt it. Or if you store it so that it is ready to send the the registra (md5, sha etc etc) then they will still be able to use the API. There are also sites springing up that are building md5 databases, so the orginal password may be able to be recoved.

tree-host, thank you for your response.

If you encrypt the password in the database, then someone hacks your server, they are going to have access to everything, including the decryption key.

I think Whois.Cart() more secure than others. Because it does not write the domain registrar password on a database(it writes it into a php file). We maybe encrypt this file by a php encoder software. So hacker cannot see the source of this file. But hacker maybe remove the registered domains by billing software. Then we cannot do anything. We want to use an online billing software(we bought most of them) but we afraid of hackers because of this security issues on the billing softwares.

tree-host, thank you for your response.



I think Whois.Cart() more secure than others. Because it does not write the domain registrar password on a database(it writes it into a php file). We maybe encrypt this file by a php encoder software. So hacker cannot see the source of this file. But hacker maybe remove the registered domains by billing software. Then we cannot do anything. We want to use an online billing software(we bought most of them) but we afraid of hackers because of this security issues on the billing softwares.

Even if its stored in a encrypted file, your not safe, If you means something like zend encoder, if they know what the var name is (i.e. they know that $enompass contains the enom password) then all they have to do is enclude the file and echo the password, and bingo, they have the password.

100's nah 100000's of web hosts use billing software, the first level of security should be your sever, as no matter what automated billing software you use, there will always be a risk as the script itself needs the password. Even Nominet which requires its email to be PGP signed has the same issue, as the PGP key still has to be on the server somewhere for the automation.

You can never protect yourself 100%, the only real solution is to not use automated systems. If you have access to a network where you can have a private backend, then your best solution is to block all public ports except 80 and 443. When it comes down to it, if your sever is secure, your password is secure, if your server is not secure, then your password is not secure.

Why eNom no accept MD5 ?

$url='uid='.md5('resellid').'&pw='.md5('resellpw');


Really as say tree-host MB and others is very insecure...

Think: if you have 100 or 200 Domains...

You need PASTE you REAL user and PASS...

eNom only accep:

$url='uid='.('resellid').'&pw='.('resellpw');

And this is bad idea...

Err... how would creating an MD5 hash help? All they have to do is pass the hashed copy along then, it makes no difference.

In the case of eNom:


1// Only YOU IP CAN work
2// You can copy the result of MD5 in file.php (you no copy pass='wordsecret'; !!)

some idea to diminish the risks ?

An idea for you; keep the decryption key on you, have queue for all domain activities, and enter it once a day (or more/less often) to process the jobs.

This issue is indeed a problem, but it really has no steadfast solution. While I agree that no passwords should ever be stored as plaintext, tree-host is right in pointing out that if they know the system you are using, they'll have access to the decryption key if they hack into your server. One-way hash algorithms won't work, because then you won't be able to connect with your registrar. Other encryption algorithms all require a key that will encrypt and decrypt your data, and that key then needs to be stored somewhere, rendering your encryption almost useless if someone ever got access to everything.

Encryption is kind of a paradox where you have to have one to have the other, and both have to be available to the system to make it work. If someone had access to ONLY the data, you would have nothing to worry about (if it was encrypted). But if anyone ever had access to the server itself, there's really nothing you can do to fully protect the sensitive data.

One good thing about the eNom API, however, (as jjsanchez pointed out) is that you must set "allowed IPs" that will have access to your remote management/API functions.

My point in all this is that nothing is ever 100% secure - there is just no way to do it. It's like your house - it's all locked up, but you have a key. What happens if one day you accidentally lose the key? No matter what security measures you have in place, if another person has the key, it will defeat them all.

Despite all this, there really is no excuse for the AWBS people to have stored the passwords in plain-text. Now if someone gets their hands on either your server OR your data, they get the passwords instead of it all being locked up in the server. Shame on them for doing so.

Well, there is a way, of a system entering data, but not allowing anyone to get it back apart from when a key is entered - PKI. We use it for all our systems, data can be encrypted, but not decrypted without a key being entered.