Monthly Archives: January 2006

Dictionary Attacks: “8@d P@55\/\/0rDz” Part 2

Posted by on January 30, 2006

One of the most common ways of protecting access to information or a computer account is with a username and a password. If someone wants to try to gain access to your account, the username is often quite easy to guess (email address, for example) so all they might need to figure out is the password.

One method of cracking the password is with a login dictionary attack.

With this kind of attack, software consecutively tries words from a list in a dictionary file (also known as a wordlist). While other attacks, like brute force attacks, are also effective, in real life, dictionary attacks succeed so often because people base their passwords on short, easy to remember words. The larger the dictionary file, the better the chance the attack will succeed.

While a research attack requires some basic knowledge of a person or system, a dictionary attack can be effective without any starting point. However, if you know that someone speaks French, English, and Spanish, you can load up those three dictionaries as a starting point, effectively narrowing your focus to relevant choices.

You can easily find dozens human language dictionaries for these types of attacks in minutes. Why did I say human? There are also Vulcan, Klingon, and other non-human dictionaries available. Actually, word lists go way beyond basic language dictionaries. Celebrities, aircraft, cars, brand names, sports terms, model numbers, jargon, and pretty much anything else that someone might use for a password has been thought up and added to a word list.

Better attack software might also do character manipulation. It’s common practice for people to substitute the number zero for the letter o, for example, or the number one for the letter l.

The software might try:

  • dig, Dig, DIg, DIG, dIG, diG , dIg
  • dog, Dog, DOg, DOG, dOG, doG, dOg
  • dug, Dug, DUg, DUG, dUG, duG, dug

as well as:

  • d1g, D1g, D1g, D1G, d1G, d1G , d1g
  • d0g, D0g, D0g, D0G, d0G, d0G
  • dvg, Dvg, Dvg, DvG, dvG, dvG
  • dVg, DVg, DVg, DVG, dVG, dVG
  • d19, D19, D19, D19, d19, d19 , d19
  • d09, D09, D09, D09, d09, d09
  • dv9, Dv9, Dv9, Dv9, dv9, dv9, dv9
  • di9, Di9, DI9, DI9, dI9, di9 , dI9
  • do9, Do9, DO9, DO9, dO9, do9, dO9
  • du9, Du9, DU9, DU9, dU9, du9, du9

Common character substitutions include:

A 4 B 8 E 3 g 9 T 7 V \ /
i 1 L 1 O 0 S 5 M / \ / \ W \ / \ /

Also, decent word lists will contain common (and not so common) misspellings. They will also contain keyboard patterns (asdf, qwerty) and common variations of any known pattern of characters that people tend to use.

Tip: don’t use words based on any kind of dictionary, even if you purposely misspell or manipulate the characters.

“Click here” to fail.

Posted by on January 29, 2006

I tell my students that if I see “click here” as link text on any of their work, they will automatically fail my course.

Period.

Why? It is low-information content. You have no idea what the destination of the link it.

People usually don’t stop and read everything word for word right away when they first see a Web page. They scan the page first. Their eye jumps from headings, lists, images, and anchors, looking for clues to see if they want to read the page or move on.

Anchor link text stands out from standard content text (otherwise, how will people know that it is a link?) and therefore, tends to draw the eye of the user to it.

So, assuming that the link text catches their eye and all it says is “click here“, they have to waste time moving their eyes around so they can read the context around the link. This is a lot of extra work, which is an absolute waste of time and energy.

People should be able to easily identify the destination of a link without any extra effort. Do these examples tell you anything about where you will go if you use them?

  • Click here
  • Read more

How about these?

  • Today’s weather forecast
  • Latest Toronto news

The first examples offer no clue to their purpose when they are taken out of context. The second group is far more helpful.

Choosing link text is a bit of an art as well as a science. Take this sentence from a real Web page:
Click here to register for our regular newsletter.

You could reword this to:
Register for our newsletter.

Code validation: Ch-Ch-Ch-Ch-Changes (turn and face the strain)

Posted by on January 26, 2006

I started teaching HTML in the ’90s. At that time, I would tell students that valid code was important for several reasons, but the one that seems to stick was that it might help them troubleshoot why pages (p-p-p-pages) looked so different between browsers at the time.

You see, at that stage, there were many different browsers, but Netscape was the current champion with Internet Explorer the up and coming underdog. While there were standards for coding your Web pages, neither browser really followed them, which is why some pages could look wildly different between IE and Netscape.

I rejoiced when the World Wide Web Consortium put their online Markup Validation Service up. Now students had an easy way to confirm that their code was leaner, cleaner, and truer to the standards.

At that time, the student might not know if the problem was with their code or with the browser. By validating the code, they could start to eliminate potential problems.

Fast-forward to 2006. IE is the current champion, and FireFox (a relative of Netscape) is an up and coming underdog. While the new roles certainly signifies ch-ch-changes, the need for valid code remains the same.

XHTML (the evolution of HTML) is all about logically defining how content relates and not about how it looks. CSS is supposed to take care of that.

CSS1, the first level of the standard, took care of the basic visual chores of the horrid font tag and a few other simple visual feats. CSS2 (and 3) took on a much larger role. There are logic flow capabilities now, so that you can specify “if a heading level 3 is a direct child of a heading level 2, make it green, otherwise, make it red”. This is a powerful, but very hard to troubleshoot if your code is not logically marked up.