Designing Non-Observable Passwords

19 03 2013

It is said that a system is only as secure as its weakest link.  It probably comes as little surprise that human beings are often cited as the weakest link when it comes to information security — often undermining system security keeping PIN codes in their wallets or even taping a password right onto a monitor.  Criminals in search of personal information need only target the user to find what they need.

But what poses a much bigger security vulnerability is that oftentimes, for criminals in search of this information, the easiest method to gaining access to the system is usually to just observe as users input their passwords or PINs directly into a system’s user interface (3).

To help solve this growing issue, password and PIN creation has had to evolve to meet increasing security violations. Criminals were able to access passwords which forced system designers to implement more stringent rules.  For instance, PIN numbers, which are usually 4-digits, were in some cases forced to be 6 or even 8-digits long.  Passwords now have rules such as needing to be 8 characters long and include a symbol, a number, and a capital letter.

But the real question is, no matter how long or complex our PINs or passwords are, if a criminal can actually see the input of the information onto a keypad or screen, how effective could that password really be?  Yearly losses due to this security vulnerability has been said to be nearly $60 million in the US  (1).

This is the fundamental problem with visual passwords today: they are too easy to observe.  But researchers have been trying to solve this problem by developing unobservable password and PIN input techniques.  This post will quickly summarize and discuss a few of the current research projects in this area and the inherent advantages and limitations of each.

Integrating an Unobservable Process with the Traditional Process

VibraPass is a system that has been created to work in conjunction with current ATMs (1).  VibraPass is unique in that it offers a second level of protection to an ATM by leveraging mobile phone devices.  The way it works is that a user hooks up their smartphone device to the ATM terminal, and each time the phone vibrates, the user knows that the next input in their password would be a “lie”.  A person trying to observe the input would be confused an unable to decipher what the real password is.

The concept behind this system is effective and, most importantly, user-friendly, as it builds upon the current easy-to-use PIN process.  The downside, however, which VibraPass admits, is that repeated observation by the criminal would eventually give away the pattern and allow them to discern the real password.  “The main weakness of VibraPass is that repeated observations can lead to successful attacks by analyzing the differences between inputs. The highest success rate for an attack can be assumed if the lie overhead is known by the attacker.” (3)

Looking at the security results of the VibraPass, we learn that 1 in 10,000 or less were able to observe the password, and that it was very weak against two or more observations in particular  (1).

Combining Audio and Sensory Perceptions into Password Creation

Spinclock is a password application developed to work on touchscreen mobile devices.  Spinclock combines several cognitive functions to create a secure, unobservable password process (1).

Ramesh_fig 1

Figure 1: A design view of the Spinlock application (2)

Figure 1 above shows the basic design of the application and how the settings work. Spinlock works in much the same way as a physical dial lock with incremental numbers and audio or haptic cue.  The user would go to their settings and select a random combination for the password.  Then they’d select the circle and spin it in the correct direction and begin to count.  Unlike a physical lock, where going three to the right had a designated position on the dial, Spinlock provides completely random auditory or haptic queues to notify the user when they have moved one “space”.  This makes it difficult for an observer to understand how many positions the user has moved on the lock (2).

Some of the disadvantages of this system would be the randomization of the sensory cues can cause confusion on the users themselves, leading to higher levels of input error when compared to traditional PIN or password input methods. “Also, the majority of errors (78%) involved entering digits one higher or lower than the target item. Comments by participants provided a feasible explanation for this; several spontaneously remarked that the randomly distributed nature of the cues made predicting the location of the final target challenging. In particular, several mentioned that unintentionally overshooting the target item was the most frustrating aspect of the experiment.” (2)

Looking at the security results of the Spinlock, we learn that 1 in 10,000 were able to observe the Spinlock password, and that multiple observations had no effect on this number (1).


From a user-experience perspective, it is likely that the traditional, visual-based password and PIN system will usually have a higher level of user input accuracy than an auditory or haptic-based system, and will also likely be faster and more efficient.  However, when we look at the security studies, it is clear that the non-visual password systems are much more effective against observation.

Additionally, I believe there is a level of comfort and familiarity between users and the long-known password and PIN system.  Use of auditory and haptic systems might be a little frustrating to understand and use in the beginning, but over time I feel that it will become a norm which people will learn to use.

Besides, if learning to get used to listening or feeling for my password is the alternative to having to memorize a 12-digit code that needs to have at least two capital letters, a symbol, three numbers and needs to be changed every 6 months, then I’m gladly open to learning something new.


  1. Bianchi, Andrea, Ian Oakely, and Dong Su Kwon. “Open Sesame: Design Guidelines for Invisible Passwords.” Computer April (2012): 58-65. Print.
  2. Bianchi, Andrea, Ian Oakley, and Dong Su Wong. Spinlock: A Single-Cue Haptic and Audio PIN Input Technique for Authentication. Tech. N.p.: Springer-Verlag Berlin Heidelberg, 2011. Print.
  3. De Luca, Alexander, Emanuel Von Zezschwitz, and Heinrick Hußmann. “VibraPass – Secure Authentication Based on Shared Lies.” Proc. Conf. Human Factors in Computing Systems (2009): 913-16. Print.

Password Security

12 07 2012

Early in June, more than 6 million LinkedIn passwords were posted to a Russian hacker forum.  Lastfm and eHarmony also confirmed that millions of their passwords were stolen.  [1]  LinkedIn’s own blog admitted the breach had taken place, apologized, and then posted some recommendations for how users create passwords.

1)  Make sure you update your password on LinkedIn (and any site that you visit on the Web) at least once every few months.

2)  Do not use the same password for multiple sites or accounts.

3)  Create a strong password for your account, one that includes letters, numbers, and other characters. [2]

Those three pieces of advice appear all over the internet.  Cisco’s security blog on June 6 reminds people to use “random, long strings” for their passwords, and to make each one unique.  [3] AVG’s blog suggested users “alternate letters, numbers, upper case, lower case.”  Jim Walter, manager of the McAfee Threat Intelligence Service, said “Today’s news of a possible LinkedIn hack is a good reminder to all internet users on the importance of maintaining an ever-changing and complex password.” [4]  After the breach, the blog “Krebs on Security” pointed readers to his primer on passwords. What advice was in that primer?  “Create unique passwords that use a combination of words, numbers, symbols, and both upper- and lower-case letters. […] Avoid using the same password at multiple Web sites.” [5]

It isn’t just a handful of lone security experts offering this advice.  Microsoft’s website has this advice regarding passwords:  “Use the entire keyboard”, “change them often”, “don’t use the same password for everything.” [6]  Don’t want to take advice from Microsoft?  Apple says the same thing:  “[Use] a combination of numbers, letters, and symbols”, “[Change] your password frequently”, “Avoid using the same password for multiple online accounts.” [7]

None of this advice is new.  In 1978, C. T. Dinardo wrote that “Obviously more frequent password changes are desirable”, and discussed the strength of passwords using pseudo-random strings of all allowable characters. [8]  So how is it that in the year 2012 four of the most frequently used passwords discovered in the LinkedIn breach were “1234”, “12345”, “123456”, and “1234567”? [9]

It’s because the traditional advice about passwords stinks.

As Randall Munroe points out in his XKCD comic strip, “Through 20 years of effort, we’ve successfully trained everyone to use passwords that are hard for humans to remember, but easy for computers to guess.” [10]

The fundamental problem is one of scale.  How many systems do you need to log in to?  I asked a few friends, and the consensus seems to be “about a dozen”.  I think that’s low.  Here are all of the systems for which I am supposed to have memorized a unique, complex password:

My school laptop
My home computer
My work laptop
My personal email
My bank’s online website
The website of my student loan provider
My credit card company’s website
Consumer Reports
My web host
The Carnegie Museum
The Nanowrimo website
My cell phone provider’s website
Tivo’s website
The official forums for the MMORPG
A guild website for the MMORPG
A second guild website for the MMORPG
The wiki for the MMORPG
An airline, to keep track of points
A friend’s blog
My local Toastmaster affiliate
The national Toastmaster organization
the HR system at work
My schema in the production environment of the database at work
The development environment of that database
The payroll website at work.
Our public library (which doesn’t allow consecutive numbers because they’re less random)
The ticket system for tracking tasks at work
An industry blog I follow for work
The main application I use at work
My family christmas blog
The Heinz thunderbolt server
The admin login for my local database on my school laptop
The website the annual conference of a vendor we use at my office
The website for another vendor at work, so I can download updates to their software
Oracle’s website/developer network
My undergrad alumni network website
My kid’s school dashboard
My internet service provider’s website
My credit card PIN
My cell phone’s voicemail
My office voicemail
Our Tivo (to escape the “kidzone”)
The code for our garage door opener

Almost all of those are in my head right now.  There are even more that I’ve completely forgotten, like uPromise, and GeoCities, and my Zen Photo installation, and some blog I had forgotten all about until they emailed me to tell me they were shutting down.  I can’t begin to count the number of online shops that have forced me to create a password just so I can buy one item, and then never shop there again.

That’s almost 50 passwords, even if you don’t count the PINs and voicemail codes.  And every single one of them is supposed to be unique.  They are all supposed to contain a mix of upper and lower case letters, with numbers and punctuation, with no dictionary words, no proper names, and no dates.  And I’m supposed to change every single one of them every few months, to something completely new and equally unguessable.  In a world where someone has memorized pi to 67,890 places perhaps memorizing all of those passwords is possible, but there must be a better option. [11]

The XKCD comic I mentioned has a suggestion:  use memorable pass phrases.  Despite the fact that common words are used, the resulting password is still very strong. Passphrases might work well for one site, but memorizing fifty different odd phrases every few months still sounds like an overwhelming mental challenge.

Another approach to creating and memorizing passwords is the algorithmic method.  My college roommate suggested starting with the name of the system for which you needed a password.  Remove all the vowels.  Count how many vowels you removed, and append the number to the end of the string of remaining consonants.  [12]  That may not be random enough to foil modern cybercriminals, but the idea could be extended to include punctuation and mixed case.

The result should be a strong password, which is unique for each site.  A problem arises when you want to change the passwords frequently.  You could choose a new algorithm every few months, or try to incorporate the date into your algorithm, but if our goal is to find an approach that can be used by the sort of people who think “12345” is an adequate password, then the algorithmic approach seems doomed.

Sometimes the best solution is the simplest:  don’t bother.  Most systems have a quick and simple procedure to reset a password by email.  Choose a very strong password for your email system and memorize that, then forget all of your other passwords.  Every time you want to log in, reset your password.  You can feel free to make all of your passwords extremely complex if you don’t have to worry about memorizing them.

Another simple solution is to write down all your passwords on a piece of paper.  The cybercriminals who broke into LinkedIn didn’t come over to your house and rifle through your desk drawers, did they?  In the world of network security, a piece of paper is marvelously secure.  No one can hack into it because it’s not on the network.  Of course, someone could steal the paper, but anyone with physical access to your work area can cause all sorts of problems, from installing a keylogger to stealing your hard drive.  It’s not a perfect solution, of course.  If someone does fine your piece of paper, all of your accounts will be utterly exposed.

A more sophisticated solution is to type all of your passwords into a computer file, and encrypt the file.  After the LinkedIn breach, Mike Newman, CEO of my1login, claimed that weak password schemes were the 2012 equivalent of leaving your housekey under the doormat.  His solution was to store all of your passwords online at his company’s website. [13]  There are other companies that offer the same service.  There is some irony in the idea of solving the problem of a data breach at one website by entrusting your passwords to another website.  Of course, Newman claims that his website is secure.  The problem is that any website which stores a large number of passwords will be an attractive target to crackers.  If companies like RSA and DigiNotar can be breached, it’s difficult to trust any web site.

Instead of keeping your encrypted password file on someone’s webserver, you could also keep it on your own computer.  If you have multiple computers, including mobile devices, you will need to keep the file on all of them, and synchronize the different versions.  This sounds inconvenient, but there is software written to help manage the chore.  In fact, the very first suggestion security expert Bruce Schneier offers regarding password security is “DO use a password manager.”  [14]

The classic advice to use different strong passwords on every site and change them frequently is impractical for modern users with many accounts.  Rather than repeating those same tired suggestions, users need to be better informed about password managers.

Since password security is critical to network security, the first step in solving the problem is to stop giving out impractical advice. The second is to find a solution that works.  Password managers might be that solution.









[8]  Author C. T. Dinardo, National Computer Conference.  AFIPS Press, 1978.  Page 139.
Title was “Computers and Security”?  Part of the series Information Technology Series v3.  “From the National Computer Conferences” is on the cover.




[12]  Conversation, Sendhil Mullainathan, discussion of passwords, Massachusetts, mid-1990s.



Is Password Security Broken? Yes… But Whose Fault Is It?

10 07 2012

Being a database administrator for a number of years, I dealt with many password issues on a daily basis. Not only passwords from an administrative standpoint, but also dealing with user password issues into the various systems I supported. Over the years, I have often asked my fellow employees (as well as family and friends) what they think of when they’re making up a new password. The general response I receive is an exasperated groan and a 15 minute tirade about how it’s “such a pain to keep track of all of those passwords” and “it’s okay to use the same password for everything because it would be really hard to guess.”

Passwords are our first line of defense to protect our private information, our social profiles, and in some cases our identities. So why do I get fired up when I find out someone has written their password on a Post-it® note under their keyboard? Why do I think that no password is secure enough? Because there are a variety of things that can break down the security of password protection such as weakness, carelessness, phishing, reuse, laziness, ignorance… I could go on but you get the idea. These issues not only plague users, but also the system owners (vendors) who are using passwords for authentication. These issues are just the beginning of the problem. Before I suggest how to fix password security and placing blame as to why it broke in the first place, let’s investigate a little more.

The Users…

To the average user, password security is an inconvenience. As we all know, when something is not fun to do, most people just don’t do it; or in the case of password security, they keep it to a minimum. Password reuse is, in my mind, one of the biggest issues of all time. As soon as one password is guessed, the attacked gains access to any number of systems with little or no additional effort. One study has found that password reuse can be as high as 50% among average users.[i] Password reuse is identified by using an identical or similar (same words different case or by changing a trailing digit) password for various systems.i

Additionally, most users may feel that their password is secure enough and very strict password policies are unnecessary.[ii] Despite a variety of websites that list various policies, most users see them as unnecessary. For instance, Microsoft lists some of the following best practices for users:[iii]

  • Use strong (i.e. complex) passwords. (Weakness)
  • If passwords must be written down, store them in a safe place. (Carelessness)
  • Never share passwords or type them in strange places. (Phishing)
  • Use a different password for every account. (Reuse)
  • Change passwords as soon as you suspect an attack. (Ignorance)
  • Having your computer “remember” your password is a security threat. (Laziness)

Even though these six tips are present to all users online (and in Windows help pages), how many of us follow ALL of them? If so, kudos to you… but is that even enough? Shouldn’t the vendors protect the users by making it easier and more secure at the same time?

The Vendors…

It is common knowledge that most systems and websites rely on password protection to authenticate users. In fact, there are so many different systems that each seems to have its own set of rules (and flaws). For example, Verizon’s password policy on their website states:

8-20 characters. At least 1 number and 1 letter. No spaces or special characters (*, #, &, etc.).[iv]

On the other hand, Comcast’s password policy states:

8-16 characters. At least one upper case letter, at least one lower case letter, and at least one number or special character (! @ # $ % ^ & *) are required. No spaces. Case-sensitive.[v]

So already, two common user accounts have different password policies. But why are the policies different? Are Comcast’s web developers smarter than Verizon’s and figured out how to pass special character to the database without error? Is Verizon’s system case sensitive even though it is not mentioned? Now take into account the myriad of account that any given user has. These minor differences quickly add to user frustration. Even by adding a capital letter and an “!” to the end of the password (Reuse), the user begins to have difficulty remembering which password has the special character, which one is case sensitive, and is tempted to begin keeping a password list (Carelessness).

Vendors have the ability to help users make good decisions when it comes to password security. While not all issues can be addressed, it’s a good start. For instance, Microsoft lists some of the following best practices for vendors:iii

  • Enforce password history policy. Don’t let users keep the same passwords. (Reuse)
  • Define the maximum password age policy setting so that passwords expire. (Laziness)
  • Define a minimum password length and complexity policy. (Weakness)

Vendors may think that good password practices are primarily the users’ responsibility. However, there are additional risks with password security behind the scenes. Vendors are also susceptible to attacks. What if I (as a vendor) didn’t follow the rules and my phished Gmail password was reused for my database account with DBA privileges. Someone with the skills could steal a lot of money from a lot of unsuspecting users. While details are still scarce, LinkedIn recently suffered a breach in their security and a number of user passwords were stolen.[vi] Even if all of the users followed password best practices, the attackers now have unlimited time to try to compare hashes of common passwords to gain access an account. Clearly, password security is everyone’s responsibility.

What Can We Do About It?

There are a variety of things that can be done. First of which should be the education of both users and vendors alike. Not just to preach password policies (that’s what got us in to this mess in the first place), but to get everyone on the same page. Rules need to be agreed upon that allow for an acceptable level of password complexity for everyone. For instance, if all vendors allowed for spaces and higher character limit in their passwords then easy to remember but difficult to guess passwords could be used. For instance: correct horse battery staple.[vii] I would even argue that a passphrase with numbers and punctuation would be even better: The 19 purple sock monkeys 8 my TV! Take into account the mixed case letters, spaces, numbers, punctuation, and general absurdity of the sentence and we have a winner. These types of passwords and pass phrases are not outside of the realm of vendors to implement, they’ve just been trained to think just like the users.

Additionally, tokens for two-step verification have been around for quite some time. With advances in technology there should be little keeping anyone from implementing a two-step verification process. Unfortunately, some RSA key fobs still cost anywhere from $50 to $120 each on That price is still a little much to give one to every person in the world; especially if a different one was required for each vendor. Now consider that over 35% of Americans carry smartphones in their pockets?[viii] If Google Authenticator works for all things Google, why can’t it (or something similar) work for a wider range of products? No additional cost aside from some minor royalties paid to the service provider. The technology is there, we just have to use it.

Let’s take it to the next level: reliable biometrics can’t be that far away. Even taking into account factors that make biometrics difficult on a day to day basis such as pattern variance, subject age, time frame, and even relative humidity they are still just about ready for main stream use.[ix] To bring existing technology into the mix, cell phones and laptops have successfully integrated fingerprint scanners into their construction. Even the sometimes gimmicky facial recognition techniques used on Android cell phones is improving.[x] Surely someone is ready to make a bit of money off of these capabilities by making them more ubiquitous?

Finally, there needs to be a voice for the users and vendors alike. They need to understand one another’s needs as well as difficulties. Perhaps the founding of an alliance is in order get these goals accomplished. Only time will tell (be sure to look for my email rallying you to my cause).

Whose Fault Is It… Really?

In conclusion I’ll ask again: Whose fault is it? It’s mine, yours, the vendors, and everyone else. I know that I have not been the best practitioner of password security – professionally or personally. Every time I see an article where a company loses thousands of user account to a hacker, I wonder how many people know their hashed passwords may have been taken. How many actually change it as soon as possible? Unfortunately, it sometimes takes a credible threat to get users and vendors to take password security seriously. However, it may already be too late to prevent the damage.

For a global society with so many computers, smartphones, and social networking accounts (over 1 billion and counting[xi]), we do not take security seriously enough. No, it’s not easy. It’s not meant to be. Don’t be at fault for being a victim. Know your responsibilities and understand what the vendors can (and cannot) do for you. Learn the rules of password safety but most of all, ask the vendors for help. A well-formed passphrase could save the day. Together, the users and vendors can make information security just a little better.

Passwords: How “strong” is strong enough, lessons learned from HBGary

11 02 2012

by Benjamin Dupont

In 2004, Bill Gates predicted that “ over time, people are going to rely less and less on passwords” [1]. Yet here we are in 2012 and passwords are still at the heart of security systems. As advocates of privacy, we should continue to embrace the use of passwords in our private lives as they offer a level of anonymity that biometric systems take away. But that’s a topic for a different day. The question I’d like to examine is how strong is strong enough?

What is a strong password?
Ideally, passwords would be extremely long and random. Since we have to remember them (and not write them down), we have to make use of less than optimal passwords. This is trivial information but it raises the issue of what is the required length and randomness of a password?

In [2] and [3], the authors argue that the strength of a password depends on the account; for example your password to access corporate resources or bank account vs the password used to access your kids PBS account [2]. Again, more trivial information.
Another question to consider is how often to change passwords. In [3], Schneier again argues that it depends what the password is protecting. And the value of the asset isn’t the only criteria: whether or not the attacker exposes the compromised account by “ using” the data is a more important criteria. For, example, money disappearing from a bank account is a good indication of a compromised account and changing the password would likely not have stopped the attack [3]. On the other hand, an attacker might use a compromised account to sniff quietly for information on a corporate network. In this case, changing passwords regularly might help. I realize, this is more trivial information, but somewhat less so.
Here’s a final piece of trivial information: don’t use the same passwords across sites, and especially don’t use a corporate password on your private sites.
This trivial information is important in understanding how the security firm HBGary was attacked [4]. Before we discuss the attack, a background on cracking passwords is required.

Compromising an Account: Attacking Passwords
Since passwords are here to stay, it’s important to understand how an attacker breaks passwords. There are two common modes of attacking a password: online and offline.
In an online attack, the attacker attempts to log into an account by guessing different passwords. This attack is circumvented by login delays and account lockout, both prevent guessing a large number of passwords. An attacker attempting an online break-in will likely utilize social engineering or a sniffer rather than randomly guessing passwords.
In an offline attack, the attacker has the password file and the passwords are presumably hashed. If you manage infrastructure that stores passwords, it’s vital that you understand how those passwords are stored. If you’re managing packaged software, it’s likely (hopefully) the vendor is aware of the following issues and has taken appropriate precautions, but if you have in house built systems, make sure stored passwords are adequately hashed.
With access to a password file, the attacker doesn’t have to worry about delays or getting locked out: the attacker can use whatever computing resources are available to aid in breaking the hashes. There are two main approaches to breaking hashes: brute force and rainbow tables.
In a brute force attack, the attacker uses a program to generate passwords. Each password is hashed and compared to the password file for a match. This is where strong passwords come into play: longer passwords with more variation will take longer to crack. Depending on the hash algorithm used, attackers have a more effective tool: rainbow tables.
Rainbow tables provide a time-memory tradeoff [5]. They’re essentially a lookup table for mapping known hashes to passwords. That is, given a hash, a rainbow table will provide the corresponding password in a matter minutes. There are a couple of well known tools that use rainbow tables that will help you recover lost passwords on windows machines, including Ophcrack [6].  By the way, if you’ve never used Ophcrack, I highly recommend you download it and try it on a home computer.
Rainbows tables are easy to defeat. Rainbow tables can’t be all encompassing; they can’t account for every password length with every possible character, and every different type of hash. System designers can defeat hash tables by requiring passwords longer than generated rainbow tables, AND apply salt to the hash. Hashing multiple times is another technique but it’s not as effective as using salt.
Using the salt technique was useful even before the realization of rainbow tables. Each password has it’s own random salt and the salt is stored with the password. With a random salt applied to each password, an attacker must generate a new hash for every account in the password file. Furthermore, the combination of a large enough salt plus password should create a hash that’s not in any available rainbow table. And the table required to hold such a hash would be too large and take too long to generate.

How Did HBGary Fail? Let me count the ways…
We now have enough history to understand the attack on the security firm HBGary. What follows are highlights of [4].
The HBGary website used a little known CMS system which hasn’t been weathered like other popular systems. The attackers exploited a flaw in the CMS which allowed them to obtain a list of hashed passwords. If you followed the first two sections on picking strong passwords and using salt when hashing passwords, you probably have a good idea of what happened next.
The CMS hashed passwords with a known weak hash function, they didn’t salt the hashes, and some of the users had relatively weak passwords. This allowed the attackers to use an existing rainbow table to crack the hashes. But that isn’t where the issues stop.
Normally, when security professionals warn against using the same passwords at home and work, the idea is a compromised personal account shouldn’t lead to a compromised corporate account. The opposite happened at HBGary: compromised corporate accounts provided access to personal e-mail, Twitter, and LinkedIn accounts.  I found this rather amusing.
The article outlines a number of exploits the attackers performed as they made their way through the HBGary network. We’ve heard the adage that systems should be built in layers; a system should not be hard on the outside and soft on the inside. This system appears to be soft inside and out. HBGary is (was?) a security firm that offers services such as secure networking and penetration testing. How could they get these simple points so wrong?

How Long Do Passwords Need to Be?
For your personal accounts, chances are, you only need to worry about online, automated attacks. Choose a password that would be difficult to guess for someone that knows you, and you’ll likely be safe. In other words, don’t use birthday’s, children’s names, pet’s names, etc. In the event that a list of passwords is compromised, hopefully the provider has taken necessary precautions to protect against offline attacks.
What I’m basically stating is that passwords to our personal accounts are relatively safe. There are more important things to protect like financial and personal data. What safeguards are companies like Facebook and Google implementing? I believe encrypting credit card data is standard practice but personal data is likely stored in the clear. That information is likely more valuable to an attacker than the login to my Facebook page.

[1] CNET News, February 25, 2004, Gates predicts death of password,
[2] Wired, January 12, 2012, Do You Really Need a Password You can Barely Remember?,
[3] Schneier on Security, November 11, 2010, Changing Passwords,
[4] Arstehnica, February 2011, Anonymous speaks: the inside story of the HBGary hack,
[5], FAQ,

Protect Passwords From Being Hacked

2 10 2011

Hacking passwords can be simpler than you would think if your password is not strong enough. It all comes down to trying to guess the password over and over again. It is a matter of time before the guess turns out to be your password.

The common method of cracking a password includes guessing what a person is most likely to use as his or her password. This would entail a bit of knowledge about the person, like name, address, phone number, partner’s name, date of birth, etc. And as it turns out this background information is not that difficult to find out. There are numerous websites on the internet that let you search for a person’s background information. Some of them are free, some charge a monthly fee. (

Once you have a person’s background information you can start guessing the person’s password: the person’s date of birth, his or her partner’s name followed by a number (usually 0 or 1), the person’s social security number, the person’s favorite sports team, the person’s place of birth etc. or a combination of one or more of the above.

If the person’s password is not related to any of the above, there are other ways to get even more information about a person. Usually, people use the same password for multiple sites. Different sites have different level of security. A banking site may have very high security but a forum site the person usually visits or an online shopping site may not have the same level of security. A hacker can use the brute force attack on one of these sites and crack your username and password.

If the hacker has the password for one site, they can very likely use that password on other sites. This is because people usually use the same password for multiple sites because they find having multiple passwords cumbersome. Or a person can be using slightly modified versions of the same password on different sites. This means the hacker by finding out the password for one site has narrowed down the search for passwords for other sites.

Of course, a hacker will not manually guess all of this; he or she will use a fast computer and software to guess the password. So how fast can a computer guess a password using brute force and dictionary attacks? It depends on the length of the password and content of the password (whether the password is a combination of all the letters and characters on the key board or if it is just made up of lower case letters.)

The below table shows how fast a reasonably fast PC can guess a password depending on the password’s characteristics.

Password Length

All Characters

Only Lowercase

3 characters
4 characters
5 characters
6 characters
7 characters
8 characters
9 characters
10 characters
11 characters
12 characters
13 characters
14 characters

0.86 seconds
1.36 minutes
2.15 hours
8.51 days
2.21 years
2.10 centuries
20 millennia
1,899 millennia
180,365 millennia
17,184,705 millennia
1,627,797,068 millennia
154,640,721,434 millennia

0.02 seconds
.046 seconds
11.9 seconds
5.15 minutes
2.23 hours
2.42 days
2.07 months
4.48 years
1.16 centuries
3.03 millennia
78.7 millennia
2,046 millennia


So how do you protect your password from being compromised? Some tips that can be followed when choosing a password are: Make sure you have uppercase letters at random positions in your password. Always have special characters in your password. Always have different passwords for different sites. Never write down your passwords. Instead you can use software like Roboform ( that will store all your passwords in an encrypted form.

Another tip for protecting your password from hackers who may use the “forgot password” option in websites to hack your password: always setup a wrong answer for the password recovery question. For example, if the question is “What is your place of birth?” make sure the answer you set up is not actually the place of your birth!

Is Token Based 2-Factor Authentication Really That Secure?

15 09 2011

When I told my bank that I wanted to use internet banking, they gave me along with my welcome package, a pocket-sized hardware device consisting of a small display and button. Each time I pressed the button, numbers would come up on the display. Every few seconds, a new number came up. To log on to the internet banking website, I had to key in my userid, password and the number displayed on the hardware device.

This was one of the most popular ways for 2-factor authentication (2FA). The hardware device, which was called a token would continuously generate new numbers. As such, even if a hacker were to get hold of my userid and password, he/she would not be able to access my account without access to my hardware device; the numbers changed so frequently that it was impossible for a hacker to guess those numbers. I was told that this was the ultimate protection against any security threats.

If only it was so simple. On March 17, 2011, RSA announced that there was a successful attack on its systems which caused the compromise of its RSA SecurID 2FA products [1]. RSA downplayed the significance of that attack, and wrote that the incident “does not enable a successful direct attack on any of our RSA SecurID customers” [1].

Unfortunately, that was not the case. On June 2, 2011, RSA confirmed that the information taken from the attack in March had been used for an attempted attack on Lockheed Martin [2]. In fact, it was confirmed that the attackers duplicated Lockheed’s SecurID tokens using the data stolen from RSA [3]. The actual details of what happened and how the compromise occurred was not released, and may well never be known. After the attack, RSA offered to replace SecurID tokens “for customers with concentrated user bases” [2]. For other companies who do not meet these criteria, the SecurID tokens which they continue to use with its compromised security might again be exploited by an attacker in the future.

The problem lies not so much with the attack on RSA as it is with the vulnerability of the token-based system. Each token comes with an embedded seed which is linked to a unique serial number. The seed is then combined with the current time through the use of an algorithm to produce a rotating code [4]. This method is used by almost all tokens today. At the back-end server, the serial number of all the tokens issued is stored, along with the seed pairs. The same algorithm on the back-end server is applied to get the same rotating code. So each time the user logs onto the system, the rotating code generated by the token is matched with the rotating code generated by the back-end server.

The main security threat is for an attacker to get the serial number and seed pairs of the issued tokens, which was likely what happened in RSA’s case. The algorithm to generate the code from the seed would likely be easily available, based on Kerckhoffs’ principle of making the algorithm public. As such, an attacker could just generate the rotating code without needing access to the token. There is a single point of failure; the attacker which can hack the back-end server would have access to all the seed pairs, compromising the security of the millions of tokens that were issued.

In conclusion, I have no doubt that adding a token-based authentication mechanism to implement 2FA adds to the standard level of userid and password kind of security. What I am saying is that it may not be the ultimate form of security after all and should still be implemented with other security measures – like the need for strong passwords, proper auditing and controls. This is especially so when such token based 2FA systems are used in highly sensitive situations such as internet banking, access to corporate VPNs and confidential systems.

[1] Coviello, A. W. (2011). Open letter to RSA Customers. Retrieved from

[2] Coviello, A. W. (2011). Open letter to RSA SecurID Customers. Retrieved from

[3] Hall, J. (2011). The RSA SecurD Compromise: Analysis & Response. Retrieved from

[4] Jarmoc, J. (2011). RSA compromise: Impacts on SecurID. Retrieved from