Archive for the 'Security' Category

On online security and password policies

Published on June 27, 2008 in Security. 13 Comments

Writing the post on del.icio.us's password policy got me thinking about passwords and online security again.

Having a strong password policy such as "passwords must be longer than six characters and must contain a number or a symbol and a mix of uppercase and lowercase characters" is great in theory but let's take a moment to follow Joe User as he encounters such a policy and chooses his password:

Joe User: Ah, it won't let me use my normal password, I need to create a new one... ok, done!

Joe User: Hmm, I'm never going to remember this, let me just write it down on this Post-it note.

Joe User: Better not lose this, let's stick it on my monitor.

Joe User: Cool, now that's done, I can leave for lunch.

See the problem?

The weakest link in online security is not password strength but the human being who owns the password. Having a complicated password policy that enforces strong passwords may actually become a security issue if it results in the user writing her password down to remember it as that becomes the weakest link in the chain. (By the way, this isn't fiction, I’ve actually seen passwords on Post-it notes stuck to monitors — good, honest, strong passwords — completely compromised.)

It's a balance, for sure, but not always between security and usability as it is often portrayed. It's a balance between security and security. Specifically, beyond a certain point, increasing the complexity of password policies may actually start compromising the overall security of the whole system where the user, not the password, is the weakest link.

It's also a matter of psychology. Different applications handle data of varying sensitivity and users have varying expectations of what comprises adequate security. You expect a bank to have a strong password policy. Twitter? Not really.

Usability, of course, is also a very important consideration. There are some applications where you spare nary a thought for the authentication system, it just works and stays out of your way. Yet there are others were it seems you are always filling out the forgotten password form. Guess which ones users like more.

stu.pid.us password usability is.su.es

Published on June 25, 2008 in Security and Usability Design. 13 Comments

Hmm, I need to log in again to del.icio.us after clearing out my passwords. I wonder why my regular passwords don't work... oh well, time to start the forgotten password process.

Cool, got the email and now I'm on the site -- this should be simple:

Delicious password stupidity - screen 1

I enter a weak password -- this isn't too important an account after all. Submit.

Delicious password stupidity - screen 2

What's this? It's too short? Well why didn't you tell me on the first screen? Mumble, grumble... I type a longer password. Submit.

Delicious password stupidity - screen 3

Aaaaaaaaargh!!! You fool!

  1. Why does a simple social bookmarking service need such strong passwords?
  2. If you do need them, give people the criteria on the first screen!

This is how the form should look:
Delicious password screen alternative

I love you, del.icio.us -- please fix this!

Upgrading to Wordpress 2.3.2

Published on January 13, 2008 in Design Patterns, Development, Plugins, Security and Wordpress. 17 Comments

How unsexy are Wordpress security updates? I have the horrible habit of doing everything else first before attempting one (which, of course, is absolutely the worst thing you can do, as the recent spam hack on the SWX blog demonstrated so well). I used to dread doing the updates mainly because I just knew something would break. At least that's how I used to feel.

When I last upgraded Wordpress, a little over a week ago to version 2.3.1, I made a slightly delayed New Year's resolution that I wouldn't hack the blog. Instead, I decided to do everything using plugins and widgets (which are plugins that display on your sidebar). And -- wonder of wonders -- I actually stuck to it! That being the case, upgrading is no longer a nightmare.

In fact, when you have an unhacked Wordpress installation, all you have to do to upgrade to 2.3.2 is:

  1. Download 2.3.2.
  2. Delete the wp-content folder and the sample wp-config file from the distribution.
  3. Test it locally on your development machine (skip this step at your own peril; the last thing you want is all your readers discovering your "Doh!" moment mistake at the same time as you do!)
  4. Upload the new files to your server.

That's it. All in all, it took me under ten minutes to do. As there were no database changes between the two versions, I didn't even have to run the upgrade script (which I realized after running it on my local installation and seeing the resulting message.)

The moral of the story is that if you don't hack your blog but use plugins for everything, upgrading no longer needs to be a nightmare. Using a plugin-based architecture (which in Wordpress shares similarities with aspects and the Template pattern in object/aspect-oriented programming) gives you flexibility in customizing something without altering the original, thereby making updates to the original possible without breaking your customization.

The same moral holds true for development when you're using third-party libraries. Instead of hacking them, see if you can't extend their capabilities either via inheritance, or, even better (because it's more flexible), through composition (say via the Decorator pattern or by using interceptors). That way, unless the public API of the library changes, you won't be afraid to update the library to its latest version. (And, if you're designing an API, see if you can't include some hooks or filters in there to make it easier for people to extend it without too much trouble.)

To cut a long story short, the blog's now running Wordpress 2.3.2 and all is well. It's also a real pleasure to actually find myself looking forward to the next Wordpress update rather than dreading it! :)

Building trust in Flash-based RIAs: a security feature request

Published on November 11, 2007 in Flash, Flex, Rich Internet Applications and Security. 14 Comments

Writing about secure passwords in Buzzword got me thinking about the state of security and user trust in Flash (and Flex)-based Rich Internet Applications in general. After giving it some thought, I concluded that we have a little more work to do if users are to be expected to have the same sort of trust in Flash-based RIAs as they do for JavaScript and HTML-based applications and web sites.

The key security issue I see with Flash applications, especially those that deal with sensitive information, is that the user has no way of knowing whether or not the application is communicating their sensitive data over a secure connection.

In a traditional web application, on the other hand, serving the application over HTTPS makes the security lock icon display in the browser and thus alert the user that their data is being handled securely. If a traditional web application then tries to make an HTTP call, the user is alerted to this.

The security lock icon tells users that their data will be sent securely to the server.

In the comments to my previous post, for example, I asked whether Buzzword sends my usersame and password over HTTPS and David Colleta replied that it does. Now I trust David, of course, but what mechanism does Joe User have to trust Jane Developer when it comes to how RIAs handle data in general?

The problem I'm describing manifests itself differently based on whether you examine how it affects users or developers:

Users: A false sense of security

A Flash-based RIA is served over HTTPS. The user sees the security lock icon in their browser and thinks that any data they provide will be securely transfered to the server.

Problem: Unfortunately, the security lock only means that the application itself is being securely transmitted. Internally, the application can transfer the user's sensitive data in clear text for the world to see via HTTP and the user would be none the wiser.

Developers: How can I say "this application really is secure?"

A developer creates an application that handles sensitive data and makes sure that every data call in the application is over HTTPS. The application itself, however, is served over HTTP and so the user does not see the security lock icon in her browser and chooses not to trust the application.

Of course, the application can tell the user what it's doing but again, the user would have to trust that the application wasn't lying.

As you can see, the current state of affairs benefits neither the user nor the developer.

From the developer's perspective, there is no way, currently, of communicating to the user that the application transfers data securely short of loading the whole application over HTTPS. And, as far as the user is concerned, an application that is served over HTTPS can still make HTTP calls and compromise the user's data without the user being alerted to this fact.

One possible solution

One possible solution to this is to have Flash applications that are loaded over HTTPS display a dialog box before attempting to do an HTTP call and to give the user the option to cancel the call if they want to.

A similar feature exists in browsers already where a browser will warn you if you are about to leave an HTTPS session using a dialog box that looks like this:

JavaScript alert warning the user that they are about to leave a secure session.

What I'm proposing is a similar dialog to warn users if a SWF that is loaded over HTTPS attempts to make an HTTP call:

A proposed JavaScript alert to warn users that a Flash application served over HTTPS is about to make an unsecure HTTP call

This one enhancement should go a long way in giving developers a way of saying "this application handles your data securely" and help build trust in users.

I feel that this will become more of an issue as more RIAs start handling sensitive data like credit card details and I would love to see some proactive steps taken by Adobe to address it in upcoming versions of the Flash player.

Do prescribed secure passwords really result in better security?

Published on November 11, 2007 in Rich Internet Applications, Security and Usability Design. 8 Comments

buzzword password error

I was excited to hear that Buzzword is in public beta so I tried to sign up this morning only to be greeted with an error message: "A password must be at least 6 characters, with at least one alphabetic and one non-alphabetic character."

It's not as bad a policy as some applications have (my favorite is "Your password must be between 6 and 8 characters long and must contain at least one number and at least one non-number, non-alphabetical character). Or, even worse still, I've actually seen an application that generated a password for me and then didn't give me the option of changing it (thankfully, I've only run into that train-wreck once).

These policies are bad because, whether we like it or not, most people use the same password (or several different ones) for different services. Yes, it's not ideal for security but it is the reality we are faced with. Given this, you can either let people use their existing passwords or dictate that they create a new one for your application. Whenever an application forces me to do this, I guarantee that I will forget this password. And what do most people do when they know they'll forget a password? That's right: they write it down somewhere. And how are most successful hack attacks carried out? You guessed it: through social engineering and by rummaging through offices and/or garbage bags for little pieces of paper with passwords on them.

That little yellow post-it that you just wrote your new eight character super strong Buzzword password on and stuck to your monitor at work is more of a security risk than the six character password you usually use for stuff that you have locked away safely in your head.

Update: I also just noticed that the Buzzword login page is being served over HTTP. Of course, they may be making an HTTPS call in the application but, if they're not, it means that your lovely strong password is open to everyone else on the network to see as it travels in clear text over the Internet.

Adobe Security Advisory: Update your Flash Player

Published on July 17, 2007 in Flash and Security. 8 Comments

There is a security advisory published by Adobe that urges users to upgrade to the latest Flash Player (currently 9.0.47.0 on Win/Mac/Solaris and 9.0.48.0 on Linux).

Critical vulnerabilities have been identified in Adobe Flash Player that could allow an attacker who successfully exploits these potential vulnerabilities to take control of the affected system. A malicious SWF must be loaded in Flash Player by the user for an attacker to exploit these potential vulnerabilities. Users are recommended to update to the most current version of Flash Player available for their platform.

Affected software versions include Adobe Flash Player 9.0.45.0 and earlier, 8.0.34.0 and earlier, and 7.0.69.0 and earlier.

Not scaring away users with security

Published on December 20, 2006 in Rich Internet Applications and Security. 3 Comments

Nick Bradbury has a great blog post about how operating systems scare users from downloading and installing desktop applications with security alerts. There's a big difference between *being* secure and scaring users. It appears to me that the less secure an operating system is, the more it tends to resort to warnings as a way of limiting its liabilities (case in point: Windows and Internet Explorer).

Nick's post frames the issue as one of the reasons why people are moving to using web applications in favor of desktop applications but I want to bring this to the attention of the RIA crowd and Adobe. I know that Adobe (and Macromedia, previously) take security very seriously and I hope that they will continue to do so. However, while doing this, I hope that they remain very sensitive to not scaring users unnecessarily.

Bad Behavior has blocked 0 access attempts in the last 7 days.