Base64 encoding and its proper use

A friend of mine recently unveiled a new version of his website. Given that I too had worked on it sometime back, I decided to check it out. The main points I looked out for was security holes, since there were numerous such flaws which I fixed years ago.  Rather unsurprisingly the password reset feature of the site had one such ‘vulnerability’. It was done anew and the method used was not the most recommended although many developers opt for it. It wasn’t a bug, but a bad implementation ready to be exploited.

The culprit was an incorrect use of base64 encoding. For me, the main uses of base64 are storage and transmission of non-secret data. Although in the case of storage it’s something like hashing binary data etc. The last part ‘non-secret’ is very important. Because if one was to use the same for ‘secret’ information, then again it’s a non-recommended use. In the above scenario that was the exact thing that happened. A piece of data which was meant to be secret and easily non-readable was sent publicly after encoding with base64. And as most developers know, it’s just a jiffy to decode base64. So what I did was decode the string value, only to find out that two values were concatenated. One value was the victim’s email and the other a randomly generated string which wasn’t that hard to identify. Then it was merely to modify the above value with a known user’s email. And voila! I could reset his/her password.

Mentioned above was how a badly implemented encoding could make your web application vulnerable. And this is not something associated with low-profile companies, but even Facebook had a similar situation which was revealed in this article at 'Hacker News'.

The remedies are many, depending on how far you’d be content with given that security isn’t a 100% achievable thing. One solution is to make the random ‘salt’ a highly cryptic value. Another is to use a well-recognized encryption mechanism. Or you could even develop your own encrypt function although security experts warn against this. A rather straightforward and often used method is to implement one-way hashing such as MD5. All this methods have their advantages and perils. It’s up to the developer to decide which is best depending on factors such as performance, importance, accessibility, etc.

You have a new text message (email)!

Few months ago I was having a requirement of getting notified whenever my office mail box received an email. The preferred notification-media was SMS. So basically whenever there was a new email to my official email account, I would get notified with its subject and sender via sms.

Now then, there were several obstacles I had to conquer in order to accomplish this task.

1. Accessing & Reading my email inbox hosted at the place I work.
2. Accessing it frequently (at least every few minutes).
3. Hosting the program (script) that would do the above, on a server that’s available throughout the day.
4. Protecting sensitive/personal data from third parties (in this case it was my password).

Our office uses a Microsoft Exchange Server as its mail server. Performing programmatic tasks on MS Exchange using PHP was a very rare occurrence. So I had to rely on Mr. Google in seeking a suitable code snippet that would help me in this endeavour. And guess what, I did stumble upon a blog on how to use XML-formatted WebDAV requests to fulfil my requirement.

Building on it I developed a modified version of that script, which would send an XML request to the server, read the response (it was XML too), process it, check for new mail messages, log it (because I need to keep track of what’s new & old), and sms it to my mobile. An sms was sent for each email in case of many.

I could see the inquisitive mind wondering… ;-)

A facility called ‘email2sms’ provided by my network operator was utilised in delivering the sms to my handset. This whole process was carried out every 5 minutes and the scripts that were responsible of performing this function were hosted on two web servers hosted elsewhere. That’s because my office PC is powered on during office hours only and email relaying to external destinations aren’t allowed. Moreover I don’t have permission of using the office web server for this purpose. Keep in mind that these weren’t mentioned as obstacles at the beginning of this article, as this doesn’t serve any official purpose but one of my ‘private’ needs.

Hence, I had to host the scripts on two web servers situated in different places, they both belonging to a couple of my friends (thanks guys). These servers are operational 24*7 and the every-five-minute request was handled by a simple Linux cron job.

Did you notice me mentioning 2 web servers? Wondered why? This is to overcome obstacle no. 4. In the aforesaid script there arose a need of hard-coding my email account’s password into it. This is required for the script to access my inbox since credentials need to be given. But if anyone was to open up and read the script (this wouldn’t normally happen, but my contentment of information security wouldn’t be satisfied otherwise) my password was there for his/her taking. To avoid this happening, I considered the use of cryptography.

Using the MCRYPT_CAST_256 cipher I was able to generate the encoded (cipher) text and a relevant key. The key was hosted on the server that initiates the request while the decrypt function and cipher text were on the second. The latter would perform the core activities mentioned earlier. Splitting these elements was necessary as it would make no sense to have the key, cipher text and decryption algorithm in the same place. If anyone was to try fetching the password on the second server by performing a ‘cipher text only’ attack, still they would need an extensive amount of brute-forcing to be performed. However this was evaluated by me as computationally secure for a long time.

Something worth mentioning is the disguising of the key when it’s transmitted from the first server to the second; care was taken to avoid any logging on the latter’s part so that no readable trace of it was leftover.

Although I’m not using this service these days (cos spammers occupy a decent share of my inbox ultimately filling up my sms inbox too!), the learning and application of learned theory was something to admire in solitude.