Archive for August, 2010

Some musings on passwords

Thursday, August 19th, 2010

Ah, security.  Here we go again.  My thesis in this post is that we all occasionally mistake “complexity” for “security” when choosing passwords – or, as administrators, setting password policy.  An IT administrator who checks every box in the password policy configuration may not be doing much more to secure users’ accounts than his peer who sets a password to “12345” to “test things out” – and forgets to change it later.  Similarly, an admin who configures passwords to expire every two weeks may be less secure than a more pragmatic one who sets a time limit of 3 or 6 months.

Countless essays, papers, statistical analyses, and blog posts have discussed the topic of passwords (a remarkably rich subject), so hopefully I’m not just adding to the the noise by saying: All too often, I see people forget about the “Threat Matrix” (not related to, well, anything by the same name).

The “threat matrix” is really a multi-dimensional graph of vulnerabilities, responses, and new vulnerabilities caused by those responses.  But for the sake of this post, let’s look at two of the dimensions:

  1. In what ways can a password be circumvented, and
  2. How can you counter those threats in the most effective way

A password can be beaten with a random string attack, dictionary attack, network sniffer, or simply a bad guy dropping by your office after-hours and rifling through your drawers.  A common mistake is thinking that common forms of thwarting some attacks necessarily make ALL attacks less likely.  Almost by definition, decreasing the odds of one attack type increase the odds of another. 

So, to the admins out there setting security policy: consider that the security benefits to increasing password length and complexity requirements do NOT rise linearly with increased length and complexity.  In fact, they drop off pretty quickly.

  • A password that has a requirement of “10 characters, at least one lower-case and one upper-case, one number, one special character, and one ancient greek symbol that doesn’t appear on your keyboard” is NOT a more secure password.  Because, by the time the frustrated user has tried 47 different memorable-but-impossible-to-remember passwords, s/he’s gonna have to write that damned thing down – and we all know THAT isn’t secure.
  • Full l33tspeak is not a secure password strategy.  If every one of your passwords is the l33tspeak version of the username (alidbuser/@l1dbu$3r, contentdb/c0nt3ntdb), it’s not secure.
  • Dictionary attacks against a web site are impractical, and permanently locking accounts as a way to thwart them after 3 failed login attempts is ridiculous.  At very least, if you’re going to lock accounts, have them auto-unlock after 10 minutes.  This makes the effort to even try hundreds of passwords impractical, let alone the millions or billions that would be required for a full dictionary attack.

I think of all the blog posts I’ve written, this may have taken the longest.  I’ve written, re-written, and trimmed pages and pages of text to basically complain about amazingly complex password rules that some clients have in place without even knowing WHY (“because they’re more secure” is not the correct answer). 

As I’ve continually pruned this post so as not to completely bore you, I realize that the Threat Matrix is an important concept that all IT people should consider in all aspects of daily IT work.  There are plenty of real-world scenarios where the matrix of threats and responses are not fully understood, and hopefully we can make light of some of these in future posts. (more…)

Cool Tools 9: Atlassian Confluence

Monday, August 16th, 2010

I started the Cool Tools feature 3 years ago at Function1, and I’m sorry to say, I’ve listed everything you could possibly ever need now or in the future of WebCenter consulting, portal development, or portlet hacking.

HA! Truth is, while I’ve already done one lap around the “software utility” track, there are LOTs of Cool Tools out there – some directly related to portal development, debugging, or maintenance, and some more broadly defined.

In fact, I wouldn’t really consider today’s “Cool Tool” a “tool” at all – it’s a full-fledged application, and it’s likely to give the WebCenter stack a run for its money in the long term.

Allow me to introduce Atlassian’s Confluence – one of the web’s best Wiki platforms out there. We’ve been working with this application a lot lately, and have been very impressed with it. It’s a powerful wiki platform, has a robust third-party support and development network, is dramatically less expensive than Oracle products, and provides many of the features some clients bought the Plumtree portal for. (Does it surprise you to know that a bunch of the old Plumtree team ended up there?)

When ALUI Publisher was released, BEA occasionally said it would be the blog and wiki platform that customers had been waiting for (it wasn’t). Then, we started hearing that the ill-fated product called Pages was the REAL blog and wiki platform (it wasn’t). 2009 brought us some more “WCI Sample Portlets available for the Wiki/Blog/Discussions functionality” (meh, didn’t really work). This year the message clients have been hearing “it’s all about WebCenter Spaces”. Honestly, while we may or may not see the fabled 11g version of WebCenter Interaction, Spaces does look very intriguing. In my opinion, though, it’s still not as rich as the much more mature – some would say over-the-hill – WCI portal is now. And it certainly is not the right application for all WCI customers.

So, friends, until I see Oracle deliver the great, mythical, elusive Enterprise Wiki we’ve been hearing about for years, consider me firmly in the Atlassian camp on this one – the stability, ease of use, price-point, and sizable third-party ecosystem are first-rate! Don’t take my word for it – try it out yourself for ten bucks.

Stay tuned for many more tips and follow-up posts on Confluence and other third-party products that can work alongside your existing portal implementations – and some posts on where Confluence falls short of a “full Portal Replacement”. Until then, feast your eyes on… THIS:

OK I’m not going to lie to you, unlike most Cool Tools, it’s not easy to find a screen shot that embodies all of what a great wiki product Confluence is.  At least it’s not as hard as taking a picture of the wind

Treat Collaboration Server as a REST-based API

Thursday, August 5th, 2010

The IDK methods for Collaboration Server are terribly sparse – you can’t get calendar events, file sizes, or a whole bunch of other critical data that you may want if you were to actually embark on a mission to write a better UI for Collab (trust me, I have).  Sure you could try and use the woefully undocumented Collab API – I’ve shown you how to deploy the portal API in the past – but that’s a challenge in and of itself.

Instead, let’s look at an alternate approach:  use the Collab Server as a sort of REST API.  It’s not really, but the basic idea is that you use URLs in your code to directly call functionality in Collaboration Server to do certain tasks.  For example, say you want to add a Collaboration project to a page programmatically; there is no mechanism to do this through the IDK, and we have no idea how to use the API, but using a header tool, we find that through Project Explorer, it works with a simple URL: /collab/do/project/selector/add?commPage=true&projID=COLLABID.

So, it turns out we can do the same thing programmatically, by using Java’s network libraries to call that URL directly (setting the proper authenticationid).  The code after the jump shows an example of how to do this; we use this approach in Integryst’s Automater, which allows you to script a bunch of actions at a time (what good is automatically creating a collab project if you can’t add it to a community page you just created!?). 

Tweak away!


Cool Tools 8: IEWatch

Monday, August 2nd, 2010

You know what I like about Integryst’s Cool Tools feature?  You guys always have great alternatives to the specific problems these tools solve – the Cool Tool feature of Benthic’s Golden drew more comments than any other post, and they were all great!

I’ve profiled header tools before (FireBug is an obvious one), but I haven’t profiled any IE header/debug tools yet.  I’ve used IEInspector’s HTTP Analyzer before, but for the love of all that was Holy and Mighty, that thing crashed IE more often than a WebCenter Consultant on a 24 hour code bender (didn’t see that one coming did you?  yeah, I’m not funny).

So, today’s profile is for my latest IE header tool of choice: IEWatch’s IEWatch Professional.  It’s not cheap at $169, but at least it’s not as bad as HTTP Analyzer and doesn’t fold like a cheap suit (yeah, i don’t even know what that means.  i’m not funny.).  The tool is straightforward:  install it and choose View: Explorer Bars: IEWatch from IE’s menu, and you’ve got a slick header tool that gives you a decent snapshot of what IE is doing behind the scenes, showing requests, responses, post data, and pretty much everything else you need to diagnose a poorly performing ALUI portal…

So here’s my question – given that HTTP Analyzer is cheaper, but has more bugs than this place (sheeeesh!  i TOLD YOU i wasn’t funny!), what IE header tool do YOU use?