My coworkers and I were just BSing about CAPTCHAs and how to make them harder to crack while still usable.  Tangentially the conversation just previously was about the bastards that injected a highly animated flash file on an epilepsy forum (which is messed up), and my mind drew a random connection between the two.

I wonder how hard it would be for automation to break an animated CAPTCHA, for example a small flash file that loads the text dynamically from the server (so there isn’t even the overhead of generated a dynamic CAPTCHA image) and slowly scrolls the text across, never showing all of the CAPTCHA text at once (though immediately a concern is the text could be intercepted in transit; it might be better to dynamically create animated GIFs on the server).  The implementation for this obviously needs to be much more complicated than that simple description; it has to cover attempts to compromise the CAPTCHA system without needing to do image processing.  However, if the attacker was forced to do image processing, how much of a speed bump would the animation create?

Any image processing gurus happen to know?

~ Joshbw

Two posts in a day, I’m on a roll (well not really; most posts I complete the night before and read over again during the day, before publishing, when I am lucid and not splitting attention between what I am writing, an attention hungry five year old, my wife, and an affection demanding but otherwise clueless cat. This is one of the few posts I am actually composing while at work before I forget about it). Anyway, having just finished complaining to my coworkers about yet one more site that seems to be using stupid security questions for their forgot password functionality (not one of our company sites, we have pretty strict security standards regarding when questions are even acceptable and how they are implemented, generally stricter than this post pleads for) I feel the need to share some advice with the random folks that occasionally stumble in here.

There are several things to keep in mind when creating security questions, but mostly they should be easy for the customer to remember the answer to (and please use a tolower call on both the provided and stored answer before comparing people, I don’t want to remember which case I used) and very hard for an attacker to figure out.  The number of websites that don’t get this right are staggering.

To start with the last criteria first, security questions should be hard for most attackers (I say most because if a close friend/family member is the attacker there aren’t very many questions that would meet the first criteria that the attacker either wouldn’t know or couldn’t find out).  This means the question shouldn’t have a very limited possible answer set.  “What is your favorite color?”- well lets try blue (apparently the color most likely to be a favorite in America.  Good branding job democrats), red, black, pink, green, purple, grey and orange.  We could go further in depth, but those are the most prefered colors in the US (I have no idea if it is a cultural thing, or if by extension the rest of the world shares a similar ordering) and cover the majority of the population.  That can be brute forced very easily.  Likewise questions along the lines of “How old were you when…”, “What grade were you in when…”, “What is your favorite movie genre” and so forth all easily brute forced because most people’s answers fall into a predictable and small set.  Questions like these lend themselves very well to automated attacks hunting for credentials.

Questions that are easily publicly discoverable are also a bad idea even if they otherwise have a much larger brute force dictionary.  Questions about a person’s family (father’s middle name, mother’s middle name, etc) can easily be discerned through the various family tree websites.  Questions that could easily be gleaned off of a person’s myspace/facebook/whatever page are also a bad idea since most users of these sites use their real names and are easily found doing a google (or yahoo or live if you swing that way) search.  Most profiles on social sites list favorite band, book, tv show, etc, but also things like high schools and colleges.  Using questions that are easily publicly accessible makes it easy for attackers to compromise the system with nothing more than google searching for details about a known user (they don’t work great for blind attacks though).

As for the other criteria, that the answer should be easy for the user to remember, this acts more as a constraint for how esoteric a question can get (if they have to think about the answer when filling out the field initially, they probably won’t recall what they said when prompted) than as a genuine security concern.  If the user can’t consistently answer their own security questions the feature is pretty pointless.  One of the things to keep in mind is that even general easy to come up with answers can eventually become hard to remember.  Current “favorite whatever” questions are susceptible to the user changing their mind.  For example, a person’s favorite television show tends to change over time, and they shouldn’t be forced to recall what their favorite whatever at the time they signed up for an account.

So what are good security questions?  Here are a couple I have seen and liked:

• Who was your best friend in kindergarten?
• Who was your first significant other (though not so great for people who married their first SO)?
• Where did you and your current SO go on your first date?
• What was the name of your first pet (I actually like when this is more specific to cat or dog, since many people had both simultaneously; it is easier to recall the answer)?
• What did your mom/dad do for a living when you were born?

Not all of these questions apply to everyone but they have the benefit of being fairly hard for a stranger to discover without being overly hard for the person to remember.  As mentioned though, they will not apply to everyone, which is why the user should be presented with a list of secret questions and are allowed to pick a subset for their own security questions.  The list should be broad enough that everyone should be able to find a couple applicable questions.

Venturing further there are other ways to improve the forgot password functionality, such as requiring a user to answer multiple secret questions to further mitigate against data mined attacks.  Ultimately such questions will still likely be susceptible to attacks by close acquaintances and disgruntled family so developers need to weigh the risks and business requirements when deciding how strict to be with the functionality.

So please various web developers, stop using weak questions, and please for the love of whatever you hold dear, don’t display the password to the screen or allow a new password to immediately be set after the questions were answered.  Emailing existing passwords is also not a great idea.  Setting a new random temporary password (by temporary I mean with a timeout as short as possibly can be acceptable by your application sensitivity and business cases) that gets emailed and requires the user to change on first login is probably a good practice.  For very sensitive applications the widespread “forgot password->secret question” paradigm might not even be strong enough, nor am I advocating this paradigm over another.  I am simply asking that if it is what a web developer chooses that they can take some steps to make it less vulnerable than I typically see.

~ Joshbw

I think about biological parallels to various aspects of society, the economy, life in general, and in technology specifically, fairly often.  At the same time I also think a great deal about biology from a computer science perspective, for example that the theory of evolution (well, I guess theories of evolution would be more apt, as it is an entire framework of ideas covering the development and propagation of life in a broad sense, and drilling down to individual organism development and even further to specific feature development; Darwin’s theories of Natural Selection and Sexual Selection are tiny pieces of that framework) can be abstracted to a general theory about the propogation of information, for which the information stored, changed, and transmitted in DNA (or RNA in the case of viruses, or even protein chains in prions, which recently have also been shown to evolve in a similar fashion to more complex biological molecules) is simply a specific instance.  Part of this is because I happen to be married to a biology PhD, so it is pretty common for both a biological and a computer science mindset to be communicating and influencing each other in our household, but my interests in such paths of thought predate our relationship (and perhaps were an impetus to it).

As such thought patterns are reasonably common in my weird little head, I tend to apply them to much of my professional life and the various topics that arise there (well, to be fair, there is a large blurring of professional and personal interests, so I am not sure it is accurate to make that distinction).  One thing that I have thought a great deal about is how biology applies to malware, its creation, propagation, tactics, current and future trends, and so forth.  I won’t be the first to point out that there are many, many parallels, but then I am not claiming a whole great deal of originality.

So this is what will hopefully be an introduction for a multipart series of posts, assuming motivation on my part (see previous article about how “free” my time happens to be) gets me around to producing content for the whole thing.  I suspect years from now I will be posting “Part 19″ or whatever, as some new idea pops into my head, since this concept is still evolving within my mind, influenced by my environment.  I have a brief framework for the next several posts already thought out, so it should be reasonably easy to come up with content.  My next post will begin with the concept of “Biological Cost” as that will be pertinent to many future discussions.  Beware, geek ramblings shall abound!  My regular schedule posts (which follow no regular schedule nor do they apparently conform to a regular pattern of subjects) should also continue.

~ Joshbw

It is common practice for security professionals to recommend that a website disable browser autocomple (credential caching) on authentication screens.  For example, OWASP says the following about authentication:

Browser Caching – Authentication and session data should never be submitted as part of a GET, POST should always be used instead. Authentication pages should be marked with all varieties of the no cache tag to prevent someone from using the back button in a user’s browser to backup to the login page and resubmit the previously typed in credentials. Many browsers now support the autocomplete=false flag to prevent storing of credentials in autocomplete caches.

This seems like perfectly valid advice since doing otherwise puts a substantial number of users on shared or public machines at risk.  If I use the same machine account as Chuck and Chuck compulsively clicks “yes” to IE nagging him about caching credentials (btw browser makers, the default answer that a user would compulsively click on should probably err on the side of security), when I use IE and visit a Chuck’s bank website IE will kindly fill in the credentials for me.  This would be bad.  Likewise, if a laptop were ever stolen and the user account on it was easily compromised (for example, the machine was in hibernate and the user didn’t configure Windows to require a password when being restored from hibernate), if autocomplete was used the user’s web credentials would also be compromised.

However some unrelated train of thought has lead me to feel that caching credentials on a private machine may not be such a bad idea, or more precisely that there are positive tradeoffs.  Most people only use at best a couple different credentials, as it is a pain for them to remember the variants and the associated websites (for example, my compulsive differentiation of credentials always comes back to bite me on rarely visited websites, especially since I don’t provide consistent BS answers to what my favorite color is in the forgot password functionality.  I know I didn’t write down a color, but I don’t remember what I did write down).  The problem with only using a limited credential set (and incidentally the problem with single sign on and federated websites) is that if any credential is compromised that will likely allow the threat agent access into many unrelated accounts.  For example, if I only used one or two usernames and a paypal phishing scam bit me, the attacker could very likely log in to my bank, into amazon, and so on with the same credentials (well to be clear, as previously mentioned, I use many passwords, often to my dismay, so on a personal note, the attacker would get very little).

By enabling autocomplete it makes it easier for users to use different credentials on different websites.  The browser can be in charge of remembering all of the variations rather than the user, and if any one credential set was compromised then only one account with one website is affected (unless it happens to be the credentials to your gmail account, where the attacker could just do a search of your email for all of the helpful companies that disclose your password in email).  An idea I have been kicking around is having an “This is a private computer, Enable browser caching of credentials” checkbox (with a corresponding “what’s this” link to explain the risk to users) that when checked sets the form to allow autocomplete.  That way, by default the credentials are not cached but if the user is confident that they can protect their machine they can choose to enable the functionality and thus successfully manage a larger collection of credentials with ease.

Thoughts?

~Joshbw