Now One Week All Year

The annual summer conference constellation of the week of Black Hat, BSides, and DEF CON usually brings out a certain vocal concern about personal device security. Some of the concern is grounded in wry humor, using mirth to illustrate a point. Some of it floats on ignorance tainted with misapplied knowledge. That’s fine. Perform the rituals and incantations that make you feel better. Enjoy the conferences, have fun, share some knowledge, learn some skills.

But after you select a level of extra precaution. Ask why such a choice is necessary for one week of the year. It’s a question without a single answer. As a leading question, it’s intended to elicit reasons based on a coherent threat model that addresses the week’s anticipated behaviors and environments. As an antagonistic question, it’s intended to explore why “default secure” is insufficient or why, after more than two decades of one-week-a-year concern, system and device security is so poor that none of it can be trusted outside your home network.

As you ponder an answer, take a moment to help someone else improve their baseline security profile.

  • For a mobile device, set a passcode longer than four characters.
  • For a mobile device, enable Touch ID or similar biometric feature.
  • Turn on automatic updates.
  • Enable multi-factor authentication (MFA, 2FA, Security Key, App Authenticator, or whatever synonym it supports) for their email, social media, and financial accounts.
  • Record and save recovery codes associated with enabling MFA. Help them choose an effective storage, such as printed and placed somewhere safe or in a password-protected keychain.

As a follow-up to enabling MFA, help them update and make unique each of their passwords.

  • Install a password manager.
  • Starting with their most-used sites, go through the password change process and allow the password manager to assign a new, unique password. If they wish to have a memorable password, ensure that it’s only used for that account.
  • Review any OAuth or Social Logins used for the account, e.g. if they use Facebook, Twitter, LinkedIn, or similar to authenticate to the site or to allow access to their social account.

Now consider that there are people whose security precautions require attention 52 weeks of the year. People who have expressed an opinion. People who are women. People in abusive relationships. People without political representation, let alone power. These are different situations that need different approaches to securing devices and data.

These are people who can’t buy a “burner phone” for one week, then return to normal. Their normal isn’t the vague threat of a hostile network. It’s the direct threat from hostile actors — those with physical access to their devices, or maybe just knowledge of their passwords, or possibly just knowledge of their existence. But in each case an actor or actors who desire to obtain access to their identity, data, and accounts.

After helping someone with the basic security hygiene of setting strong passwords and turning on automatic updates, gather resources for how to deal with different threat models and different levels of concern. Help them translate those concerns into ways of protecting accounts and data.

One resource to start with could be https://onlinesafety.feministfrequency.com/.

There’s a trope in infosec that this week has “the most hostile network” ever. A network may indeed be hostile, but a hostile playground network is far different from the threats against a network people use on a daily basis.

It can be fun as well as a great educational experience to attack a playground network. On the other hand, networks that no one can use or be expected to use aren’t reflective of security engineering. If you think a network can never be secured or a device never be safe, then you’ve possibly skipped over the exercise of threat modeling and making choices based on risk.

Audit Accounts, Partition Passwords, Stay Secure

It’s a new year, so it’s time to start counting days until we hear about the first database breach of 2014 to reveal a few million passwords. Before that inevitable compromise happens, take the time to clean up your web accounts and passwords. Don’t be a prisoner of bad habits.

It’s good Operations Security (OpSec) to avoid password reuse across your accounts. Partition your password choices so that each account on each web site uses a distinct value. This prevents an attacker who compromises one password (hashed or otherwise) from jumping to another account that uses the same credentials.
Penny-Farthing
At the very least, your email, Facebook, and Twitter accounts should have different passwords. Protecting email is especially important because so many sites rely on it for password resets.

And if you’re still using the password kar120c I salute your sci-fi dedication, but pity your password creation skills.

Start with a list of all the sites for which you have an account. In order to make this easier to review in the future, create a specific bookmarks folder for these in your browser.

Each account should have a unique password. The latest Safari, for example, can suggest these for you.

Next, consider improving account security through the following steps.

Consider Using OAuth — Passwords vs. Privacy

Many sites now support OAuth for managing authentication. Essentially, OAuth is a protocol in which a site asks a provider (like Facebook or Twitter) to verify a user’s identity without having to reveal that user’s password to the inquiring site. This way, the site can create user accounts without having to store passwords. Instead, the site ties your identity to a token that the provider verifies. You prove your identify to Facebook (with a password) and Facebook proves to the site that you are who you claim to be.

If a site allows you to migrate an existing account from a password-based authentication scheme to an OAuth-based one, make the switch. Otherwise, keep this option in mind whenever you create an account in the future.

But there’s a catch. A few, actually. OAuth shifts a site’s security burden from password management to token management and correct protocol implementation. It also introduces privacy considerations related to centralizing auth to a provider as well as how much providers share data.

Be wary about how sites mix authentication and authorization. Too many sites ask for access to your data in exchange for using something like Facebook Connect. Under OAuth, the site can assume your identity to the degree you’ve authorized, from reading your list of friends to posting status updates on your behalf.

Grant the minimum permissions whenever a site requests access (i.e. authorization) to your data. Weigh this decision against your desired level of privacy and security. For example, a site or mobile app might insist on access to your full contacts list or the ability to send Tweets. If this is too much for you, then forego OAuth and set up a password-based account.

(The complexity of OAuth has many implications for users and site developers. We’ll return to this topic in future articles.)

Two-Factor Auth — One Equation in Two Unknowns

Many sites now support two-factor auth for supplementing your password with a temporary passcode. Use it. This means that access to your account is contingent on both knowing a shared secret (the password you’ve given the site) and being able to generate a temporary code.

Your password should be known only to you because that’s how you prove your identity. Anyone who knows that password — whether it’s been shared or stolen — can use it to assume your identity within that account.

A second factor is intended to be a stronger proof of your identity by tying it to something more unique to you, such as a smartphone. For example, a site may send a temporary passcode via text message or rely on a dedicated app to generate one. (Such an app must already have been synchronized with the site; it’s another example of a shared secret.) In either case, you’re proving that you have access to the smartphone tied to the account. Ideally, no one else is able to receive those text messages or generate the same sequence of passcodes.

The limited lifespan of a passcode is intended to reduce the window of opportunity for brute force attacks. Imagine an attacker knows the account’s static password. There’s nothing to prevent them from guessing a six-digit passcode. However, they only have a few minutes to guess one correct value out of a million. When the passcode changes, the attacker has to throw away all previous guesses and start the brute force anew.

The two factor auth concept is typically summarized as the combination of “something you know” with “something you possess”. It really boils down to combining “something easy to share” with “something hard to share”.

Beware Password Recovery — It’s Like Shouting Secret in a Crowded Theater

If you’ve forgotten your password, use the site’s password reset mechanism. And cross your fingers that the account recovery process is secure. If an attacker can successfully exploit this mechanism, then it doesn’t matter how well-chosen your password was (or possibly even if you’re relying on two-factor auth).

If the site emails you your original password, then the site is insecure and its developers are incompetent. It implies the password has not even been hashed.

If the site relies on security questions, consider creating unique answers for each site. This means you’ll have to remember dozens of question/response pairs. Make sure to encrypt this list with something like the OS X Keychain.

Review Your OAuth Grants

For sites you use as OAuth providers (like Facebook, Twitter, Linkedin, Google+, etc.), review the third-party apps to which you’ve granted access. You should recognize the sites that you’ve just gone through a password refresh for. Delete all the others.

Where possible, reduce permissions to a minimum. You’re relying on this for authentication, not information leakage.

Use HTTPS

Universal adoption of HTTPS remains elusive. Fortunately, sites like Facebook and Twitter have set this by default. If the site has an option to force HTTPS, use it. After all, if you’re going to rely on these sites for OAuth, then the security of these accounts becomes paramount.

Maintain Constant Vigilance

Watch out for fake OAuth prompts, such as windows that spoof Facebook and Twitter.
Keep your browser secure.
Keep your system up to date.
Set a reminder to go through this all over again a year from now — if not earlier.

Otherwise, you risk losing more than one account should your password be exposed among the millions. You are not a number, you’re a human being.

Oh, the Secrets You’ll Know

Beware of [hash]CatOh, the secrets you’ll know if to GitHub you go. The phrases committed by coders exhibited a mistaken sense of security.

A password ensures, while its secrecy endures, a measure of proven identity.

Share that short phrase for the public to gaze at repositories open and clear. Then don’t be surprised at the attacker disguised with the secrets you thought were unknown.

*sigh*

It’s no secret that I gave a BlackHat presentation a few weeks ago. It’s no secret that the CSRF countermeasure we proposed avoids nonces, random numbers, and secrets. It’s no secret that GitHub is a repository of secrets.

And that’s how I got side-tracked for two days hunting secrets on GitHub when I should have been working on slides.

Your Secret

Security that relies on secrets (like passwords) fundamentally relies on the preservation of that secret. There’s no hidden wisdom behind that truism, no subtle paradox to grant it the standing of a koan. It’s a simple statement too often ignored, bent, and otherwise abused.

It started with research on examples of CSRF token implementations. But the hunt soon diverged from queries for connect.sid to tokens like OAUTH_CONSUMER_SECRET, to ssh:// and mongodb:// schemes. Such beasts of the wild had been noticed before; they tend to roam with little hindrance.

connect.sid extension:js

Sometimes these beasts leap from cover into the territory of plaintext. Sometimes they remain camouflaged behind hashes and ciphers. Crypto functions conceal the nature of a beast, but the patient hunter will be able to discover it given time.

The mechanisms used to protect secrets, such as encryption and hash functions, are intended to maximize an attacker’s effort at trying to reverse-engineer the secret. The choice of hash function has no appreciable effect on a dictionary-based brute force attack (at least not until your dictionary or a hybrid-based approach reaches the size of the target keyspace). In the long run of an exhaustive brute force search, a “bigger” hash like SHA-512 would take longer than SHA-256 or MD5. But that’s not the smart way to increase the attacker’s work factor.

Iterated hashing techniques are more effective at increasing the attacker’s work factor. Such techniques have a tunable property that may be adjusted with regard to the expected cracking speeds of an attacker. For example, in the PBKDF2 algorithm, both the HMAC algorithm and number of rounds can be changed, so an HMAC-SHA1 could be replaced by HMAC-SHA256 and 1,000 rounds could be increased to 10,000. (The changes would not be compatible with each other, so you would still need a migration plan when moving from one setting to another.)

Of course, the choice of work factor must be balanced with a value you’re willing to encumber the site with. The number of “nonce” events for something like CSRF is far more frequent than the number of “hash” events for authentication. For example, a user may authenticate once in a one-hour period, but visit dozens of pages during that same time.

Our Secret

But none of that matters if you’re relying on a secret that’s easy to guess, like default passwords. And it doesn’t matter if you’ve chosen a nice, long passphrase that doesn’t appear in any dictionary if you’ve checked that password into a public source code repository.

In honor of the password cracking chapter of the upcoming AHT 4th Edition, we’ll briefly cover how to guess HMAC values.

We’ll use the Connect JavaScript library for Node.js as a target for this guesswork. It contains a CSRF countermeasure that relies on nonces generated via an HMAC. This doesn’t mean Connect.js implements the HMAC algorithm incorrectly or contains a design error; it just means that the security of an HMAC relies on the secrecy of its password. Developers should know this.

Here’s a snippet of the Connect.js code in action. Note the default secret, ‘keyboard cat’.

...
var app = connect()
  .use(connect.cookieParser())
  .use(connect.session({ secret: 'keyboard cat' }))
  .use(connect.bodyParser())
  .use(connect.csrf())
...

If you come across a web app that sets a connect.sess or connect.sid cookie, then it’s likely to have been created by this library. And it’s just as likely to be using a bad password for the HMAC. Let’s put that to the test with the following cookies.

Set-Cookie: connect.sess=s%3AGY4Xp1AWB5PVzYHCANaXHznO.PUvao3Y6%2FXxLAG%2Bp4xQEBAcbqMCJPACQUvS2WCfsmKU; Path=/; Expires=Fri, 28 Jun 2013 23:13:52 GMT; HttpOnly
Set-Cookie: connect.sid=s%3ATdF%2FriiKHfdilCTc4W5uAAhy.qTtH9ZL5pxgClGbZ0I0E3efJTrdC0jia6YxFh3cWKrU; path=/; expires=Fri, 28 Jun 2013 22:51:58 GMT; httpOnly
Set-Cookie: connect.sid=CJVZnS56R6NY8kenBhhIOq0h.0opeJzAPZ3efz0dw5YJrGqVv4Fi%2BWVIThEsGHMRqDw0; Path=/; HttpOnly

Everyone’s Secret

John the Ripper is a venerable password guessing tool with ancient roots in the security community. Its rule-based guessing techniques and speed make it a powerful tool for cracking passwords. In this case, we’re just interested in its ability to target the HMAC-SHA256 algorithm.

First, we need to reformat the cookies into a string that John recognizes. For these cookies, resolve the percent-encoded characters, replace the dot (.) with a hash (#). (Some of the cookies contained a JSON-encoded version of the session value, others contained only the session value.)

GY4Xp1AWB5PVzYHCANaXHznO#3d4bdaa3763afd7c4b006fa9e3140404071ba8c0893c009052f4b65827ec98a5
TdF/riiKHfdilCTc4W5uAAhy#a93b47f592f9a718029466d9d08d04dde7c94eb742d2389ae98c458777162ab5
CJVZnS56R6NY8kenBhhIOq0h#d28a5e27300f67779fcf4770e5826b1aa56fe058be595213844b061cc46a0f0d

Next, we unleash John against it. The first step might use a dictionary, such as a words.txt file you might have laying around. (The book covers more techniques and clever use of rules to target password patterns. John’s own documentation can also get you started.)
$ ./john --format=hmac-sha256 --wordlist=words.txt sids.john

Review your successes with the --show option.
$ ./john --show sids.john

Hashcat is another password guessing tool. It takes advantage of GPU processors to emphasize rate of guesses. It requires a slightly different format for the HMAC-256 input file. The order of the password and salt is reversed from John, and it requires a colon separator.

3d4bdaa3763afd7c4b006fa9e3140404071ba8c0893c009052f4b65827ec98a5:GY4Xp1AWB5PVzYHCANaXHznO
a93b47f592f9a718029466d9d08d04dde7c94eb742d2389ae98c458777162ab5:TdF/riiKHfdilCTc4W5uAAhy
d28a5e27300f67779fcf4770e5826b1aa56fe058be595213844b061cc46a0f0d:CJVZnS56R6NY8kenBhhIOq0h

Hashcat uses numeric references to the algorithms it supports. The following command runs a dictionary attack against hash algorithm 1450, which is HMAC-SHA256.
$ ./hashcat-cli64.app -a 0 -m 1450 sids.hashcat words.txt

Review your successes with the --show option.
$ ./hashcat-cli64.app --show -a 0 -m 1450 sids.hashcat words.txt

Hold on! There’s movement in the brush. Let me check what beastie lurks there. I’ll be right back…

Condign Punishment

The article rate here slowed down in February due to my preparation for B-Sides SF and RSA 2013. I even had to give a brief presentation about Hacking Web Apps at my company’s booth. (Followed by a successful book signing. Thank you!)

Gladius

In that presentation I riffed off several topics repeated throughout this site. One topic was the mass hysteria we are forced to suffer from web sites that refuse to write safe SQL statements.

Those of you who are developers may already be familiar with a SQL-related API, though some may not be aware that the acronym stands for Advanced Persistent Ignorance.

Here’s a slide I used in the presentation (slide 13 of 29). Since I didn’t have enough time to complete nine years of research I left blanks for the audience to fill in.

Advanced Persistent Ignorance

Now you can fill in the last line. Security company Bit9 admitted last week to a compromise that was led by a SQL injection exploit. Sigh. The good news was that no massive database of usernames and passwords (hashed or not) went walkabout. The bad news was that attackers were able to digitally sign malware with a stolen Bit9 code-signing certificates.

I don’t know what I’ll add as a fill-in-the-blank for 2014. Maybe an entry for NoSQL. After all, developers love to reuse an API. String concatenation in JavaScript is no better that doing the same for SQL.

If we can’t learn from PHP’s history in this millennium, perhaps we can look further back for more fundamental lessons. The Greek historian Polybius noted how Romans protected passwords (watchwords) in his work, Histories1:

To secure the passing round of the watchword for the night the following course is followed. One man is selected from the tenth maniple, which, in the case both of cavalry and infantry, is quartered at the ends of the road between the tents; this man is relieved from guard-duty and appears each day about sunset at the tent of the Tribune on duty, takes the tessera or wooden tablet on which the watchword is inscribed, and returns to his own maniple and delivers the wooden tablet and watchword in the presence of witnesses to the chief officer of the maniple next his own; he in the same way to the officer of the next, and so on, until it arrives at the first maniple stationed next the Tribunes. These men are obliged to deliver the tablet (tessera) to the Tribunes before dark.

More importantly, the Romans included a consequence for violating the security of this process:

If they are all handed in, the Tribune knows that the watchword has been delivered to all, and has passed through all the ranks back to his hands: but if any one is missing, he at once investigates the matter; for he knows by the marks on the tablets from which division of the army the tablet has not appeared; and the man who is discovered to be responsible for its non-appearance is visited with condign punishment.

We truly need a fitting penalty for SQL injection vulnerabilities; perhaps only tempered by the judicious use of salted, hashed passwords.

=====
1 Polybius, Histories, trans. Evelyn S. Shuckburgh (London, New York: Macmillan, 1889), Perseus Digital Library. http://data.perseus.org/citations/urn:cts:greekLit:tlg0543.tlg001.perseus-eng1:6.34 (accessed March 5, 2013).

Don’t Rub Salt in Your Wounds

By now everyone’s downloaded a copy of John the Ripper and taken a crack (ahem) at the LinkedIn password file. The wordlists, whatever their provenance or size, likely ran out in a matter of minutes. That left unsophisticated users with the unending silence of incremental mode compounded with the challenge of figuring out how to tease incremental mode into making guesses longer than eight characters.

On the other hand, a cunning cracker might think for a moment about users’ psychology. We all have passwords. We’ve all heard that passwords should be long, preferably longer than eight characters (to the disappointment of crackers who can’t figure out CHARSET_LENGTH and the –make-charset option), and these super passwords shouldn’t just be letters. I already went through one counterpoint to relying on users to follow this advice. Here’s another.

LinkedIn has already been lambasted for not salting passwords. Salting would not have increased the work factor for attackers (the time difference between cracking salted vs. unsalted passwords isn’t significant). Instead, salting would have protected users who had chosen short passwords because it would have defeated precomputation attacks — the pleasantly named “rainbow table” attack. A hacker who started building a rainbow table in 2000 would have a nice collection of precomputed password hashes for most complex passwords up to eight characters. All that’s needed is to look up a pre-calculated hash and reference the password that generated it. The sha1 of “MyP4$$w0rd” is always 8300de9d93a7bd03edce1e73ede3bbfe7fc7c714. The hacker only needed to crack that hash once. The hacker builds a dictionary of hashes for passwords based on movies, songs, etc. Including simple passwords like “12345”.

Salts come to the (meager) rescue for the poor sap who chose “12345”. Adding a long salt changes the original hash from 8cb2237d0679ca88db6464eac60da96345513964 to 99483607e3ee3891208749a372cbff883b5bc652. Whereas the hacker’s rainbow table surely had an entry for the first …3964 hash it’s equally unlikely that the rainbow table has an entry for the second …c652 version even though the user’s password remains “12345”. The presence of a salt erases all of that preparatory work, thereby forcing the hacker to fire up the CPUs for some old-fashioned brute force.

While the salt defeats the rainbow table it isn’t a defense against brute force. If the password list is compromised, then it’s safe to assume the salt is going to be exposed as well. So, if the salt in our example is exposed as “alongsalt” then the time to brute force a password of “alongsalt12345” does not change in comparison to attacking the same password without a salt. The password would be lucky to last a few minutes in either case.

Humans like patterns. Ever since we descended from the trees (well, real humans did; the explanations based on some magic-sky-dude are kinda fuzzy, but I digress as usual) humans became creatures of habit.

Passwords are no different. Exhibit A) Users chronically select poor passwords; exhibit B) Users are constantly encouraged to create long passwords; exhibit C) LinkedIn was hacked. Do you concur?

Which brings us to the bad habit of salting yourself. Or more accurately, using poor entropy to extend a password’s length. It’s easy to turn a short password like “12345” into a longer password by including the web domain, e.g. “linkedin12345” — woohoo! 13 characters! And an entirely predictable password scheme for an account on a site called “LinkedIn”. The mixed-case version, “LinkedIn12345”, fares no better.

On Wednesday I took the time to manually guess some passwords based on pop-culture topics. I have a nice, long .bash_history file to prove it. Today it was time to polish off my JtR memory to play with password schemes. As always, efficiency (a.k.a. laziness) rules the day. The first step was to look for users who chose to improve their password by adding the word, “linkedin”. John the Ripper’s rule mechanism makes this easy. Take a word list and add a word to the beginning or end of each entry.

[List.Rules:LinkedIn]
-: A0"linkedin"
-: Az"linkedin"

Bunch of hits right off the bat. But remember that laziness rule? We could enumerate the different case combinations and number-vowel substitution with more A0 and Az rules. Or we could use the ^, $, and grouping operators. In six lines of JtR rules we’ve extended the word list to hit some fun combinations.

[List.Rules:LinkedIn]
# linkedin
-: ^[nN]^[iI1]^[dD]^[eE3]^[kK]^[nN]^[iI1]^[lL]
-: $[nN]$[iI1]$[dD]$[eE3]$[kK]$[nN]$[iI1]$[lL]
# nideknil (linkedin reversed)
-: ^[lL]^[iI1]^[nN]^[kK]^[eE3]^[dD]^[iI1]^[nN]
-: $[lL]$[iI1]$[nN]$[kK]$[eE3]$[dD]$[iI1]$[nN]
# number|@ -> linkedin or linkedin -> number|@
-: ^[nN]^[iI1]^[dD]^[eE3]^[kK]^[nN]^[iI1]^[lL]^[0-9@]
-: ^[0-9@]^[nN]^[iI1]^[dD]^[eE3]^[kK]^[nN]^[iI1]^[lL]

Suddenly, it becomes clear that users are terrible creatures of habit. My favorite so far? 6af6ebbbea6a2c20f25fd84c9933a8d6ef908c20.

There’s one positive aspect here in that it’s extremely likely that each linkedin-variant password is only used for LinkedIn accounts. But that’s bad news if hackers go after those accounts with domain-style password schemes on other sites.

The message here is that passwords should be a surprise. Yes, normally “L1nk3d1n” would be a good start to a long password, except for the correlation with the site’s domain name. The predictable component only adds about nine bits of entropy to the password rather than the expected 48 bits from an eight-character alphanumeric mix.

I’ll expand on the surprise principle in an upcoming post. Good password advice requires more explanation than four bullet points — the majority of passwords found by the custom JtR rules would have satisfied what turns out to be empty advice if you don’t understand the underlying reasons.

Finally, LinkedIn shouldn’t just be salting the password, they should be applying an algorithm like PBKDF2 to increase hackers’ work factor required to crack a password. Briefly, PBKDF2 applies iterative hashing such that the time to brute force “12345” changes from a few seconds to several minutes. In other words, the longer it takes to generate a single password guess compounds the hackers’ effort against a million combinations. For example, your WPA2 wi-fi connection applies 4,096 iterations for a password hash. To make the math simple, if it took 1 second for a single iteration of SHA1, then it would take over an hour for 4,096 iterations of SHA-1. (Obviously, it doesn’t take an hour because we enjoy efficient wireless connections — the point is that there will still be a significant time increase.)

Change your password. Avoid a domain-style password scheme. Employ PBKDF2 if you’re responsible for protecting passwords. Because hackers have the same advantage as Mick Jagger, “Time is on my side. Yes it is.

LinkedIn, HashedOut

Linked-“Be great at what you do”-In, bringing you modern social networking with worse password protection than 1970s UNIX. Not only did LinkedIn avoid a robust, well-known password hashing scheme like PBKDF2, they didn’t even salt the passwords. Something FreeBSD programmers have been doing for years.

It also appears some users are confused as to what constitutes a good password. Length? Characters? Punctuation? Phrases? An unbelievable number of users went for length, but couldn’t be bothered hitting the shift key, space bar, or one of those numbers above qwerty. I sat down for 20 minutes with shasum and grep — and my bookshelf for inspiration — to hand-hack some possible passwords.

grep `echo -n myownpassword | shasum | cut -c6-40` SHA1.txt

The grep/shasum trick works on Unix-like command lines. John the Ripper is the usual tool for password cracking without entering the super assembly of GPU customization. And if someone tells you to use node.js instead of Perl, Python, Ruby, or that grep command because a non-blocking IO is faster…just walk away. Walk. Away. Your brain will thank you.

Anyway, I love sci-fi and fantasy as much as the next person. I still run an RPG on a weekly basis; there’s no dust on my polyhedrals. Speaking of RPGs. I started the guesswork with 1st Edition AD&D terms only to strike out after a dozen tries, but your 2nd edition references aren’t bad:

waterdeep — Under Mountain was awesome, unlike your password.

menzoberranzan — Yeah, mister dual-scimitars shows up in the list, too. This single-handedly killed the Ranger class for me. (Er, not before I had about three Rangers with dual longswords; ’cause that was totally different…)

No one seems to have taken “1stEditionAD&D”. Maybe that’ll be my new password. 14 characters, a number, a symbol, what’s not to love? Aside from retroactive revelation?

tardis — Come on, that’s not even eight characters. Would tombaker or jonpertwee approve? I don’t think so. But no Wiliam Hartnell? Have you no sense of history? Even for a timelord?

doctorwho — Longer, but…um…we just covered this.

badwolf — Cool, some Jack Harkness fans out there, but still not eight characters.

torchwood — Love the show, but your anagram improves nothing.

kar120c — I’m glad there’s a Prisoner fan out there. It was a cool series with a mind-blowingly bizarre, pontificating, intriguing ending that demands discussion. However, not only is that password short, it even shows up in my book (upcoming edition, too). I should find out who it was and send them a signed copy.

itsatrap — Seriously? You chose a cliched, meme-inducing movie quote that short? And you couldn’t be bothered with an exclamation point at the end? At least you chose a line from the best of the three movies. (No, the last three aren’t worth considering. And, yes, they’re the “last” three because it’s only an “e” away from “least.”)

myprecious — Not anymore.

onering — Onering? While you were out onering your oner a password cracker was cracking your comprehension of LotR. By the way, hackers have also read earthsea, theshining and darktower. Hey, they’ve got good taste.

I adore the Dune books. Dune is in the top list of my favorite books. Just this week I offered a nice quote from the Bene Gesserit. Seems I’m not the only fan:

benegesserit — Don’t they have some other quotes? Something about fear?

fearisthemindkiller — Heh, even the hackers hadn’t cracked that one yet. Referencing The Litany Against Fear would have been a nice move except that if “fear is the mind killer” then “obvious is the password.”

entersandman, blackened, dyerseve — What are you going to do when you run out of Metallica tracks? Use megadeath? It’s almost sadbuttrue. And jethrotull beat them at the Grammy’s. So, there.

loveiskind — Love is patient, love is kind, hackers aren’t stupid, passwords they find.

h4xx0r — No, you’re not.

notmypassword — Actually, it is. At least you didn’t choose a 14-character secretpassword. That would just be dumb.

stevejobs — Now how is he going to change his password?

Comments on this post are only open to users with strong passwords. Please place your password at the beginning of the comment so we know you didn’t choose something as pop-culturally obvious that I can figure it out in 20 minutes.