Security Gone Awry: Security Practices at NamelessHost

After a debacle with one cloud service provider, I decided to go with NamelessHost, because of an egregiously bad security capability problem at this provider with their API keys. They lost my trust. I'll expand on that issue in another security related blog post and post a link to it here when completed.

I signed up to NamelessHost, primarily for NamelessObjects, which is NamelessHost's storage option that follows Amazon's S3 API. It has this same API as the first cloud provider, something that would make the switch easy in some of my projects. As a result, I did a bit more research on NamelessHost, and ended up setting up a server or two with them, due to a combination of price and performance that was also preferable to me over the first cloud provider.

Then it happened. After a couple of months with NamelessHost, they offered me a financial incentive to sign up for their "Multi-Factor Authentication." Being a security guy and not passing up some free credit, I decided to take it. 

All that being said by talking to a website over SSL, I've already entrusted a credit card and billing information, and after a couple of billing cycles I was reasonably assured that I was indeed talking to a company called NamelessHost and had no indication that they were misusing my credit card information. They fired up a page with a list of "codes" on it. The page told me that it would be the last I see of them, and that I should write them down. I took a picture with my phone instead. 

Okay, fast forward, a couple of weeks and a couple of business trips later, the micro SD card on my phone dies. I did not back up that picture of the codes, so now logging onto NamelessHost is a problem. I can reset my password, but I need that other code to sign on as well, which I do not have. Of course, one would think, these days, there is a remedy to this situation. There is. They say to contact support. 

I realize that this process may be slow, but what the hey, it was my fault. Nothing critical is happening and everything is working. I can still get to my virtual servers via ssh, my servers can still access NamrelessObjects from the API. All their mulit-factor authentication covers is logging onto the NamelessHost website. In light of the Heartbleed exploit I wanted to change my NamelessHost website password. So, now I can get to the password changing page, but I cannot log onto the website to complete the transaction. So, I contacted support, what ensued was a complete surprise. At an impasse, NamelessHost is now losing my trust as well.

George from support at NamelessHost told me that I had to send them the following information to him in an e-mail:

1) The full name on the account. 

2) The billing address of the account. 

3) The first four, and last four digits of the credit card on file for the account, as well as it's expiration date. 

4) The answer to the account security question: "What was [--deleted--]?"

I was floored! It was not because of the erroneous use of "it's!" How can this procedure be from an organization that wants to provide security to their customers? I sent back an e-mail inquiring to find some other approach as I did not want to fire them off a text document with my financial information in an e-mail. I will discuss the flawed and misguided reasons in the following snippets of what I got back from various back and forth e-mails. First, in response to my question of why I need to send all this account identifying financial information:

Unfortunately any account access issues must be handled over email due to strict documentation requirements.

I had to get a further clarification to the meaning of "strict documentation requirements", and got this statement from George:

In order to gain access to an account we must first confirm the individual that is contacting is the account owner. These documents are needed to cross reference the accounts records. The guidelines that we must follow for providing access requires these pieces of information to match.

For my assurance, George also offers this bit of instruction, should I not trust sending this information to him.

However if you would like you can send this email through our verifications email address(verifications@namelesshost.com), which is only handled by our security team.

So, the phrase "strict documentation requirements" means that they actually require all the account information including the financial information in a single e-mail. There are several things that are wrong with this misguided approach:

1. Sending information in an e-mail is not secure. 
2. Financial information and its verification should not be sent via e-mail.
3. Credit Card numbers, if portions are left out, can still be worked out.
4. The e-mail verifications@namelesshost.com is no safer than support@namelesshost.com, no matter how safe he tells me it is or to where it goes.

Let's discuss these points one by one.

The first point, should be quite obvious to most with some notion of security. However, to some it may not. E-mails are passed around from server to server in a hop to hop fashion known as "store and forward".  The very first word of that term should alarm you, which is "store". Yes, it is stored, whether in memory or on disk, it is stored. Perhaps with the NSA, it may be stored for a long period of time.  This storage happens on e-mail relays and servers, and can be anywhere.

Furthermore, lower levels are not secure. Packets that comprise the e-mail are sent over wireless, switches, and routers. Those packets can be intercepted and reassembled easily enough. E-mail relays usually have the entire assembled e-mail stored somewhere before it is sent out again to its next hop. Basically, you have no idea where an e-mail has traveled, let alone even if it gets to its final destination. One could encrypt the e-mail, but still it could be saved somewhere, worked on for a period of time, and eventually cracked. Furthermore, even in this day an age when the patent has run out on RSA encryption, most likely both parties do not have the expertise and the software set up to send a signed and encrypted e-mail.

Based on the first point, you should never send financial or authentication information in an e-mail. Even if you send it in several e-mails in a piecemeal fashion, it is just a matter of collecting e-mails from and/or to a single source and assembling them for the whole picture.

In contrast, on company websites, you enter financial information. However, due to the SSL connection, you have an assurance, albeit not a very good one, but some assurance, that you are entering your information to the desired destination, and it is encrypted along the way. Now, there is a different question on whether you trust the other organization with that information, but we'll save that for a later time. With an e-mail, you have no such assurance. Therefore, never send identifying financial information and its verifying components in e-mail.

The third point is not well understood, but extremely important. Leaving portions of a credit card out is not secure. The format for credit card numbers was made along time ago, and they were built with the intent that they could be somewhat "verified" off-line using a formula for the digits. For an example of this procedure, please see Anatomy of CreditCard Number. What this procedure does is effectively cut down the search space of the missing numbers that may be tried. It actually makes it easier to discover your actual credit card number from the given parts. In NamelessHost's request, they are asking for half the number, 8 digits and their positions, which is quite enough information for discovery. Now, combine that with all the other information associated with that number, such as the full name, billing address, expiration date, you've just given anybody who can pick up this e-mail a blank check.

The forth point is also not well understood. First of all, let us say that with points 1 and 2 we have already established that sending sensitive information over e-mail is just not a good idea. Why would sending it to a different place be any better? George may know that e-mail goes to his "security team" on a separate server, as he elaborated in response to my question about it:

I only offer this alternate email address, as only a select handful of people have access to this server. Only our Security/Abuse team have access to this server, and not our general technical support team.

George may certainly try to assure me of that, but he cannot assure me how it got to that server and to his "trusted" people. He seems misinformed at best, and demonstrates it with the following claim that if I faxed the information, it is actually less secure:

If you prefer you can send this information via Fax or Postal Mail(However I would admit that this would be less secure, as any office staff walking by can pick it up, while with Email only those staffers vetted for access to such info can see it).

His "admission" doesn't give me much trust in his organization if he doesn't trust his staffers with such information in their own offices once it gets there. Nonetheless, the point is moot. Fax is no more or less secure than e-mail, and using the post office is only marginally better. I say marginally better, only because somebody at NamelessHost may be able to ascertain that the envelope has been opened in transit and alert me that my information may have been compromised so that I may take appropriate action. With an e-mail, unless there is encryption and signature, there isn't even that assurance. You might as well write the financial information on a post card with large font, and then, mail it.

The intent at NamelessHost was that if I signed up for multi-factor authentication at their request, it was to make my experience more secure. Yet, the rectification of my current situation is tantamount to publishing all the requested information on an obscure website, most likely picked up and cached by Google and to live on in perpetuity. This situation, in the very least, results in a contradiction of purpose.

One possible approach and a STRONG SUGGESTION  for NamelessHost, and any other organization, is to eliminate the need for the financial information associated with the account for authentication purposes. They do not own this information, and it is entrusted to them solely for the purpose of charging their customers for services rendered. NamelessHost should devise other ways to authenticate their customers such that they do not expose their customers financial information. And, although it can be considered a bit misinformed on their part, forcing their customers to expose their information is an egregious act, as at that point the blame can be laid squarely on the transmitter of the information, the customer.

Since I signed up for Multi-factor authentication, unless, they change their security practices, there are only two approaches that I can take.  Create another account on NamelessHost, or go with another service. Both are undesirable and both approaches require shutting down my credit card. That's not really good for business, on their end or mine.

Why? I will not be able to unlock my account on NamelessHost. That means logically and technically that I cannot even cancel  my account, if they are following their policies. I cannot remove any servers or objects I may have. I cannot remove my credit card from their charging scheme. Given that, I will incur monthly charges for an account I cannot shut down. I must shut down my credit card so that I will no longer be charged.

I'm happy with NamelessHost as I have used it, and I still need this kind of service from some provider.  I could create another NamelessHost account. Alas I would need a different e-mail, because my current one is already in use for an "active" account. Of course, I would need to get a different credit card, which is a hassle that affects much more than my relationship with NamelessHost.

In conclusion, I signed up for Multi-factor authentication for more security with NamelessHost, and it appears that I have gotten much less.