A recent event that made some blog headlines got me thinking about security and stuff.  I’ve been thinking about it for a couple nights and every time I remember it, I am too tired to actually write anything.  The event was some hacking and defamation of some Facebook sites, probably Christian users.  I was online the night that the passwords got hacked and I remember making a post elsewhere warning people to change their passwords.  Almost 6 months later, the attackers organized and used that information.

From reading posts on other sites, there’s a few things wrong with the security model in place.  The flaw used to be weak passwords (and still is, I’m sure).  Another flaw was using the same password for multiple sites.  The current flaw is the security question to reset a password, where the answer to that question can be found online, possibly posted by the victim.  The attacker gains access to the victim’s email account, but can’t get to other accounts (Facebook, Paypal, banking, etc), so they answer the security questions to reset the password and have the new password sent to the email account they have access to.

There’s two things I propose to squelch this.  First, understand that hacking is best done in a hurry.  The longer you mess around in someone’s account, the more likely it is you will get caught.  So, delay the delivery of the new password for 24-48 hours.  Ideally, this would be user-defined setting in a member profile.  This is better understood when you know the other half of my security proposal.  Sure, if someone forgets their password, they will have to wait 24-48 hours to get their new password.  That is an inconvenience in the name of security, but resetting a password is a last-ditch effort.  If someone logs in frequently, they know their password.  The most common case would be someone who hasn’t logged in for many months.  If they haven’t been active on the site for months, what’s an extra 24 hours?

Ok, the second part of the improvement, probably the more important part: the password reset request is queued.  You’d think that when a user hits “forgot password” and answers the security question, the password is reset and the email is generated.  Well, now the email is delayed by a day or two.  What happens is the user successfully logs in during that window of time?  Yes, they do know their password; there is no need to reset it.  The request can be cancelled and the user notified that a reset request was attempted.  If the user thought their password was compromised, they would not use the Forgot Password/Reset Password function, they would change their password in the edit profile section after logging in.

Think of it this way.  You’re talking to a (soon to be untrustworthy) colleague.  In the casual conversation, you mention what seems like innocent information about yourself, then you excuse yourself, saying that there’s a package at UPS you need to pick up.  The colleague rushes to the UPS store and says “I’m John Smith from ABC Company.  You have a package waiting for me?”  If the clerk is bright, he’ll ask for ID.  In lieu of ID, the imposter may or may not successfully convince the clerk he is you using the information gleaned from a casual conversation (or maybe from online stalking).

What I am suggesting is that because positive proof couldn’t be made with an ID (your password), the clerk says “We’ll have your package ready at the close of day.  Stop back then to pick it up.”  Now if you show up half an hour later to pick up the package and show your ID (your password), the interception attempt was foiled and maybe you can catch the imposter when he comes back in later.

This is why I suggest having the reset delay be user-configurable.  It’s a balance of convenience vs. security (not unlike “remember me on this computer”).  If a person knows they log in to a site at least once a day, 12 hours might be sufficient.  If you only use the site once a month, maybe a 3 day delay with notifications emailed at random times telling you how much time is left.  A hacker would have to monitor your email constantly and random times to intercept all the notifications.

This idea came about from an old article I read about how you could get away with less restrictive password policies if you implemented an expiring lockout after X failed login attempts.  The theory was, if an attacker is using a script or other random generating tool to brute force a login, stalling the login attempts for 15 minutes after every 5 failed logins makes the attack unrealistic because the Change Password policy would require the user to change the password before the brute force attack could finish all the possibilities.  Then they’d have to start over.  What a waste of time.

These are just ideas, but as people start keeping and sharing more personal information online, security based on that personal information is less secure, duh.  So by making the bad guys wait, the good guys have a chance at taking action.  That’s probably why bank robbers run out the door instead of scanning the marketing brochures.

The other day I was writing some code and I got an error message.  It happened to be one of those cases where it should have worked.  You know when good code it written it just happens to work like you expect it to.  The general idea was:

    Private Sub FillCombos()
        Dim dict As New Dictionary(Of String, String)

        With dict
            .Add("Steve", "Steve Harris")
            .Add("Bill", "Bill Murray")
            .Add("Dave", "Dave's not here")
            .Add("Jack", " (Captain) Jack Sparrow")
        End With

        ComboBox1.DataSource = dict.Keys
        ComboBox2.DataSource = dict.Values

    End Sub

Seems pretty logical.  The Keys property of a dictionary is a collection and so is the Values.  A collection is just a list of things.  They should be bindable, right?  Well, no.  The error you get is: “Complex DataBinding accepts as a data source either an IList or an IListSource.”  And after poking around, it’s right.  The collections do not implement those interfaces.

So that was going to be a blog topic about how and why those collections couldn’t be databound, but when I tried it on my other computer, I noticed that I had extra methods on those collections, ToArray being one of them.  so I used ToArray and the databinding worked.  As it turns out, the ToArray was added from System.Linq.Enumerable, which comes along with .NET 3.0.  I switched the project to .NET 2.0 and the ToArray function disappeared.

So now, I’m blogging more about the blunt realization that I’m officially missing out on additional functionality that would have simplified my code.  Well, as complicated as this solution makes it:

ComboBox1.DataSource = New Generic.List(Of String)(dict.Keys)
ComboBox2.DataSource = New Generic.List(Of String)(dict.Values)

So, with the release of Windows 7, I do plan on installing VS 2008 at work and driving ahead with 64-bit development under .NET 3.5.  Well, eventually.  There’s still some Win2k workstations out there…