Tuesday, 25 March 2014

Namespro has seemingly poor password storage methods

Somehow I managed to lose the password to my Namespro.ca account, which I had setup at one point for managing a number of my domains. It was likely that my password manager had an incorrect entry at some point or some other silliness resulted in my inability to log in. Needless to say I needed to reset the password and so I tried…

Why am I limited to between 4 and 16 characters for my password? What logic dictated this? There are a multitude of reasons on a technical level for this sort of behaviour, so I decided to ask them to get clarification.
I noticed that you enforce a 4-16 character limitation on passwords. Could you please answer the following:
- Is this limit purely a limitation created by the forms?
- How are they being stored in your database? Is it in plaintext or some sort of cryptographic algorithm?
Very straightforward questions and something that does deserve some level of technical explanation–no? Wrong. Here’s what they sent back:
Although you have not specified, we believe you are referring to the password of your Namespro.ca account. To answer your questions:

1) The password requirement is validated by server-side algorithm.
2) Passwords are encrypted before being stored in our systems
We hope the above information is helpful to you. Please do not hesitate to contact us if you have any other questions. We will be glad to answer them for you.
“Server-side algorithm” and “passwords are encrypted” don’t tell me much. A “server-side algorithm” is what is providing the SSL connection between you and my server, but without you looking at the certificate that is fairly vague no? I decided to press a bit further:
Thanks for having gotten back to me. Could you please elaborate on this?

1) When you mean “server-side algorithm”, do you mean that the password length is limited by it? Can you elaborate on what this “algorithm” is? Is it what limits you from storing the passwords beyond 16 characters? Are there any starting characters that are not permissible?
2) What method of encryption do you use for storing the password? DES, 3DES, MD5, BCrypt, ROT13? Is it something else? Do you employ a per-user salt or a global salt?
These two questions are once again pretty straightforward–although throwing “ROT13″ into the mix might seem snarky. Why did your engineers decide that four to sixteen characters is an acceptable length and what do you use to ensure that the passwords are stored correctly? Sadly Namespro didn’t want to give up that information but instead tried to go this route:
Unfortunately, we cannot disclose the actual process on how we protect our data and passwords. However, we can say that the 16 characters limit was a decision by our engineers and all front end implementations are simply an extension of that decision. You can also use any letters, numbers and characters you wish and in any combinations. Please be assured in our 10+ years of operation, there has not been any security compromise on our client’s accounts. This may be one of the reasons why clients such as:
use our services.
Let’s extract what we’ve learnt from Namespro based on the conversation so far:
  • Passwords are stored within the server using a “server-side algorithm” that “encrypts the passwords” but for whatever reason the developers of the back-end saw it fit to limit user to a password length of anywhere between four and sixteen characters.
  • Namespro believes that giving any details about itself and its storing of passwords could lead to a potential compromise even though the choice of algorithm provided if done correctly would unlikely lead to it and if in the event there is a compromise that the knowledge of the password storage mechanism probably wouldn’t really matter anyway.
  • That its impeccable record of not getting breached and having clients like the RCMP being used to endorse their services should be enough to calm my fears.
Here’s my opinion on what I think based on the conversation thus far:
  • Passwords are limited from 4-16 characters either due to a limitation in their database, the cryptographic storage method used, or some sort of silliness in their code; whatever that may be.
  • They’re afraid to admit that they have inadequate password storage and would rather tell me to leave than to address the issue at hand. They hide behind the statement that informing me of their storage method would lead to compromise, but lots of organisations have informed their users in the past.
  • Namespro believes that they have “police-grade security” thanks to clients like the RCMP being in their list.
After having discussed further with Namespro, I got the following:
Thank you for your comments. We appreciate them and have forwarded them to our management team for review. However, at this time, we do not believe there is any further information we can provide. We fully understand some user’s concern about security and our response is again that we have never had a security incident with our accounts. Our goal is indeed to continue to strengthen our security as we go along but the manner and time frame on how this is achieved is the sole responsibility of our management team and engineering team.
Not having an incident ever does not excuse poor password management. Having an account with another registrar, I decided to ask them what they do to store passwords. Their response? While not ideal, they told me that they were using SHA256 with a per-user salt and no real limits on password length. This is far better than what I am getting from Namespro.

So I tossed this response back:
Please let your management know that I have spoken with another registrar that I conduct business with and they were more than happy to let me know how they store their passwords. If you’re concerned about sharing this information with the public then it is apparent that you do not have these details stored securely.
And got this back:
We regret to hear about your point of view, although drawing such conclusion about our password security is premature in our opinion. Again, password policy is not 100% based on security alone, there are other operation consideration. If you require any assist with domain transfers, we will be more than glad to assist. Once again, we apologize it does not work out, and are prepared to serve you again in the future if you change your decision. Have a nice day.
Needless to say, Namespro is telling me that they don’t care. If you’re a customer with Namespro: leave.


It was pointed out to me that I didn’t differentiate between them hashing or encrypting passwords. This was on purpose as I assume that based on their responses they’re not hashing at all but using some sort of two-way method.

No comments:

Post a Comment