Archive for June, 2013

I’ve posted a video of the full presentation I gave in Munich earlier this year on social media threats but now if you want the abbreviated format, please join me at Hacker Hotshots on Thursday, July 18, at noon (EDT) for a short web cast.

Here’s a link to the web site where you can register:

http://www.concise-courses.com/infosec/20130718/#

I got a question recently from Tyler Dukes at the Raleigh News & Observer related to work on the “Stump the Geeks” column. A reader had developed his own, rather elaborate scheme for assigning unique passwords for each web site (a laudable goal). Here’s what he wrote:

Q. I’ve developed a method for creating IDs and passwords so I can store them without any encryption or hacking worries. I do the following:

1. I always use a base user ID such as MYUSERIDn and password as MYPASSWORDnn.

2. I simply change the “n” to any number for the ID and the “nn” to any number for the password.

3. Now I can store a Web site ID and password as, for example, “Macy’s 522.”

Say Macy’s wants me to set up a user ID and password. I would create my ID as MYUSERID5 and my password as MYPASSWORD22. Now I can bookmark the Macy’s Web site described as “Macy’s 522.” If you don’t know my basic structure, the “522” means nothing. My actual IDs and passwords are more complex than this example, but the concept is the same.

Am I lulling myself into a false sense of security, or is this scheme a viable solution?

The short answer is “yes.” Nice try but there are some problems with this approach. 

The article in the paper summarized some of the issues but I thought I would go ahead and put out my full answer here…

The password scheme described is certainly better than using the same password for every system but not really something I would feel comfortable hanging my hat on. First of all, since only alphabetic and numeric characters are used, the number of possibilities an attacker would have to try in a brute force attack (i.e. trying all possible password combinations) is not nearly as large it would be if special characters like (e.g. *, &, !, %, $) and mixed case alphas were used. Also, the length of the password is not so long that an attack couldn’t be successfully completed in a reasonable amount of time. The key to better security with passwords is complexity. Ideally, you want randomness created by a mixture of cases, alphas, numerics and special characters. These should also change every few months and not be reused on other system. Any scheme that you reuse also runs the risk that if someone discovers your password on one system that they might be able to infer what it would be on others.


Of course, the problem with doing what I just recommended above in terms of password complexity is that, in general, making a password hard to guess, also makes it hard to remember. Rather than writing passwords down, which introduces yet further risks, it’s best to either use a password storage “vault” or, better still, a single sign-on tool that combines the vault with a capability to automatically enter the password for you. With this sort of software all you need to do is keep up with one complex password (rather than many) and then the program does the heavy lifting of generating strong, unique, random passwords that you never even have to know.

Finally, for even better security, a second mechanism can be added to the password (“something you know”). In this case you would also be challenged to prove that you have some unique device in your possession (“something you have”) or some physical characteristic unique to you (“something you are”). The latter involves biometrics such as fingerprints, retinal scans, voice recognition and the like. The former is perhaps more practical in many cases if the thing you “have” is something you are likely to keep with you most of the time anyway, such as a cell phone. This sort of two-factor authentication would involve logging in with your userid and password as always and then you might face a second challenge such as entering a one time PIN that has been sent as a text message to your phone or entering a temporary password that his been generated by an app on the phone. Google, Facebook and others offer this sort of scheme. Twitter, at this point, does not, although there are reports that this capability will be coming in the not too distant future. When it does, I would recommend that this option be considered since it could have prevented the sort of situation that has been see with a number of high profile Twitter feeds.

Since the time I wrote that Twitter has, indeed, come out with a two-factor authentication scheme — a welcome and long overdue enhancement. It’s not perfect but it is an improvement. If you use Twitter, you might want to take a look.