Rubymotion effort

I wrote the following on a Rubymotion Google Group thread about the disappointment that some are having with Rubymotion. I thought I would place it here. For those who don't know Rubymotion is a proprietary code library (cost $200/year) that enables the use of the Ruby programming language for iOS program development, which is entrenched in Objective-C, and just recently released Android support.

I'm not so disillusioned with Rubymotion, yet. But there are strange memory errors, and stuff that just doesn't work, or I haven't figured out "how it's supposed to work," yet.

I am more disillusioned with iPhone development in general. It's like a trip back to the 1980s, and the nineties are more than over, man! As some would have it, Ruby may be "friendly" to some. It's a nightmare to others like me, who are advocates for type safe languages and a guy who worked on functional languages, like Haskell, back in the day.

Originally, we embarked on type safety to get attain efficiency of execution from the languages in which we wrote code. In all, that was a good goal, but the ultimate benefit of that effort is now the ease with which the development process has improved. The development tools, e.g. Eclipse, are excellent at analyzing the code on the fly, good at making suggestions of method names you desire, and proper argument matching by type, and leads to much faster development process, eliminating stupid errors as a result of the dynamic compiling the IDE employs. And refactoring the code is just a few mouse clicks away, brilliant!

Ruby throws most of that progress into the trash can, and you end up with typeOs and argument mismatches so far down the line that you have write test for everything, just to make sure you typed it correctly. And you can still get burned way down in the process when you fire up the app, because your development tools don't have a friggin clue about what is to transpire. That process is ridiculously long.

I started on this project with Rubymotion because I have an Android App that I did in Java, as one does. It took me a week to learn enough intricacies about the process, and with the help of a good IDE and its integration with excellent documentation, I had a functioning Android app with maps in about a week. It was a relative breeze. 

My app contains a lot of non-ui logic, so after a failure of trying to convert the Java to Objective-C (you can read about that here), I decided to go with RubyMotion, based on the fact that I could get a common base of code that will work for both the Android and iOS. 

I've been at this Ruby crap for months, converting my Java code to Ruby. The IDE I'm using is RubyMine, which is good, but it's Ruby, so it can only be so good, and that's just not Eclipse and Java. It's been a trying experience. As a result, I have Rspecs for everything, basically which is the result of just trying to clear the typeOs and the type mismatches that the IDE can't do anything about before I get into the arduous iPhone/Rubymotion process.

Objective-C is the most inelegant language I've ever come across. Anyway, I bought Rubymotion, and it's just been a frustrating experience. Rubymine just doesn't play well with it. The debugger sucks, and is basically useless. However, its consolation is that it's better than Xcode and Obj-C. And the REPL, which is a dynamic Ruby expression evaluator in the context of the running app, is somewhat useful, except that I have so many "puts" statements in my code for debugging purposes, trying to read the result of an evaluated expression in REPL is like trying to catch chickens in the yard if you can't stop the scrolling fast enough. Also, REPL tries to print out the resulting object and if the object is large the whole thing crashes with a malloc_error, which is some throwback from the 1970s, but I digress.

The whole write code, compile, fire up the simulator, fire up the app, crash sometimes with or without an assembler dump reminds me of a time when I would accidentally drop a boxed program of punch cards on the floor, or when the card reader would chew your cards like a mad dog. Alas, you guys are probably too young to remember that, and some of you'll probably say I'm too old to be doing this stuff.

In any case, I'm hoping that some of the problems with Rubymotion can be gotten around and that the Android thing will work. I'm kind of betting on that. I've seen a lot of software come into being and improve, even Microsoft's horrible crap, given enough time. I still have faith. 

Cheers,
Dr. Polar Humenn

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.