November 2009 – Here Be Subtlety

Ensuring Good Passwords: Reward or Restrict?

We’re currently in the designing phase of a password rule configuration form. At first this sounded easy, but after a couple of discussions it turned out that the whole password strength and rule configuration topic is a pretty delicate one once you start digging deeper and questioning what you originally have thought was unquestionable.

The basic question here is „What does a good password make?“ where good actually means strong. The other question is „How can we get users to choose good (i.e. strong) passwords?“ – and that’s where the trouble starts.

The problem is that there’s a lot of tension when it comes to getting users to choose good passwords. There’s tension that you might never resolve and just have to find a compromise and there’s tension as a result of a false sense of security and policies established around that sense.

An example for the first type of tension is one of the basic problems of good passwords: The stronger a password, the harder it is to remember. It would be great if everyone chose a 24-character totally random password and had a different password for each service and application they use, but that’s just not going to happen. So, we need to compromise on the strength of a password in order for people to be able to remember it.

Of course there are tools that help organize our passwords, but let’s stay real here – this is not something that for example my parents would use. If I were to install KeePass on my parents‘ computer and tell them to use 20-character randomly generated passwords from now on, my mother would stare at me blankly and tell me that she was doing just fine with her passwords.

Now there are two ways to go from here: I’d call them restriction or reward.

Restriction means defining password rules that users have to comply to. Minimum length, use of numbers, symbols and uppercase characters, and so on. I can also force users to change their passwords every two months and prevent them from using any of their old passwords.

Reward means rewarding users for choosing a good password. It’s a bit of an ‚attaboy‘-reward, but still. Whenever I sign up for a new service or change my password, I like to see the password validation bar go from red and weak to green and strong, telling me that, yes indeed, the password I chose is strong enough to protect my account sufficiently.

The problem with restriction is that it doesn’t guarantee good passwords. If you take the most common password rules, minimum length as well as required use of numbers, symbols and uppercase letters, you can still choose Admin,1 as your password and be good to go. Requiring users to change their password after a defined period doesn’t help either. The user who chose Admin,1 initially will just change the password to Admin,2 to satisfy the required password change.

A strong password doesn’t need symbols or numbers. It simply needs to be hard to guess. A good password is a random set of characters and that’s something that’s hard to put into configurable rules.

Restriction and reward don’t really contradict each other, but they’re different approaches of how to educate users to choose good passwords. There’s a difference between forcing users to adhere to a set of rules and rewarding them for making sensible choices. And there’s tension everywhere: How far can I go with configuring rules to enforce good passwords without seriously annoying users because none of their passwords are accepted? Huh?

As I said, there are a lot of questions here and I’m not done thinking about it.

The One-Hour Bug

This is the story about one of those bugs that show their ugly faces at the most inappropriate of times, seem impossible to pin down, and turn out to be very easy to fix once you get to the root of the problem. Usually after several hours of banging your head on the table, cursing at the computer, and doubting your own sanity.

You all know these bugs, right? After spending the first one or two hours digging helplessly through code I usually say „I know it’s something stupid.“ Because I do. Whenever you run into one of these obscure bugs it’s usually one or two lines of code with a stupid, stupid mistake. These bugs are usually easy to fix. But they’re hard to find. And they will make you feel like an idiot. Always.

Anyway, as for the most inappropriate of times, how does „two hours before the sprint demo“ sound? Like an amazingly inappropriate time for a bug to be found? You betcha. So last Friday it was two hours before the sprint demo and we were just trying to check all our features for one last time, when saving a new password didn’t work anymore.

As it happened I had stumbled upon the same bug the night before. However, after a couple of rounds of re-fetching from source control, re-compiling and checking the application logs, the bug just went away. It was gone. Unreproducible. There was nothing else for me to do than blaming it on the arbitrary ways that Perforce works at times. I obviously had been working with old versions and updating the files and rebuilding the solution fixed it. Case closed.

Until the next morning when the bug was there again. Nobody could explain it. Our tester had been running UI and functional tests for days in a row. We all had been using the feature from time to time and nobody had ever come across this bug. So another developer and me went about to try to fix this ugly bug as fast as possible in time for the sprint demo. In retrospective we should have thrown in the towels and asked to postpone the demo right away. But we thought it might work.

From the logs it seemed like a trigger on the database prevented saving a new password on the base that the expiry date for a password was smaller than its create date. So we pinned it down to some DateTime issue. We tweaked the code to make sure that the create date of the new password would always be greater than the old one’s expiry date. This didn’t exactly fit the trigger’s complaint, but it was the closest we came to finding an angle to start with.

Then my colleague stumbled upon another strange behavior that made it look like the new password was already associated with the login although it hadn’t yet been persisted to the database. So we tweaked the code a little bit more to make sure that we wouldn’t accidentally expire the new password.

Since the bug occurred on two forms we made sure that the changes were implemented for both of them, compiled the code and… voilà… the bug, it was gone. Still not overly confident, but at least glad that the problem seemed to have been fixed in time for the demo, we started a new build, packed up and headed to the conference room.

You want to guess what happened during the sprint demo? Naturally, the bug, it reappeared! It was back! Naturally the feature wasn’t quite accepted and our Scrum team, well… let’s say, we weren’t exactly thrilled.

Since the rest of the demo went fairly well, it was decided that the sprint would be dragged out for a few more days to give us time to fix the bug and a couple of small things. While we were talking about how to best proceed I tried to reproduce the bug on my local installation. You want to guess again? I couldn’t reproduce it. Now the local installation had exactly the same files than the build we used during the demo. We had witnessed the bug just about half and hour ago. Now it was gone again.

We spent the afternoon hunting down what might cause a bug that re- and disappears, going down various paths until we reached a point when we consulted the database guy for some NHibernate anomalies my colleague found. Then the moment of revelation, facepalms, hysterical laughter and relief came.

Whenever we set a new password we set its create date to the current time. However depending whether we were dealing with a completely new login or just a password change for an existing password the code executed was slightly different.

Now lacking an implementation to delete logins we were mostly working with existing logins. Deleting a login required logging on to the database and deleting it manually using SQL. Not a big deal, but one that interrupted the flow and was therefore avoided as long as it wasn’t absolutely necessary.

While we were working on fixing the bug we had concentrated on the part where a password is saved for an existing login. The bigger picture revealed what the real issue was. While we were using DateTime.Now when setting the password for a new login, we used DateTime.Now.ToUniversalTime() when changing the password for an existing login.

With our server settings, DateTime.Now was one hour later than DateTime.Now.ToUniversalTime(). Since we started our demo by proudly presenting that you could create a new login that meant that for exactly one hour we were unable to change the password, due to the simple fact that the database wouldn’t allow saving a password when its expiry date was earlier than its create date.

This also explained why the bug had just gone away so many times before. After one hour of time difference between the server’s time and universal time, the expiry date would be later than the create date and the database was happy. This was a bug that occurred for exactly one hour before retreating and not showing up until the next time you created a new login and tried to change its password within the same hour.

Now, as I said, the answer, once found, was amazingly easy and clear. However the path that led to the answer was pretty much paved with confusion. It also taught us the lesson to be very, very, very careful when dealing with timestamps. Because these things, they are small and look harmless, but they can make you go temporarily insane just the same.

Defending Whiteboards

What I especially love about the video below is that it shows how utterly important whiteboards are if you want to work creatively in a team. I can’t stress this enough, and I also seem to be the greatest defender of whiteboards in our development team and the first to add „No whiteboard in conference room“ as an impediment to our taskboard.

Even now the whiteboard in our current team office is far too small for my taste. To compensate this we have pinned big sheets of flip chart paper pads pinned to the rest of the walls. My old Scrum team was located in two room, so we had two whiteboards, but that still wasn’t enough at times.

Especially during design phases you need room to sketch. In a Scrum team with five developers it is not uncommon, if not preferable, to have two user stories running at the same time which means you need two designs, which means two whiteboards is the minimum that you can work with. I would still argue you need more for any technical problems, additional tasks or just whatever pops up.

Even when you constantly erase what you don’t need, we often came to a point where the only option left was taking a picture of the whiteboard to make room for the next problem. That worked, but it is still a limiting factor when you need to organize your creativity.

A thing as shown in the video where the same content can stay on the whiteboard for days and maybe more so that people can always come back to the design, rethink and rearrange sounds too good to be true.

On the other hand, I’m not complaining. As a creative team, we find ways to be creative and work within an informative workspace. As I said, flip chart pads make a good whiteboard-ersatz for a lot of problems. They don’t provide the flexibility a whiteboard does, since you can’t easily erase stuff, but they generally work well, too. You can also get cheap pinboards at IKEA (and probably elsewhere) and use these to put up reminders. Or you can hi-jack whiteboards in other offices that are currently not used.

I still believe that whiteboards are one of the most important tools you need when working in an agile team and you can never enough.

Many Browsers and a Smarter Playlist

Today at work a colleague raised the issue of which browsers we were planning to support. Naturally, supporting a browser also means testing on a specific version of a specific browsers, which, quite simply put, means more test effort, probably more coding effort, and therefore more time spent.

After a discussion with our product owner they settled on the latest stable version of four browsers. The product we were working on before supported two browsers, Internet Explorer and Firefox, with Internet Explorer being the one to optimize for, especially since one of the third party products only supported IE. Now we added Chrome and Safari to the list.

The same colleague also complained that he currently uses three browsers, sometimes simultaneously. I realized, I do too.

On Vista I use Chrome for most things. Now I know that it lacks the tons of add-ons that Firefox offers, but I just love it. I love that the design is very simple and focuses on the actual web pages rather than menu and status bars. Mostly I love typing in anything into the address field. I’ve gotten so used to it that I forget that other browsers use extra fields for Google searches and just typing my search words into IE’s or Firefox’s address bar. If there’s one thing I need other browsers to copy from Chrome, it’s this.

However, I understand that people still prefer Firefox. The fact is that I have never actually been an avid user of add-ons. I’ve had my favorite Firefox add-ons, mostly webdesign stuff like the color picker or the ruler and these were awfully helpful and cool. FireBug as well is an awesome tool for web developers. But I’ve never heavily relied on any add-ons which might have been the reason why switching to Chrome went so smoothly for me.

I still use Firefox occasionally, though, mostly when I need one of the add-ons I have installed or whenever a page doesn’t look quite so right in Chrome (still happens).

I use IE mostly for anything that relies on using IE, which sadly happens often enough. Now, I’m not even sure whether there’s still reason to hate IE (given that we’re two versions away from IE 6 it seems like the grunting phase should be over), I just still prefer Firefox and probably wouldn’t use IE if it wouldn’t rock the whole Outlook webmailing thing and wasn’t necessary to run some of Microsoft’s web applications (yes, MS Project, I’m looking at you). Plus, of course, given that IE is still widely used, it’s the browser I most often use when developing.

What I’m trying to say is that it’s gotten hard to settle for one browser, for three reason. First, sometimes you just can’t. Some pages or web applications just run or look better on a specific browser (and some will only run on a specific browser). Second, browsers seem to have their own personalities. Chrome is awesome for the whole browsing, social, fun, interactive stuff and in my opinion just generally awesome. Firefox is great because of its vast library of add-ons and because it’s really really good. IE still beats other browsers for some of the more conservative sites, probably because a lot of sites are still optimized for IE.

Last of all, the feeling I have is that all major browsers are actually getting pretty good, so there’s not a clear winner anymore. For most people that just means that they can just pick what they like best. For a geek girl like me it means that I can’t even settle on one for good.

In other news I fixed a small thing that was bugging me on iTunes. I like listening to my recently added items, but since I use my iPod for audiobooks and movies as well, these files were always mixed in between, which is especially annoying when you’re on your kickboard on the way to the train and don’t have the time to fiddle with your iPod just to skip that audiobook chapter or that episode of House.

Now, I could have realized that sooner, but of course, „Recently Added“ is just another Smart Playlist and perfectly editable. The only change I had to make was filtering it down to media kind and everything was as I wanted.

What Went Wrong With Delta

I recently tweeted about my frustration of our flight back from San Francisco with Delta Airlines. I have since then scanned a few other reviews and Delta rants and though I admit that we were comparably lucky I still would try to avoid flying with Delta in the future. Here’s why:

1. The organization at SFO was a mess. A tiny man kept pointing people in rows and though this is just an impression seemed completely overwhelmed by the task. Please note that though there was quite a queue it seemed like a totally manageable queue. Yet we were told to wait in line there then told to go to the line where we originally came from. Then they kept letting people cut the line for no apparent reason. I overheard that their flight was taking off at 6am, which was exactly the same time our flight was going and yet they seemed in no hurry to let us check in.

2. We had a little extra bag because we bought a couple of things and couldn’t fit everything in the suitcases we came with. Please beware: additional bags on Delta Airline international flights cost 50$. Now, I could have checked that on the internet, but I didn’t. So while this could be said to me my fault, it still made the mood worse. The bag was small enough to take as hand luggage, but of course we had smartly distributed liquids in all the bags and didn’t want to repack everything, so we sucked up and paid.

3. Nearly everything on the flight from San Francisco to Atlanta cost extra. Only soft drinks, coffee, peanuts and pretzels were free. Now, that I had read on the flight confirmation, so we were prepared and brought sandwiches on the place, but still. You even get stuff free on two hour flights to Poland and this was a four hour flight. They also had in-seat screens, but that didn’t really help, since all movies had to be paid extra. I didn’t check music and TV shows. Now I admit, I hardly watch movies on the plane, but it was just another thing to add to the dissatisfaction building up.

4. On the flight from Atlanta to Düsseldorf, the pillows were close to non-existent. Now, I have yet to see a comfortable airplane pillow, but this was definitely the worst I’ve had so far. No in-seat screens (which I can deal with) as well.

5. They ran out of chicken about halfway through the plane. Fine with me since I wanted pasta anyway, not so fine with my husband and even less fine with the girl behind me who had a dairy allergy and couldn’t eat cheese, which was apparently stated on her ticket but no-one seemed to care. She didn’t miss much (which I told her), since the food was pretty bad. I don’t expect much from airplane food, but I have had some pretty decent stuff on my last flights. This was nowhere near decent. Anyway, at this moment I would have expected some flight attendant to come up with a solution. Like, „upgrade“ to some business class meal or whatever, but that didn’t happen.

On the plus side, the staff on the plane was generally friendly, flights were on time. The ride was a bit bumpy, but I’m pretty sure that was the weather’s fault, not Delta’s.

I think the problem here is that I have had very good experiences with Air France so far, both on my trip to Vietnam and on the flight to San Francisco. Very professional and efficient, good service on board, manageably comfortable and actually pretty good food and drinks.

I’m pretty sure a lot of people had positive experiences with Delta and others had negative ones with Air France, but it’s still my very own experiences that I base my (flight booking) decisions on. Nothing went seriously wrong with Delta, but it went wrong enough to have me try another airline next time before I book a flight with Delta again.

By the way, the in-flight security video from Delta Airlines is Awesome (yes, capital A). I watched it with fascination on both flights and then again on YouTube, because it’s so much not what I’m used to: