SOPA, while it’s not likely to be passed as-is, I would be willing to bet money that something SOPA-like will be passed. It may be watered down with many of the most offending parts removed, but for those backing SOPA it’ll still be a real victory. For them getting it on the books, even in a weakened form means it can be tweaked (and extended) later.

There’s been an amazing resistance to SOPA, from the boycott of GoDaddy to public statements from celebrities such as Adam Savage - the public outcry against this horrid piece of legislation has been quite inspiring. But how often will you be able to get so many people to stand up and take action before they start to lose interest? How many times can you raise the troops before the numbers start to dwindle; how long before the celebrities start fearing they’ll be branded in the media as extremist or crazy? How many times can you raise the call of breaking the internet and freedom of speech before the public gets bored and goes to read about the latest Hollywood divorce instead?

Here’s how I see it going:

1. Strip many of the worst parts of SOPA and get it through congress. By removing these offending pieces, those backing SOPA will try to make themselves look responsive to the community, and it’ll be played as a victory for the community in the media. All in all, if you aren’t paying attention it’ll look like a victory for the people.

2. Next year, introduce a bill to modify SOPA to change the wording here are there, edging it just a little closer to the original. If done carefully, it’ll be easy to dismiss those that try to stir up another outcry as over-reacting or even paranoid.

3. In a few years after a series of modifications, we have SOPA, just as broad and dangerous as originally intended - and the vast majority of people who fought SOPA would have no idea.

If you have a financial motivation to get something like this passed, they key to success would be patience. Chip away slowly at DMCA Safe Harbor protections, at what requires a judge instead of an administrative action, at transparency so that any action ends up happening behind closed doors. In enough time you’ve established a law that gives the US Federal Government a massive amount of control of the internet, without oversight - all in a way designed to get offending web sites off the internet as quickly as possible. To say it would be ripe for abuse would be a massive understatement.

Am I being paranoid? I honestly hope so - I really hope that there aren’t people out there looking to limit the freedoms we cherish for their own profit, but the fact that SOPA was introduced in the first place makes that hard to believe.

PCI DSS, the security standard for companies that handle credit cards, defines a number of rules as to how credit cards are handled. One of those rules, 3.3, is defined as follows:

Mask PAN when displayed (the first six and last four digits are the maximum number of digits to be displayed)

So based on this requirement I assumed that the code to do this would be common and widely available; much to my surprise there are rather few samples that do this, and of those I found they only showed the last four (which when you are handling a lot of credit cards, searching for an account by the last four isn’t all that helpful) and were often rather fragile.

So I whipped this up, hopefully it’ll be useful to others.

The regex pattern is from Regular-Expressions.info and should detect most major cards.

A couple of days ago I was sent a link to Robert Cringely’s latest treatise:  The second coming of Java - and to say I disagreed was a bit of an understatement. To me, it represents a fundamental flaw in his perception of developers, and more importantly the economics of software development.

The key to Cringely’s argument comes down to this:

When SSDs gain enough capacity there will be a shift from the Ruby world back to the Java world. Not for prototyping, because, well, it’s prototyping. But simply because the statement “Ruby is _incredibly_ slow but I don’t care because my database is slower” will no longer be true.

What he’s missing here is the real reason people use frameworks like Rails; it’s not about it being Ruby, or being the latest cool thing - it’s about developer productivity. That’s it, and that’s all there is to it - Rails allows a developer to do more in less time. That’s one of the key reasons so many Java web developers jumped ship (though I can think of a few others), and what pushed Microsoft to invest so heavily in their MVC framework.

I could fully rehash the argument, but in what I consider to be one of Jeff Atwood’s best articles,  Hardware is Cheap, Programmers are Expensive, he covers a key point to my argument - developer time is vastly more expensive than hardware. Atwood’s take on the issue is clear:

Clearly, hardware is cheap, and programmers are expensive. Whenever you’re provided an opportunity to leverage that imbalance, it would be incredibly foolish not to.

When there’s a choice between developer productivity, and spending money on hardware - the conclusion should be the same. It’s much cheaper to throw more hardware at a slower framework than it is to invest more developer time in a faster framework. For any non-trivial application, throwing more front-end servers at it will always be cheaper than slowing the development process down with a non-productivity-centric toolkit.

It’s simple economics; server hardware is getting faster and cheaper, developer time is only getting more expensive.

I was recently given the task of ensuring that a Silverlight+RIA application that could contain private information was secure for deployment to a public web site. So I started searching for automated pen-testing tools that could work against Microsoft’s Binary SOAP protocol (msbin1, a.k.a application/soap+msbin1) and found only disappointment. For various reasons, it’s significantly more complex to pen-test a application using msbin1 than traditional SOAP + WSDL.

To properly test the services, I had to make a compromise: temporarily modify the application to expose a SOAP endpoint. While this changes the state of the application and thus reduces the validity of the tests, it does provide a reasonable way of testing the web services to ensure that they are behaving as intended.

The recently released SoapUI Pro 4 adds new security testing tools that makes this a viable (and attractive option). To get this working, there are a few small changes that need to be made to the solution:

First, you’ll need to add a reference to Microsoft.ServiceModel.DomainServices.Hosting.EndPoints which is part of the RIA Services Toolkit; this allows you to expose different End Points for the service such as SOAP and OData.

Next, you’ll want to add the following configSections entry to your Web.config:

<configuration>
 <configSections>
   <sectionGroup name="system.serviceModel">
     <section name="domainServices"
      type="System.ServiceModel.DomainServices.Hosting.DomainServicesSection,
      System.ServiceModel.DomainServices.Hosting,
      Version=4.0.0.0,
      Culture=neutral,
      PublicKeyToken=31bf3856ad364e35" />
   </sectionGroup>
 </configSections>
 ...

Finally, to expose the SOAP end point:

<configuration>
 ...
 <system.serviceModel>
  ...
  <domainServices>
   <endpoints>
    <add name="Soap"
     type="Microsoft.ServiceModel.DomainServices.Hosting.SoapXmlEndpointFactory,
     Microsoft.ServiceModel.DomainServices.Hosting,
     Version=4.0.0.0,
     Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
   </endpoints>
  </domainServices>
  ...

Finally, just follow the instructions for SoapUI to setup your tests, and you can feel (just a little) more confident in your application. Passing with flying colors obviously doesn’t mean your application is bulletproof, but it helps to confirm that web service code is solid.

Now, while this does provide some insight into your application and should help find common issues, it’s not a replacement for a professional assessment by a qualified auditor. If you are handling credit cards or other highly targeted information, please consult a security specialist before a public deployment.

Earlier today, the hacker collective Lulz Security released a batch of 62,156 email/password combinations from unknown sites; I decided to take a look at the data and see if there was anything to be learned from it.

So, let’s take a look at a few stats:

Total Domains: ~5,230

Top 15 Domains:

There are over 50,000 unique passwords, but even with this many passwords, there’s still a few quite common - and very bad passwords in use:

While this is a fairly small release, the LulzSec twitter stream has a number of entries like these:

There are several tweets about people accessing Facebook, Twitter, and even Amazon accounts - what’s so unfortunate here is that service providers could easily restrict accounts on lists like this to protect the users and greatly reduce the impact of these breaches.

Until people learn that password reuse is dangerous, this will keep happening.

Update: I’ve removed a link to a tweet, as the account has since been removed. The tweet said: “@LulzSec Cheers for the paypal account with £250 in it! ;)”