Sasha Romijn

Why your certificate authority rarely matters, and expensive certificates are not safer

When you deploy HTTPS, you’ll typically need to get an SSL certificate signed by a commonly trusted certificate authority. Certificates and authorities come at many different pricing levels with many different validation depths. A common misconception is that more expensive certificates provide better security. In reality, your choice of vendor rarely matters, and more expensive certificates do not make your website safer.

Read on →

Appsterdam lecture: chips: the engine beneath your apps

This Appsterdam lunchtime lecture was on Chips: the engine beneath your apps, by Marco Jacobs

This was a live summary and has not been reviewed by the speakers. Opinions reflected are the speakers’, not necessarily matching those of the author.

Chips: the engine beneath your apps

Marco has a software background, but has been working in silicon chips for many years. He shows a disassembled Nexus 5, showing plastic casing, PCBs, optics, battery, and so on, but most importantly, the chips.

A brief history of chips

The first transistor made by Bell Labs in 1947, was rather large. About ten years later, someone at Texas Instruments built the first integrated circuit prototype. They are now rather smaller, but still based on the same technique.

Read on →

Cocoaheads January 2014 meetup summary

The CocoaHeads Amsterdam January 2014 meeting was hosted by WappZapp, in Amsterdam. There were two speakers, talking about Appcelerator Titanium and CocoaPods.

This was a live summary and has not been reviewed by the speakers. Opinions reflected are the speakers’, not necessarily matching those of the author.

Wienke Giezeman: Building native apps with Javascript

Wienke works for WappZapp. WappZapp is a video discovery app that gathers video from many sources on the internet and provides them to users in a curated way. WappZapp builds it’s apps in Appcelerator Titanium. They chose for this both for their initial development, and for the rewrite after their funding round last year.

Read on →

But where is the decryption key?

Encrypting sensitive data is usually a good practice. You’ll see many organisations, like Dropbox, advertise this as part of their offering:

Or Apple iCloud:

This means that your data is protected from unauthorized access … when it is stored in the cloud. iCloud uses a minimum of 128-bit AES encryption …

Using strong AES for this situation is a good choice. There are some other technical details to be considered, like the block cipher mode. However, a more fundamental question is missing. The technology used, be it AES or DES, is only half the story when we wonder about the security of data. The other important question is: where is the decryption key?

The nature of encryption of data means there is always someone or something holding the decryption key. If nobody has the key, nobody can decrypt it. And to someone with the decryption key, the encryption method is largely irrelevant, as with the key, the data can be effortlessly decrypted.

Read on →

Watch that cache: Dropbox and Evernote insufficiently protecting iOS 6 user’s data

With the ever increasing ways to use our mobile devices in daily life, they also collect increasing amounts of sensitive personal data. Being mobile, these devices are easily misplaced or stolen. That makes it essential to protect the data stored on the device.

For iOS developers, Apple offers the Data Protection API (for files and databases) and Keychain (for keys and small data, like passwords). With these simple APIs, access to data can be tied to the device passcode. Although this is certainly not impenetrable, it adds a substantial obstacle at virtually no cost for the app developer.

A while ago, I took a look at the data storage security in two commonly used apps for iOS: Dropbox and Evernote. I tested them on iOS 6, as I required a jailbroken device to get reliable information. As one would expect, these apps get many basics right: passwords and keys, for example, are stored in the Keychain, where they belong. However, they’ve failed to apply data protection to their caches.

This means that a significant portion of my Dropbox files and Evernote notes are available to anyone who acquires physical access to my device for an hour or so, regardless of any passcodes I might have set, if I am running iOS 6, as 15-20% of users still are. The issue could be prevented with a few lines of code. Evernote has confirmed they will not resolve this, and Dropbox has stopped replying to me.

Update: I have verified that on iOS 7, this issue has been resolved, as the default data protection settings in the OS have changed.

Update 2: On January 14, I received a message from Dropbox, thanking me for my report and offering a 100GB account quota, and a t-shirt.

Read on →

An appeal for security for the ordinary developer

A few days ago, I noticed #truebugswait on twitter. A parody of American sex education campaigns, endless jokes were made about ill advised coding practices that can trigger nasty bugs. Many of these related to security issues:

I have a lot to look forward to in life. That’s why using strcat isn’t an option. Only abstaining from strcat can 100% protect me from overflows and memory disclosures. — @natashenka

They told me that timing channel was not exploitable due to the large block size of existing MACs. They were wrong. #truebugswait — @matthew_d_green

Now, I am aware that tweets are only 140 characters, and that part of the joke was to follow an existing style. However, it made me think about how we communicate about security, and why I think we can improve this significantly.

Read on →

PyLadies December 2013 meetup summary

The PyLadies Amsterdam “Tot ziens 2013” meeting was hosted by Travelbird, in Amsterdam.

This was a live summary and has not been reviewed by the speakers.

Guido Kollerie: Data Analysis with Pandas

Guido works for a company that deals with a lot of questionnaires and other big datasets. They used to process this data in Oracle, with a lot of complex queries that didn’t work very well for them.

Read on →

WeerAPI: a ridiculously simple weather API

This week I was talking about open data at the Netherlands Environmental Assessment Agency, together with several others from the Appsterdam community. In the process, I found myself needing some realtime very basic weather data: what is the current wind direction in the Netherlands, and what is the current wind speed?

This data is collected and published by the KNMI for 36 places in the Netherlands. However, to my surprise, there is no structured format available. All they have is an HTML table. So despite thousands of open datasets having been published in the Netherlands, there is no structured way to find the current temperature on Texel.

I found this so incredibly ridiculous, that I went ahead and built it myself: the WeerAPI. It scrapes the KNMI website and has a single call for now, for the current conditions at 36 measuring stations. I enrich the data with the wind direction in degrees, wind speed in Beaufort and a very rough geographical location of the measurement stations. It’s free to use and open source, but you’ll have to credit the KNMI if you use the data. Updates come in every 10 minutes.

A basic guide to when and how to deploy HTTPS

Many web developers know about SSL, but it is very common to see it only partially deployed, or not deployed where it should be. This basic guide on when and how to deploy SSL will help you avoid the most common mistakes.

Key points

  • If you have any kind of confidential information, or if you have logins, even if they are just for admins, you should deploy HTTPS. The risks are not theoretical.
  • Never deploy HTTPS partially: use it for all content, or many risks are left open, like the interception of session IDs, which is almost as good as passwords.
  • When you deploy HTTPS, enforce all requests to be served over HTTPS, by redirecting any plain HTTP requests to HTTPS URLs.
  • Enable strict transport security (HSTS) to further reduce the opportunity for attacks.
  • Set the secure flag on your cookies, like the session cookie, to make sure they don’t leak out through plain HTTP requests.
  • If you are running OpenSSL 1.0.1, make sure you use OpenSSL 1.0.1g or newer, or a version which has been otherwise patched for heartbleed. In general, keep your OpenSSL up to date.
  • Make sure to configure your ciphers properly as well. Preferably, you should support forward secrecy. Many default configurations are insufficient. Check this with the Qualys Labs SSL server test.

Last updated: July 5, 2014: added section on ciphers.

Read on →

Proof of concept: arbitrary remote code execution through pickle-backed cookie-based sessions

Flask is a lovely Python microframework for developing web applications. Based on Werkzeug, one of the features supported are secure cookie-backed sessions. Django is a larger framework that also supports cookie-backed sessions.

In some situations, which the documentation tells you to avoid, this can be used for arbitrary remote code execution, and I built a little proof of concept to show how easy it really is. Before I cause any panic: this is not a new vulnerability of any kind in any software. This is a known risk when using these type of sessions and not following the documentation.

Read on →