How People Select Their Passwords

The invaluable Troy Hunt has run another analysis of recent dumps of password data from Anonymous, LulzSec, and others. This time he looks at how people select their passwords. As with his previous analyses, the results are depressing.

His idea was to look at the passwords to determine how they were selected. For example, 14% were either names—Stephen, Mary, Jessica, etc—or derived from names in an obvious way—nehpets, Mary!, Jessica1, etc. Using the plain name or adding a number accounted for 97 per cent of passwords in this category.

Other categories include dictionary words, names of places, all numeric and some other rare patterns. Thirty one per cent of the passwords exhibited no pattern. There’s lots of interesting data in Hunt’s post—he really drills down—so if you have any interest in this sort of thing, you should head on over there and read it.

The obvious take away from Hunt’s post is the undeniable fact that the overwhelming majority of people use terrible passwords even when they’re trying to be clever. There’s a secondary lesson here though: Hunt has identified a series of patterns that account for 69 per cent of the 300,000 passwords he examined. If he can do this so can the people trying to break passwords and you can be sure that those patterns will be coded into their password breaking software if they aren’t already there.

That brings us back to my post about password advice from XKCD. The “bad” password in the cartoon, Tr0ub4dor&3, seems like it should be secure. It’s got 11 characters taken from upper- and lowercase letters, numerals, and symbols. That’s an alphabet of 94 characters so if we assume the characters were chosen randomly that gives us just over 72 bits of entropy. More than enough, as a practical matter, to be unbreakable. But of course the characters weren’t chosen randomly. They were chosen according to a pattern. A well known pattern that password crackers are programmed to check for. Therefore the true entropy is much less than 72 bits; it’s more like 28 bits by Munroe’s estimation.

The process recommended by Munroe also seems like an obvious pattern. After all it uses dictionary words from a relatively short list—about 2000 given Munroe’s assignment of 11 bits of entropy to each one—and there’s only 4 of them. “What if,” people say, “the method became popular? Wouldn’t the bad guys just program their password crackers to check for that pattern?” The crucial difference is that the choice of the words is random (or has to be for the system to work) so even if everyone used the method it doesn’t help the cracker: the entropy is still 44 bits. Think of it this way, each word is a symbol taken from an alphabet of 2048 symbols and the password consists of 4 symbols. That’s 20484 = 17,592,186,044,416 possibilities for the password. Since the 4 symbols were chosen randomly, there’s no way for the cracker to reduce the search space.

As explained by Agile Bits’ Jeff in these two posts, you really need a bit more than Munroe’s scheme for a truly secure password1. He recommends the Diceware method, which uses, say, 5 words, chosen by the roll of dice, from a list of 7776. That gives 64 bits of entropy. Jeff recommends adding some private “word” that is gibberish but meaningful to you (something like m3crA,M,&M = my three children are Allison, Mary, and Michael). That way you can add enough entropy that it would take 500 million years at one million guesses a second to crack the password. Again, see Jeff’s two posts for the details.

It’s very counterintuitive that a few short dictionary words chosen from a small list provides more security than 11 characters of complicated gibberish, but it’s none-the-less true. The mathematics that shows that is fairly accessible but, of course, most people run screaming from the room when you mention mathematics. To those people, we can say only, “Stop using your intuition to argue otherwise because your intuition stinks.”

Footnotes:

1 “Secure password” is always a relative term. All we can do is estimate the amount of work it would take to crack the password by brute force—trying every possible password—and hope that the system we are applying the password to is at least as secure as the password given to it.

Posted in General | Tagged | Leave a comment

Searching For Blog Posts With Dired

Here’s another nice trick using Dired. I sometimes want to make an update to a blog post a few days or even weeks after I published it. I have no problem finding the title of the post, if I need to, because I can just search for some keywords and get a list of likely posts. The problem comes when I want to find the original Org file for the post. The file name is only loosely related to the title of the post. For example, this post’s source file is search-blog.org. So even though I have the title of the post it can be hard to find the right source file.

Here’s one way to do that. I can open a Dired buffer in my org/blog directory and use 【* .】 to mark all the org files. Then I can search through those files by using dired-do-search, which is bound to 【A】, to do a regular expression search for the title. If I were searching for this post I would use the regular expression

TITLE:[ ]+Searching For Blog Posts With Dired

(here’s a screenshot of a typical post’s org file). That will search all the marked files for the title and pop the target org file up in a new buffer ready for editing. Using TITLE: in the regular expression avoids matching a reference to the target post in some other post. When I’m done, I can unmark the files in the Dired buffer with 【Meta+Delete】.

Here’s a slightly easier way. Use 【Ctrl+x d】 to open a Dired buffer but instead of accepting the current directory type *.org (or ~/org/blog/*.org if the current directory isn’t org/blog). That will populate the Dired buffer with just the files you want. Then type 【t】 to mark those files and search for the title as before. When you’re done, just use 【Ctrl+x k】 to get rid of the Dired buffer.

Not everyone needs to find blog post titles, of course, but this little trick is useful for searching a set of files for anything that can be specified with a regular expression. Because dired-do-search is a variant of a Tags Search, you can use 【Meta+,】 to search for the next occurrence of the match. Searching a set of marked files is just another example of the power of Dired.

Posted in Blogging | Tagged , | 3 Comments

Oh Look! I’m A CSS God

If you look closely at the prettified key sequences—like this 【Meta+x】 one—you will notice that they now have slightly rounded corners in the hopes that they will be a tiny bit more suggestive of actual keys. I did that by using the border-radius property in CSS3. All I did was to add the line

border-radius: 3px;

to the .key definition. I didn’t add any of the browser specific border-radius properties.

Despite the title, I’m really a CSS noob, so if things don’t look right to you or the keys don’t look rounder and you are using a modern browser, please leave a comment.

Posted in General | Tagged | 2 Comments

Inhibiting Babel Evaluate Confirmation On The Mode Line

In Setting the Babel Evaluate Confirm Status, I wrote about Org-mode’s Babel asking for confirmation before executing a code block and why it’s sometimes convenient to turn that behavior off. In the post, I presented a simple Emacs Lisp function, babel-confirm to test the status of org-confirm-babel-evaluate and to optionally toggle its value. It’s often convenient to be able to turn off the confirmation question, especially when the code block gets called many times, such as when a table full of computable cells is evaluated.

Sometimes we have a file that we know is safe and that we often update and evaluate. One such example is my daily steps file, which has an R code block to generate the statistics max, min, mean, median, and standard deviation. Every day I enter the previous day’s steps and type 【Ctrl+c Ctrl+c】 to calculate the statistics. Each time I do this, Babel asks me to confirm that I really want to evaluate the code block. Notice that babel-confirm doesn’t help here because it takes more typing than just answering y to the question.

Yesterday, I saw this post on the Emacs reddit, which suggests another method: just put a mode line at the top of your file that turns org-confirm-babel-evaluate off. That way you get rid of the annoying question for that one file but keep the security of asking for confirmation for other files. To do this, just put

# -*- org-confirm-babel-evaluate: nil -*-

at the top of your file.

What could be simpler? It’s easy to forget the power of the mode line and that’s too bad because sometimes it’s just what you need.

Posted in General | Tagged , , | 1 Comment

Some More Emacs Dired Magic

In a comment to my post yesterday about A Nice Emacs Dired Command Sue Nymme notes that in addition to 【* t】 a plain 【t】 will also toggle the marks in a Dired buffer. That brings up another Dired trick that I learned from the Emacs Wiki.

You can display only the marked files by using the command 【t k】. This works by first toggling the marks so that the previously marked files are not marked and all the others are. Then the 【k】 kills (that is, hides) all the marked files. You can restore things with the 【g】 command or with the 【t g】 command if you want the files to still be marked. The 【t g】 command is useful if you have a lot of files in the directory and want to see which files are marked before you perform some operation, such as delete, on them.

Posted in General | Tagged , | 1 Comment

Password Advice From XKCD

In view of today’s XKCD:

http://irreal.org/blog/wp-content/uploads/2011/08/wpid-password_strength.png

I thought it would be useful to again mention the post by Jeff over at the Agile Bits Blog. That post discusses making a password by choosing 5 or 6 random words for your passwords. That’s what Randall Munroe is talking about in the XKCD comic.

As I was writing this post, I popped over to Agile Bits to get the URL for the link to the Blog. There I found that Jeff had written a followup article also based on the comic. In it he deconstructs the comic and shows how Munroe arrived at his estimation of the entropy of the two systems. As usual, there is a lot more going on in the comic than you might think. This is a really great post and everyone who uses a password for anything nontrivial should read it. Really.

Posted in General | Tagged | 1 Comment

A Nice Emacs Dired Command

As I’ve mentioned many times, I write my blog posts in Emacs and publish them with org2blog. After I push the post to WordPress, I have a buffer and file with the HTML that I no longer need. I used to clean that up by opening a Dired buffer and using the 【% m】 command to ask that files be marked by a regular expression. When prompted for the regexp, I would specify \.html$. Then a 【D】 command would delete any html files and ask if I wanted the buffers deleted too. That’s a quick and easy way to get rid of leftover files and buffers.

Somewhere along the line, I discovered an easier way to mark those files in Dired. Instead of 【% m】 use the command 【* .】 to ask that buffers be marked by their extension and then just specify html when prompted.

Today I read that this command is not well known so I thought I’d share. If you think about it, we often want to delete files this way. Think of how many times you’ve typed something like

rm *.o

Here are some other useful commands in the marking family:

Key Sequence Command
* / Mark Directories
* @ Mark Symlinks
* * Mark Executables
* t Invert Marking
* s Mark Files in Current Subdir
* % Mark Files Matching Regexp
* ( Mark Files For Which an Elisp Expression Returns t (Dired+)

Update: Several commenters have reported that the 【* .】 command is available only when dired+.el is loaded. I’ve been using Dired+ for a long time and can recommend it whether or not you need this particular command.

Posted in General | Tagged , | 8 Comments

Using Reeder

It’s been almost two months since I started using Reeder and I was thinking that I should write a review. Fortunately, Angel over at Apple Casts has already taken care of that for me. He does a very nice job so I encourage you to head on over there and take a look if you’re in the market for an (OS X/iOS) RSS reader.

As I wrote when I first adopted Reeder, I like it because it works across the entire Apple platform and keeps my reading in sync no matter which device I’m using at the moment. That last point deserves some emphasis: iMac, MacBook Pro, iPad, or iPhone1 it makes no difference. The “same” application runs on them all and because Reeder is a Google Reader client what I’ve read on one device is reflected on the others.

I put same in quotes in the last paragraph because, of course, it’s not literally the same application—it’s a family of ports of a single application. Each of these ports offers the same functionality and behave in essentially the same way but there are some UI differences due to different hardware. On the Macs, for example, you can control Reeder entirely through the keyboard if you like; with the iPad, the keyboard is never used except for entering subscriptions, emailing articles, and things like that. The hardware differences that matter go beyond the type of computer. For example, my MacBook has an “old” trackpad that recognizes only the two-finger scrolling gesture whereas my iMac has a Magic Trackpad that recognizes the full set of Apple gestures. The same full set of gestures are available on the trackpads of the newer MacBooks, of course. These differences influence how you use Reeder.

Here’s how I invoke the common Reeder functions on the various devices:

Function iMac (Magic Trackpad) MacBook (old trackpad) iPad
Next/Previous Feed click on feed n/p touch feed
Next/Prev Article 4-finger swipe down/up j/k touch down/up arrow
View Article 4-finger swipe right v touch article
View Article in Readability pinch open g pinch open
View Article in Browser Menu b Menu

As you can see, I’m inclined to control Reeder on the iMac entirely with the Magic Trackpad although I could use the same keyboard shortcuts that I use on the MacBook.

There are other Reeder function that I don’t use very often so I haven’t listed them. You may find you do want to use them or you may find that you want to invoke the functions in a different way from me. The nice thing about Reeder is that you can pretty much use whatever method you like except on the iPad where everything is touch based.

Update: touch up/down arrow → touch down/up arrow for iPad

Footnotes:

1 There is an iPhone version of Reeder but I don’t use it because I don’t like reading articles on the small screen.

Posted in General | Tagged | 1 Comment

Solarized On Emacs

Unlike many hackers, I don’t care for a dark-themed Emacs so I use the basic black on white screen. Lately this scheme has begun to feel overly bright and I thought I would try some lower contrast colors. I’ve browsed the Solarized color scheme several times and thought it looked great on the Web site. So I downloaded Solarized and color-theme, made the necessary changes to my init.el, and bounced Emacs. The next thing I did was to comment out the enabling Emacs Lisp in my init.el and bounce Emacs again. I absolutely hated using the color scheme. At first I couldn’t figure out why I didn’t like it; as I said, it looked great on the Web site. I finally realized that I didn’t like working with the low contrast colors. The syntax highlighting didn’t stand out as well and I had a hard time reading some of the shades.

As a compromise, I set the background color of my frame to “oldlace” (#fdf5e6) and left the other colors alone. That definitely helped with the brightness and I will keep my Emacs this way for a few days before I decide whether to make the change permanent or go back to a white background.

Apparently I’m not alone in my aversion to low contrast colors but others aren’t so sure. We’re talking about my Emacs screen so I don’t have to please anyone but myself. All the design decisions for the blog use the default values of the Twenty Ten theme. Those turn out to be #666 on white so while there’s a little less contrast than the stark black on white it’s hard to tell unless you look carefully. I think it looks nice and is easy to read.

Here’s a shot of my Emacs screen with the oldlace background. It looks pretty good, I think, if you like a light themed Emacs.

http://irreal.org/blog/wp-content/uploads/2011/08/wpid-oldlace.jpg

Posted in General | Tagged | 2 Comments

Let Emacs Make Your Scripts Executable

Because I like to automate things, I write a lot of shell scripts. Sometimes it’s just some simple shell code, other times the script loads and executes a Scheme program. Almost every time I do this, I forget to set the execute bits on the script so, of course, it fails the first time I try to run it. Here, via Hacker News, is a simple trick to automate making your scripts executable. Add the following to your .emacs or init.el file.

(add-hook 'after-save-hook 'executable-make-buffer-file-executable-if-script-p)

This will check when you save a file to see if it looks like a script and if it does, make it executable. The executable-make-buffer-file-executable-if-script-p function does the intelligent thing when the file is already executable so it won’t mess up any file mode bits that you’ve already set.

Posted in Programming | Tagged | Leave a comment