Day one of ÜberConf was the workshop day, and I attended the Web Application Security Workshop with Ken Sipe. I’d say the workshop met my expectations. There were parts that I knew, parts I didn’t know, that sort of thing. Here are a few hits that stood out.
“Security and user experience are inversely related” @kensipe #uberconf
— Joe Barnes (@joescii) June 24, 2014
This is something I had never really thought of. Single sign on? Convenient! Great user experience! But it is a security vulnerability no matter how well implemented. Another example he gave that really stood out is Mint.com. Here you give them your banking credentials, and it grabs all of your transactions and helps you budget, etc. Great user experience, but now you’re credentials are stored out there.
"Given a use case, create abuse cases" @kensipe #WebSecurity #uberconf
— Joe Barnes (@joescii) June 24, 2014
In other words, think of security up front. This is often one of the last considerations given to an application, but it’s arguably too little too late. It left me with the impression that I should really bake security into an application. This makes sense because when you have the hood up on a feature, that’s when you are thinking about all of the paths and use cases. While you’re there, go ahead and think about how it can be abused.
Another observation I’ve made during this workshop is the power of two. What I mean is having two different security measures. The one we are most familiar with is 2-step verification, where after logging in with valid credentials, the web application sends you a text message with a token/id. The principle in play is the unlikelihood that someone has stolen both your credentials and your phone, or hacked both systems perhaps. Another example of this I’ve not thought of before is the unlikelihood a malicious individual has gained access to both your application data and your application source. For instance, if you hope to not repeat the LinkedIn mistake, you should salt your passwords. We could use some immutable data about each user (such as the account creation date) and apply some application-level logic to it (convert it to millis, then compute the modulo with a big ass prime number) to create the salt. Hence to unlock the hash, you need both the data and the source to know how to compute the salt with the data.
As with anything in software, there is always a cost/benefit to consider. Ken highlighted how this also applies to your threat analysis. Perhaps you have identified a vulnerability in your system. Before you address it, you should first consider the likelihood of exploitation and the cost of that exploitation. An example he gave was related to his work on GoGo internet which serves in-flight wireless internet services. The pool of potential attackers have all paid a large sum of money for a plane ticket, and they are in the network for a relatively short amount of time. Hence, the need to make sure the service isn’t stolen or somehow discounted is probably not something of great value that the development team should invest time into.
So far so good at ÜberConf. I have no idea if I’ll write any more blog posts while here. Frankly I got bored during the exercises and blogged up what I learned today. I doubt that will happen for the remainder of the event.
