Thursday, November 22, 2012

DIY xkcd Password Generator

One of the things I'm thankful for today is xkcd. Specifically, I want to talk about the world-famous password strip, which points out that using a few selections from a big list of things (a dictionary) is more random, and yet easier to remember, than a lot of selections from a limited list of things (the keys on your keyboard).

There are even sites which generate xkcd-style passwords for you. Many sites, in fact.

The other day I was using one of these generators to make a password for work. The only problem was that the system that I was logging on to required my password to be between 8 and 16 letters, which is difficult to do when you're dealing with a list of random dictionary words. It also checks to see if you had a string of four or more letters that matched a dictionary word.

To fix this, I needed to have a list of, say, three letter words. Where to find them? Sergey and Larry's search engine helped. For example, here's a list of allegedly legal Scrabble words. Given that, all we need is a script to generate a list of words.

That script is below. What I didn't do was include the words. For one thing I'm not sure about the copyright status of that list. For another, you might want to use your own list. For a third, it would make this post really, really long. So add your own list of words, one per line, between the two EOF lines in the script.

While I was at it, I decided to add a few improvements, towit:

  • You can specify the number of words. If you call the script xkcdpass, then
    xkcdpass 5
    
    will generate a password using five words from the list. The default is 4, which you can easily change.
  • Given the number of words in the list, call it N, and the number of words in the password, call it M, you can generate NM unique passwords (since strings like thethethethe are perfectly valid). That's a measure of password security, so the script tells you that.
  • You have three choices of randomness. In order of security, they are: The bash variable $RANDOM, which can be seeded to the current time, and the linux scripts /dev/urandom and /dev/random. Uncomment the one you like, depending on your level of paranoia.
  • It should work on any system that runs bash, including Macs.
  • And, of course, I tried to document where I got everything.

So here's the script. Add a comment if you see a problem, or if you just like (or hate) it.

#! /bin/bash

# Generates an xkcd-like password from a list of three-letter words

# Usage

# xkcdpass n

# where n>0 is the number of words in the string.  The default value of
#  n is 4.

# Set the default if needed

if (( $# < 1 ))
then
    nwords=4
else
    nwords=$1
fi

# Set up an array and populate it.
declare -a array
let index=0

# There is a list of acceptable three-letter Scrabble words at
# http://www.yak.net/kablooey/scrabble/3letterwords.html
# Add additional words, if you like, or use a different list.

while read line
do
	array[$index]=$line
	let index=$index+1

# Insert your words between the two EOFs, one per line
# There is a list of acceptable three-letter Scrabble words at
# http://www.yak.net/kablooey/scrabble/3letterwords.html
# Add additional words, if you like, or use a different list.

done <<EOF

EOF

# So how secure is this string (bigger numbers are better):

echo -n $index "words in file, giving "
unique=`echo "$index^$nwords" | bc`
echo $unique unique passwords

# Uncomment this if you use $RANDOM and want a
#  unique seed.  See http://linuxgazette.net/issue55/tag/4.html
# The date +%s command gives the time from the epoch

RANDOM=$$$(date +%s)

# Select $nwords at random.  Note that you can select the
#  same word more than once.

for (( i=0 ; i<$nwords ; i++ ))
do

#   Uncomment the random technique you want to use:

#   Probably not all that random, but you can use the seed above
#   to make it better.
    let number=$RANDOM

#   More random, but slower (the sed gets rid of some annoying spaces)
#   -N3 prints out 3 bytes of data.  That's probably enough.  Note that
#   if you have 2^N words, for any integer N, it won't matter how
#   many bytes you use if the number of bytes is bigger than N
#    let number=`od -An -N3 -i /dev/urandom | sed "s/ *//"`

#   For the difference between random and urandom, see
#   http://stupefydeveloper.blogspot.com/2007/12/random-vs-urandom.html

#   Really random, though visibly slow
#    let number=`od -An -N3 -i /dev/random | sed "s/ *//"`

#   Do modulo arithmetic to get the number between 0 and $index-1
    let "number %= $index"

    echo -n ${array[$number]}
done
# Print a newline character
echo

Saturday, June 19, 2010

Smart ssh tricks

I want my computers to talk to one another.

More specifically, I want to be able to remotely log in to one of my computers from another one, and I want to be able to easily copy files from one computer to another. The easiest, most secure, way to do that these days is to use the Secure Shell protocol, aka ssh.

Examples: I have an account on a computer called grumpy (sleepy and doc were already taken). To log onto grumpy from hal, I open up a terminal window and type:

$ ssh rcjhawk@grumpy

The program then logs me onto grumpy, where I can access the system just as I can for any desktop machine.

Or, say, I have a file at /home/rcjhawk/Documents/strasburg_pictures.ppt on grumpy. To copy it over to Hal, I use the secure copy program, scp:

$ scp rcjhawk@grumpy:Documents/strasburg_pictures.ppt .

which, obviously, works pretty much like the regular copy program except that I have to specify the machine and account name right up front.

And, finally, I can send files the other way:

$ scp The_Hard_Times_of_Zach_Greinke.txt rcjhawk@grumpy:Documents

which sends that regrettable file into the Documents folder on grumpy.

Except:

You will probably find that this doesn't work out of the box in your Ubuntu setup. You'll get a message that looks something like this:

ssh: connect to host grumpy port 22: Connection refused

That's because Ubuntu ships ssh in two parts:

  • openssh-client: this lets you use ssh and scp from your machine to log onto another machine. This is installed with the standard Ubuntu installation, and is all you need if, for example, you want to log onto your work computer from home.
  • openssh-server, on the other hand, allows other machines to log onto your personal desktop machine. This is not installed by default in Ubuntu because it's an obvious security hole unless you know what you're doing. If you do know, or assume that you will learn, install the package with

    $ sudo apt-get install openssh-client

    Once you do that, sshd, the daemon that controls remote access, will automatically start up, and will start up every time you reboot the machine. Then you're good to go.

In the example above, grumpy needs to have openssh-server installed and running, but hal does not.

Note for Mac Users: You get the equivalent of openssh-server by going to System Preferences => Sharing and clicking Remote Login.

Security

ssh encrypts the transmissions between machines, but it also has other security features. The first time you try to log onto a machine, for example, you'll get a message that looks something like this:

$ ssh rcjhawk@grumpy
The authenticity of host 'grumpy (192.168.54.42)' can't be established.
RSA key fingerprint is xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx.
Are you sure you want to continue connecting (yes/no)?

If you answer yes, then you'll get the message:

Warning: Permanently added 'grumpy,192.168.54.42' (RSA) to the list of known hosts.

After that you'll be able to log onto grumpy without the warning message. If you want to start over, i.e. not recognize any computer as being previously visited, erase the file $HOME/.ssh/known_hosts

You can also limit access to the machine by editing your /etc/hosts.deny and /etc/hosts.allow files. As I've noted before, if you don't want ever Tom, Dick, and Susie to have a chance to access your machine, your /etc/hosts.deny file should read:

ALL: ALL

after which only addresses listed in your /etc/hosts.allow file will have access to the machine. In my /etc/hosts.allow file I currently have

ALL: 192.168.1.0/255.255.255.0 ,

which allows all machines on our local network to access grumpy.

OK, everything is good, right? Well, not quite. As things are set up right now, every time you ssh or scp to grumpy you must enter a password. This isn't a big annoyance with ssh, because presumably you will keep the remote login running for a relatively long time. However, it is an annoyance with scp, if you want to copy a large number of files from different places, requiring a large number of scp commands.

The solution is to use ssh-keygen to generate a a key. Here's how it works:

Start the program:

$ssh-keygen -t dsa Generating public/private dsa key pair.
Enter file in which to save the key (/home/rcjhawk/.ssh/id_dsa):


We'll use the default directory location, so just hit return here.

Enter passphrase (empty for no passphrase):

Frankly, I don't know anyone who does use a passphrase. It does protect your key against someone who's gotten access to your account, but at that point you're probably hosed anyway. So for now we'll just hit return.

Enter same passphrase again:
Your identification has been saved in /home/rcjhawk/.ssh/id_dsa.
Your public key has been saved in /home/rcjhawk/.ssh/id_dsa.pub.

Now let's take a look at the .ssh directory:

$ ls -la $HOME.ssh
total 16
drwx------  2 rcjhawk rcjhawk  4096 2010-06-19 13:04 .
drwxr-xr-x 34 rcjhawk rcjhawk  4096 2010-06-19 13:01 ..
-rw-------  1 rcjhawk rcjhawk   672 2010-06-19 13:04 id_dsa
-rw-r--r--  1 rcjhawk rcjhawk   599 2010-06-19 13:04 id_dsa.pub

Here you'll notice two files. One, id_dsa, is your private key. The second, id_dsa.pub, is your public key. Key the private key private. Don't let anyone have access to it. Don't copy it over into the .ssh folder of another account, or to another computer. You'll note that both the .ssh directory and id_dsa are set so you are the only person who can read those files. Keep it that way.

The public key, now, that's another matter. If you place id_dsa.pub into the file $HOME/.ssh/authorized_keys on another computer, you'll be able to access that computer from your home computer. Here's one way to to it (I'm leaving out all the password prompts):

$ ssh rcjhawk@grumpy
Welcome to grumpy!
rcjhawk:~ $ cd .ssh
rcjhawk:~/.ssh $ scp rcjhawk@hal:.ssh/id_dsa.pub tempid
rcjhawk:~/.ssh $ cat tempid >> authorized_keys
rcjhawk:~/.ssh $ rm tempid
rcjhawk:~/.ssh $ exit

What did we do? We logged into grumpy, copied hal's public key over to grumpy's .ssh directory, and added it to the end of the authorized_keys file. I renamed the file during the copy so as not to write over grumpy's own id_dsa.pub file, if one was there. Notice that scp was able to get that file even though Hal's .ssh directory is copy protected, because you gave the system the right password.

The next time you try to ssh or scp from hal to grumpy, ssh will find the public key on grumpy, compare it to the private key on hal, and conclude that you are, indeed, allowed to log in or transfer files.

The discerning reader will note that I'm only applying this to my local network, which all sits behind a router and firewall. How, you may ask, can I use ssh to log onto my local machine from outside my home?

Well, I wish I could tell you, but at the moment I can't. It's something to be researched in the future. If you're reading this, and you know how to do it, post a link to the procedure in the comments.

Friday, May 28, 2010

hosts.deny

Ubuntu, and most Linuxes, by default come with an empty /etc/hosts.deny file. I'd argue that by default it really should look like this:

$ cat /etc/hosts.deny
ALL: ALL

Because:

  • If you don't know what how the /etc/hosts system works, you shouldn't allow others to access your machine.
  • If you do know how it works, then you know enough to edit the files to do what you want.

Comments?

Friday, May 18, 2007

Do People Really Read the Links They Click?

Apparently not ...

Hundreds Click on 'Click Here to Get Infected' Ad

And only 2% of them were non-Windows using geeks wondering what would happen if they pressed the button.

(This would have been a This Week's Sign ..., but that award has been retired until we find something better than O.J.)

Saturday, May 12, 2007

Secure File Deletion

During the recent Windows unpleasantness I borrowed a couple of old disk drives to backup data on the “broken” disk — it was only broken under Windows, I could read it quite easily in Linux, but never mind. Now that everything's fixed, I want to give the drives back. The problem is that they have personal data on them, so I want to delete it all before I give it back.

This isn't as easy as it seems, since files leave traces all over. Fortunately, the folks at the Stanford Linear Accelerator Center (SLAC) have put together a guide to Secure Erase in UNIX, which also works in Linux.

I'm not going to repeat all the article. Just note that you need:

  • shred, which does secure file erasure by repeated rewrites followed by deletion, and comes by default in Ubuntu
  • scrub, which erases the free space in your file system by filling it up with a large, random file, which you then delete (with shred, if necessary). This isn't a standard file, you have to download and compile it.

Ideally, one would delete everything on the disk in question in the following way:

$ cd /media/disk # or wherever the thing is
$ sudo rm -fr * # delete all files and directories recursively
$ scrub -X junk # Fill up the whole disk with junk
$ shred --remove junk # rewrite several times, then delete

The difficulty is that the disk I used has a VFAT file system, so the biggest file that can be written is 4 GB. I just wrote

$ scrub -X junk
$ scrub -X junk1
$ scrub -X junk2

etc., until the disk was filled up, then ran

$ shred --remove junk*

If you are using a journaling file system other than ext3, there are some other issues involved, but for VFAT or ext3 this is a good way to go.

26 July 2009: Replaced the old link to scrub, which generates a 404 error, by the link https://computing.llnl.gov/linux/scrub.html, as noted by the first commenter. You can also download scrub directly from sourceforge at http://sourceforge.net/projects/diskscrub/.

Saturday, August 07, 2004

Making It Never Exist

Part two of that Slashdot article I mentioned before:

For some reason, this happens most frequently when I go to washingtonpost.com, but it happens on other sites, too. I click on an article, and get the message

Waiting for doubleclick.net

and then the web page hangs for awhile.

What's happening is that the Post is going to doubleclick.net and waiting for advertisements to load up. Of course, the net doesn't just go to doubleclick, it goes elsewhere as well. And many of those ``elsewheres'' are nothing but annoying ads.

Wouldn't it be great to get rid of those ads? OK, we can use something like Adblock, and I recommend that, but wouldn't it be wonderful to make your computer believe that places like doubleclick never existed? (And, incidentally, decrease worries about your privacy.) There is a way.

Let's go back to the early days of the Internet. There was nothing like the current Domain Name Service (DNS). Oh, each web site had an IP address, but there were no central directories to tell you which IP address belonged to Google (not that Google existed back then).

So how would you have found Google? In order to find things on the Internet, each computer had a file called /etc/hosts. (OK, each Unix-like computer had such a file. I have no idea what other OS called it.) In the /etc/hosts file was a line like:

216.239.41.104 www.google.com

which told your computer the IP address of Google. Of course, this file had to be upgraded periodically by downloading a new file from somewhere, and eventually it got so big that the whole thing had to be scrapped and DNS was adopted. But, the /etc/hosts file still exists, and it's read before your computer goes out to your chosen name server!

This is really quite useful. If you use Google a lot, for example, adding the line

216.239.41.104 www.google.com

to /etc/hosts saves you from having go to the DNS every time you want to do a search. And there's another use:

Near the top of /etc/hosts is a line like

127.0.0.1      localhost.localdomain localhost

This tells your computer where your local computer lives on your local network (even if you don't have a local network). If you try to go to localhost from your web browser, you'll get a message like

The connection was refused when attempting to contact localhost

(Unless you are running your own web server, in which case you'll get your home page.) In this case, localhost and localhost.localdomain function as aliases for the address 127.0.0.1. Any request to go to localhost takes you to 127.0.0.1, and does whatever you tell it to.

Now suppose the webpages you visit regularly connect you to a scuzzy site we'll call reallystupidads.com. You're tired of these ads and never want to see them again. What to do? Remember that /etc/hosts is read first, before the request goes out to the DNS. So add a line

127.0.0.1  reallystupidads.com

to /etc/hosts. Now, when that page you are interested in asks reallystupidads.com send some advertisements, your computer looks up the address, finds that it is 127.0.0.1, and does whatever you've set it up to do. If you don't run your own web server, it does nothing. It's as if that site never existed.

So, what you need is a list of really annoying sites that should be banned from your computer. Of course, this being the Internet, there are many such lists. The one I'm using is Mike Skallas' Ad Blocking Hosts file. Basically, you add it to /etc/hosts. And, frabjous day, there are instructions for doing the same thing in Windows 2000 and XP.

And, of course, once you know the trick, you can add your own annoying sites to the list. Parents can add sites that they want to keep their children out of, e.g.

Hopefully no one will add

127.0.0.1 hawknotes.blogspot.com

The Effects of Spyware

One article on Slashdot (Analysis of Spyware) yields two entries here. First, the title article:

I've mentioned the program Ad-Aware, which locates and helps you remove spyware from your system. OK, what happens if you don't use a program like this, and accidentally/on purpose download a program that results in spyware being loaded onto your computer?

The folks at SANS decided to find out, so they intentionally infected a virtual PC with spyware (look for the heading Follow the Bouncing Malware - Part I and then tracked the results. You can read all about it at the link above, but, basically, it rewrote the Windows registry, changed IE's home page, changed the default search engine, and dropped various programs onto the computer. To see what happens, we'll have to wait for Part II.

Monday, August 02, 2004

More Power to the Shields, Mr. Scott

The Internet Tourbus (Hop On the Internet Tourbus!) has another good article on computer security, this time firewalls. In particular, they mention the site Gibson Research Corporation, which runs a service called SHIELDS UP!. This probes your computer, DSL router, hardware/software firewall, etc., to see how secure your installation is against hackers. I tried it, and it taught me a few things about security -- specifically, I found that my router was replying to pings, and figured out how to shut that off.

A word of warning -- as they say, these people are going to probe your computer. If you don't want them doing that, or if it's your employer's computer, not yours, and you don't have permission, then don't go through with the test. And, even though I've used it, I'm not going to say that this is totally secure, or even a Good Idea. But it's something you should consider if you are worried that your computer could be hacked. (If you run a business and don't know how to do this for yourself, you should probably seek professional help to do the tests.)

Forgot to Mention: The Tourbus guys have a tutorial on running the Shields Up! tests.

Wednesday, June 09, 2004

Another Reason Not to Use Internet Explorer

This just in via friends, and Slashdot, there's another hole in Internet Explorer. According to the article, it will "allow a complete bypass of security and provide system access to a computer," and it's already available in the wild.

Solutions are to either:

If you want to be supersafe, use lynx.

Saturday, May 08, 2004

Internet Weather

I got this from Jerry Pournelle's Chaos Manner website. I'm sorry, I can't find the link to the original article. (If Chaos Manner has an RSS feed, or an index, I haven't found it yet.)

It's an Internet Weather Bug, which tells you how the Internet is behaving at the moment. Apparently when there is some virus out in the wild it will change colors. I'm going to try posting this on the sidebar to the right, we'll see how it works.

OK, it looks better at the top, so that's where it will stay for now.

Wednesday, January 14, 2004

System Services

Something that should be run early on, but I'm just now getting around to: $ redhat-config-services (root password required)

Lets you turn on and off daemons. I'm turning off various things I don't need, like sshd, as I don't need this machine to be an ssh server, at least not at the moment.

If a service is running, you can stop it with an icon at the top of the window. You can also prevent it from starting on the next reboot by unclicking the box next to the name of the service.

Sunday, December 21, 2003

Denial ain't just a river

No other machine needs to acess the "services" we provide, so edit /etc/hosts.deny to read:

$ cat /etc/hosts.deny
ALL: ALL