Monday, 24 January 2011

SSL is not about encryption

Monday, 24 January 2011

It’s about assurance. It’s about establishing a degree of trust in a site’s legitimacy that’s sufficient for you to confidently transmit and receive data with the knowledge that it’s reaching its intended destination without being intercepted or manipulated in the process.

Last week I wrote a (slightly) tongue-in-cheek post about the Who’s who of bad password practices. I was critical of a number of sites not implementing SSL as no indication of it was present in the browser. “But wait!” some commenters shouted, “you can still post to HTTPS and the data will be encrypted” they yelled, “stop propagating fear and misunderstanding”, they warned.

I thought carefully about these responses and made a little update at the end of the post but the story of posting data from HTTP to HTTPS is worth more than just a footnote. The real misunderstanding in this story is believing that just because the credentials are encrypted in transit, SSL has been properly implemented. Let’s took a good look at what’s wrong with that belief and why there’s more to SSL than just encryption.

Read more

Monday, 17 January 2011

Who’s who of bad password practices – banks, airlines and more

Monday, 17 January 2011

Ah, passwords. Love ‘em or hate ‘em, they’re a necessary evil of the digital age. The reality is we all end up with an alphabet soup of passwords spread over dozens of various sites and services across the internet. Whilst we might not always practice it, we all know the theory of creating a good password; uniqueness, randomness and length. The more of each, the better.

Of course we frequently don’t do this because of all sorts of human factors such as convenience, memory or simple unawareness of the risks. Still, when it’s a case of individuals electing not to create secure passwords, they really only have themselves to blame.

But what happens when the website won’t allow you to create a secure password? Or at least when they severely constrain your ability to create long, random, unique passwords? And what about when they don’t allow you to send it between your computer and their server securely?

Even worse, what happens when our most “secure” institutions implement lazy password policies? Unfortunately, all of this is pretty rampant practice.

Read more

Wednesday, 12 January 2011

Continuous web application security scanning with Netsparker and TeamCity

Wednesday, 12 January 2011

Late last year I got all excited about continuous deployment with TeamCity when I wrote a five part series on using it in conjunction with web deploy. I then went on to write about Continuous code quality measurement with NDepend and TeamCity and Continuous project statistics with StatSVN and TeamCity. Needless to say, I’m a bit of a fan of continuous, automated processes which make the software development process more predictable and result in a higher quality product.

Speaking of quality, there are very few things that drop the quality bar faster than software with security vulnerabilities. Web application security is something I’m pretty passionate about, and for good reason. Nothing destroys reputation like security holes (I take it Gawker is still fresh in everyone’s minds), and when it comes to web applications, security holes are everywhere.

One of the problems with software security is that it’s easy for it to appear a bit like black magic, or at least like an entirely foreign industry to software development. The application security space is an alphabet soup of acronyms (XSS, CSRF, WAS), strange sounding attack practices (tab-napping, click-jacking, HomoXSSuality) and other odd concepts. Unsurprisingly, these concepts aren’t always clear and we end up with apps with holes in them.

So we (hopefully) do security scans before going live to make sure everything is safe and sound. These often take the shape of manual penetration tests or automated analysis. The problem we have though is the same one I touched on when I wrote about NDepend; finding quality or security issues right at the very end of the project is too late! You’re back between that rock and hard place where you’ve pushed all your risk to the end of the project and if it comes to bare, you’re going to need to choose between delivering a degree of quality problems versus likely delivering late and over budget. It’s not a nice position to be in.

Read more

Monday, 10 January 2011

Why your app’s security design could affect sales of Acai berries

Monday, 10 January 2011

Here’s the thing about securing credentials in web apps; you’re not just responsible for securing your application, you’re also responsible for securing your customer’s identities.

Let me demonstrate:

123456, password, 12345678, qwerty, abc123, 12345, monkey, 111111, consumer, letmein, 1234, dragon, trustno1, baseball, gizmodo, whatever, superman, 1234567, sunshine, iloveyou, fuckyou, starwars, shadow, princess, cheese

These 25 passwords were used a total of 13,411 times by people with Gawker accounts. The first one – 123456 – was used over two and a half thousand times alone.

How do we know this? Because every one of these passwords and hundreds of thousands more were stolen from Gawker last month and released into the wild where they are now readily accessible. Because people reuse their credentials, Gawker’s approach to application security didn’t just compromise their own data, it compromised an untold number of other applications.

Read more