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.

Friday, 14 March 2014

Tracking users via wireless networking at BSides Vancouver

BSides Vancouver 2014 has come and gone and it went off really well. I gave a presentation on Canary and had a good time overall. One thing I did do this year was keep track of the users who were sitting in the presentation room using Wi-Fi and Bluetooth.

"Scroll of Sheep" was created based on the idea borrowed from DEFCON's very own Wall of Sheep, but instead of harvesting passwords and the like from Wi-Fi networks, it scanned for enabled Wi-Fi and Bluetooth devices within one section of the conference.

It would listen in on 100 packets via Wi-Fi and do a sweep via Bluetooth every three seconds and keep track of it via a SQL database. All that was stored was the device MAC, a time stamp, and an SSID if found.

Reception of it was well-received and now I have some statistics and other data to share!

Hardware and software

Some fairly off the shelf hardware was used:

  • Laptop computer

  • LCD monitior

  • Alfa-based USB Wi-Fi adapter

  • Yagi antenna mounted on camera tripod

In addition to the above, a standard point-of-sale receipt printer was added and connected via parallel cable. Inside of the printer it had about 70 metres of receipt paper. Each day, a new roll was added to allow for proper measuring of how much paper was used--more on this later.

Even Bobby Tables showed up

The software that powered it was mostly through the use of Airmon-ng with Scapy providing the interface. You may wish to check out the source code of the software I wrote as it also incorporated a web-based display for statistics in addition to printing the data on to a receipt printer.


Here are the requirements for how things were tracked:

  • New access points were added and then ignored for the rest of the day.

  • Probes from client devices were only counted as new if they had not shown up in the last five minutes.

  • Bluetooth devices fell into the same category.

It should be noted that not much in the way of Bluetooth data was acquired (we're talking less than a handful both days) so the data has since been discarded.

Most of the activity was really in the early part of the morning due to it being the start of the conference. As the days wore on, the number of new client devices continued to drop.

The above graph shows that while Apple devices were most popular, they were outnumbered overall. I was not keeping track of operating systems, but it was surprising to see Blackberry devices this high. With better OUI data, I am sure I could have gotten far better results.

Something that should be kept in mind is that while this antenna was aimed directly at the main conference hall, data from devices not belonging to conference goers was likely in the mix--attendance was no more than 200, but 330 devices were counted on average each day. Having said that, we did have command of the entirety of the hotel's conference space and it was likely that some people had more than one device. I'd wager that 80% of the data was likely the conference attendees.


As mentioned earlier, a receipt printer was used and each day it had available about 70 metres of paper. The idea behind the printer was borrowed from Chaos Computer Congress, where a receipt printer like the one I am using was used to print out tweets that discussed the conference.

While the "paper out" light was on, there was indeed paper inside. Nobody managed to get it to spit out control characters to make it cut the paper or go into a continuous spool--this was completely possible as I had not done any filtering via the interface. Bobby Tables made an appearance on here as well too.

My girlfriend was on hand on the second day and decided to figure out how much paper had been spat out. Her approach was to just outright measure it whereas mine was to figure it out by weighing what has been printed.

Her answer was that 25 metres had been printed on day 1, but did not measure for day 2 as it was still spooling.

However, weighing the paper proved to be problematic as while I do have a scale, it's meant to measure things in pounds and kilograms, and we're likely dealing with less than a pound here--a kitchen scale would work much better. But there was one way, determine how many lines were printed.

Here's what I figured out and what I already knew:

  • Day 1 had 143 access points, 6 Bluetooth devices, and 670 client entries.

  • Day 2 had 102 access points, 5 Bluetooth devices, and 711 client entries.

  • Two lines maximum for access points, three lines for clients and Bluetooth.

  • Five lines of space between each new entry.

What this means is that on day 1, 6,397 lines were spat out and on day 2, it was 6,442. At this point, I can measure the length of each line (4 mm) and then tell you that 25.59 metres of paper was used on the first day and then 25.77 on the second. Even if I had gone and kept a single roll, I would have not ran out. One interesting fact is that the fastest a garden snail has gone at is 0.0034 m/s, which means that the printer was spitting out paper at around a third faster than that.

I guess I should have ran with my girlfriend's answer all along as I had assumed more--something like 30 metres on each day.


Next year I plan to keep track of AP encryption and get the OUI data a bit more polished. It would be nice to know if those who are tethering at the conference are bothering to encrypt their links.

A little bit more about what else was found in the data set may be written later.