Friday, May 30, 2014

What the termination of TrueCrypt Development means

So, a lot of hype has been going on the past few days about the "mysterious" circumstances which lead to the terminal of TrueCrypt development.

Since I truly believe that most of it is just hype (and a lot of it), I decided to put my two cents towards explaining what all of this means (and why it possibly happened).

Monday, April 28, 2014

How to mitigate the not-to-be-patched IE zero-day for Windows XP

So, after the XPocalypse, we have the first "critical" vulnerability that is currently exploited in the wild that affects all currently support version of IE. The CVE given to the vulnerability is CVE-2014-1776 and the Microsoft Security Advisory is 2963983.

As expected, there is no mention of Windows XP in the Security Advisory. This really is a first.

However, since there is no patch out anyway for currently supported Windows operating systems, both the consumer and server flavors, could the workarounds mentioned be used for Windows XP?

Friday, April 11, 2014

Heartbleed and Two-Factor Authentication - Does it help

Along with all the hype about the heartbleed bug, I've been reading a lot of posts and articles that recommend (amongst other things) to enable Two-Factor Authentication (2FA) to all services that support it.

In general, having 2FA greatly increases your security, since you credentials are not bound to just a username/password pair (something you know), but also rely on something you have (a phone to receive text messages or a device/application that generates one-time tokens).

Is this the panacea and the solution to the heartbleed problem?

Thursday, April 10, 2014

Heartbleed - Should I change my passwords?

Ok, so most of you should have read by now the headlines about the Heartbleed bug and it's consequences. For those of you who haven't, there is an abundance of resources out there that explain the issue (just google it). The gist of it is that an attacker could leverage the bug and access memory on the server that could contain the SSL certificates private key. Using this, they could create fraudulent certificates, mount a man-in-the-middle attack to get your credentials or, if they have been monitoring traffic between the clients and the server, decrypt the (under TLS) encrypted traffic. Additionally, the issue only exists in OpenSSL implementations that implement the SSL heartbeat feature (which is more or less 17 percent of the worlds web servers).

Ok, so, I've been getting a lot of emails from services informing me they have patched the issue and that I should change my credentials. Is this something you should do for all your online accounts?

Monday, April 7, 2014

User Authentication/Life-Cycle Management Best Practices

The last couple of years, we have witnessed an ever increasing number of pwnage to various sites, leading in compromised user accounts. A lot of these sites do not even have the user credentials hashed (even using the least amount of effort) but rather have the username/password pairs as plaintext. You can go to for a small list of such compromises. And the ones mentioned are mostly fairly recent to the blogs posting.

This allows malicious users that gain access to this data to possibly use the same credentials on different sites (because nobody reuses passwords, right?).

A greater concern is also the fact that the compromised site/services do not disclose the issue in a timely manner (in a lot of cases they are unaware the compromise happened!!!), so the user is unaware that their credentials have been leaked, allowing them (if we are talking about a slightly above average internet user) to do anything possible to protect themselves. Of course, little can be done if the site/service has very poor security mechanisms (if the user changes their password, the hacker could simply re-dump the password database for example). But, this is a conversation for another time.

What I will be focusing in this blog post is how to correctly manage user accounts in a web application. There is an abundance of frameworks out there that provide all the piping necessary to help a developer correctly set up the whole identity life-cycle. Some have more features than others, but at least they provide a start point for a developer to create more secure code. Why on earth a developer would try to re-invent the wheel is beyond me - after all, one of the basic principles of programming is code re-usability.

The blog post was heavily influenced by daily news, and Episode 1 of the Professionally Evil Perspective podcast which mentions some of the below points I will be making.

For the purposes of the blog post, I have created a Web Site project using Visual Studio 2010, which is available on here. I leverage the ASP.Net Application Services framework for the piping, but the same concepts hold for most of the other authentication and user management frameworks available out there.

Monday, March 24, 2014

New Tool Release - ASPASC (ASP.Net Application Services Configuration Tool)

After a long time about thinking of creating a tool that I could use to easily configure and maintain Membership and Role for ASP.Net applications that use ASP.Net Application Services, I finally got around into creating one.

The tool is a WCF application, which can connect to existing aspnetdb databases or help the user create a new aspnetdb database.

The tool can then maintain the users and roles available to each application in the database, as well as add additional applications.

You can find the tool on Codeplex: ASP.Net Application Services Configuration tool

As always, the tool is Open Source, so feel free to dig around, use it and should you find any issues, let me know.