Is Sir Bonar one of Paul's aliases?

I just have to say that the article on ContactPoint written by Sir Bonar and quoted by Kim just feels like it was written by our one and only Paul.

Either Paul is writing under an alias, someone is working hard to emulate his ironic style, or somebody is writing seriously and just doesn't have an f***ing clue.

Interesting, very interesting....

Tags : identity / identity theft / security

Smart Card hackery

This is an old video (from May of '08) and probably accomplished using an older technology smart card (theoretically easier to break), but it's still quite interesting to watch how one can peel back the layers of a smart card in order to snoop the communications going on within the components.

The related story on Wired.com gives a lot of interesting details to the ongoing cold-ware between satellite TV operators and hackers attempting to get free TV.

Tags : smart card / hacking

Scripts, Browsers and Security

We all know that many of the common security exploits with browsers is accomplished through the use of the enhanced scripting/programming capabilities such as JavaScript or flash.

These usually aren't attacks on the browser itself, but rather are attacks where the scripting capability of the browser is used to take advantage of an existing session in another window. For example, one attack which was launched via email that included a link to a page which had javascript which opened a hidden window that went to a financial site and tried to make some stock trades. If the user happened to be logged into that institution in a different browser window, the script succeeded in selling/buying some stocks (as part of a pump/dump scheme). Sure, many people did not have that particular financial institution open at the time, but with enough spam, enough people (who should have known better) clicking on links in the email, the fraudster could generate enough successful traffic to enable their scheme.

How does one protect themselves against such attacks?

Turning off such capabilities will render many, if not most, web sites unusable. Turning on and off as necessary will make your browsing unusable for even the most patient user.

If you're running Firefox, there's an add-on you can get called NoScript which makes it pretty easy to manage which sites are allowed to run scripts and which sites are not. I've been using this for a few weeks now and while it was a little tedious at first (each time I went to a new site that used such scripts they would start out blocked and I would have to enable them with a simple click on the notice bar). I could choose to enable all scripts on the page (if I was lazy) or just certain scripts from certain parties that I trusted. I could enable the scripts permanently for sites I visited often, or only enable them temporarily for a site that I was just visiting as the result of some search.

This model makes it much less likely that I'll be surprised by some hidden script on a page that I pull up as the result of a Google search.

A very positive side effect is that those flash adds that I hate so much, are also blocked! Yeah!

I definitely recommend NoScript and what's really cool is that it's free as well.

Tags : Firefox / NoScript / security

Firefox 3.0

I've been using the new Firefox 3.0 browser for several days now and I have to say that I am very impressed with it.

The browser certainly feels substantially faster at loading the same pages that I frequently visited before with Firefox 2 and with Internet Explorer 7 -- though I have to admit that this is very subjective and that server and ISP performance come into play.

I was a bit concerned that the browser address bar no longer indicates the SSL status of the site I'm visiting. This was a conscious decision by Firefox developers and there are work-arounds for getting it back. I'm not sure I agree with the arguments either way yet, but I was a bit surprised when I first went to a site and the SSL status was no longer indicated in the address bar -- I had to go checking a bit to make sure I was where I thought I was.

The problem that drove this change was the fact that they are now indicating site status with the background around the site icon that shows to the left of the location bar and the colors for the three states (unsecure, ssl and ev) did not match the colors of the address background. The ultimate decision was to leave the address bar uncolored and solely rely on the icon background. While I agree that if there are colors on the background that they must be the same, I think I disagree with not also reflecting the colors on the address background as well. You can read more about this change and the logic/discussion behind it here.

The only problem I've observed so far is that the ordering process at the AT&T wireless site does not work (my son lost his phone and I had to order a replacement for him). I can't explain clearly what the problem is as the site just behaved incorrectly -- asking me for the same information multiple times or doing other strange things like showing nothing in the cart after I selected a phone, clicked on add-to-cart and the popup that resulted from that operation would show that no phone was put into the cart). I tried logging out and logging back in and restarting the browser -- all to no avail. I ended up having to use Internet Explorer to make the order.

Overall, I'm very satisfied with the new version of Firefox and recommend that others using earlier versions of upgrade -- you will like the speed improvements. Congrats Firefox team on a great upgrade!

Tags : firefox / browsers / AT&T / Internet Explorer / ssl

Keylogging & Security

In Identity X-File 0x01, Pam writes about a story in the UK where a 6 year old was able to bring in and install a hardware key logger on an MP's computer in the House of Commons (it was part of a BBC experiment).

I assume a physical keyboard logger like this could still be used to steal an IdP username & password, even with all the secure desktop stuff that the CardSpace client has built in…

Essentially what a key logger does is use a Man-In-The-Middle attack to capture all input to programs and applications (including login screens) on a computer. The captured data is then analyzed to pull out useful information such as login credentials, credit card numbers, and other such valuable information.

If the primary concern is login credentials, the "easy" answer is to move to some form of strong authentication that requires hardware assistance (such as a smart card or biometric reader). These usually have communications protections in them to protect against MITM attacks. This isn't so easy to implement across a number of vendors (especially if you try to do it without identity federation networks such as those discussed by the Liberty Alliance's ID-FF and OASIS's SAML 2.0) and, even if you were to do so, the non-credential data entered by the user would still be subject to loss (such as the content of all typed emails, documents, etc.).

I did stumble across one amusing way around loggers (but, IMHO, opens all kinds of other problems) which uses a screen based keyboard to enter your data by clicking on buttons -- theoretically this is less likely to be picked up by loggers. The problems with this model include:

• While you click on the keys, your credentials are displayed plain-text on the screen so anyone looking over your shoulder would get them.
• You are trusting that the party that manages that page is not going to add anything to that page to log your entries (and without looking at the code, there's no easy way to do so).
• The site is unencrypted, so anyone looking at your network traffic can get the data
• The way that you then copy the data to the appropriate application is via the Operating System's copy/paste routines, something that is frequently available to any application and so subject to attack.

I wouldn't recommend using such a solution. Just too many weaknesses for me.

The ultimate answer for key loggers is a Trusted Path (sometimes called "Secure Path"). The trusted path ensures that the user is talking to the application that they think they are talking to (i.e. that there's no MITM listening in). Microsoft talked about doing this in their Next Generation Secure Computing Base (NGSCB) (code-named Palladium), which, at one point was to be part of Vista. However, only a limited set of the NGSCB functionality made it into Vista - the BitLocker drive encryption component.

This problem isn't small and isn't easy to solve, especially when you consider the need for being able to replace keyboards (because they broke, because you want to try a more ergonomic version, etc.). If you make replacement easy, you make MITM easy. If you protect against MITM, you end up making it hard for your users to easily work with their systems (increasing IT maintenance cost).

Tags : key logger / Microsoft / Palladium / Vista / Trusted Path / Secure Path / MITM / NGSCB / SAML / Liberty / Liberty Alliance / ID-FF

Engineers and Programmers

Pam's "Baking in Security" post included a quote that raised her ire:

I remember being incredibly incensed by a Catalyst conference panel some years ago, where one of the panelists haughtily declared something to the effect of “if engineers built bridges the way coders wrote programs”… you can guess the rest of the analogy.

That kind of a statement raises my ire as well.

The engineer's job in designing the bridge is so easy:

• Engineers don't get blamed for someone driving or jumping off the side of the bridge. That's the common user model that programmers have to develop against (and we can't figure out all of the possible ways the dumb user might try to go -- there doesn't seem to be alot of "stay in your lane" mentality for computer users).
• Engineers don't get blamed when someone accidentally or purposefully damages the bridge. That's the primary security threat for a programmer.
• Engineers even take shortcuts in their bridge design.. Many bridge deck components are only attached on one side -- the other side is just resting on the vertical structure. This allows the engineer to ignore some of the lateral forces from expansion and contraction since the unattached side can move back and forth. This gave my wife a wonderful feeling when I told her about it and pointed to the place where you can see the bridge just resting (e.g. not bolted) on one end.

Note that I'm not making an excuse for bad code and when I write code I tend to try to anticipate many such situations to protect from them. I'm just saying that comparing the two jobs is like comparing first grade addition to multi-variable calculus. There's just no comparison.

Tags : programming / engineering / bridge / security / programmer / engineer