Like It Matters

[Runner Girl from Amateur Hour by Ben Pence] Inspired by one of...

Sun, 16 Oct 2011 00:00:00 -0400

[Runner Girl from Amateur Hour by Ben Pence]

Inspired by one of my High School’s physically rambunctious treasures, Runner Girl.

dontspamme 11.7

Tue, 19 Jul 2011 00:00:00 -0400

For the last month or so, I have been working on an anti-spam project. All users with a google account can use and deploy this because it runs on Google App Engine; however, I should warn you that it is in an early stage in development. Many of the features I planned for the project have yet to be implemented (such as the accompanying chrome extension).

The project summary/install guide/user guide is located at https://github.com/benpence/dontspamme/wiki/Summary.

1 SSH Account: Gitolite + Shell Access

Sun, 20 Feb 2011 00:00:00 -0500

Here’s a situation I found myself in:

I have 1 ssh user available to me
I wish to have shell access to this user
I wish to use this user for multi-user git repositories

Here’s the solution I found: Use an ssh ‘config’ file and gitolite. I followed the instructions from Pro Git to install gitolite. I will repeat them here for convenience. Replace words starting with ‘my_’ with names respective to your setup.

Create a key pair with no passphrase.

$ ssh-keygen -t rsa

Copy your public key to the remote server. (Note: some OSs have the command ssh-copy-id. Run ‘ssh-copy-id -i ~/.ssh/id_rsa my_remote_user@my_remote_server‘ to skip the following step).

$ scp ~/.ssh/id_rsa.pub my_remote_user@my_remote_server:~/
$ ssh my_remote_user@my_remote_server
my_remote_user@my_remote_server:~$ cat id_rsa.pub >> .ssh/authorized_keys
my_remote_user@my_remote_server:~$ rm id_rsa.pub
my_remote_user@my_remote_server:~$ exit

Clone gitolite source and install it. Replace git_admin with the desired gitolite admin user name. The passphrase-prompt asks you for a passphrase to protect your gitolite private key. I left it blank.

$ git clone git://github.com/sitaramc/gitolite
$ cd gitolite/src
$ ./gl-easy-install -q my_remote_user my_remote_server git_admin

The install creates the following files in your home directory:

.ssh/git_admin
.ssh/git_admin.pub

The install creates the following files/folders in

my_remote_user

‘s home directory:

.cache/
.gitolite/
gitolite-install/
.gitolite.rc
projects.list
repositories/

Open my_user’s ssh config file for editing with your favorite text editor.

$ pico ~/.ssh/config

Add something like the following, substituting in your respective info, and save.

Host my_gitolite_server
    Hostname my_remote_server
    User my_remote_user
    Port 22
    IdentityFile ~/.ssh/git_admin

When you wish to use clone/pull/push/etc with your gitolite server, usemy_gitolite_server instead of my_remote_user@my_remote_server.

git clone my_gitolite_server:my_favorite_repo

Note: If you’re on OS X, ssh-agent may save your password for shell access, preventing you from using your git key. Enter ‘killall ssh-agent’ at command line to erase its keys before connecting to your gitolite server. Don’t worry, your key files will by fine.

UPDATE (12 Aug 2011): Some versions of openssh will die with the message ‘PTY allocation request failed on channel 0′. Until I figure out how to fix this properly, my remedy is to append the following to ~/.profile:

GIT_SSH='ssh -T'

Hashing For Humans 2

Mon, 08 Nov 2010 00:00:00 -0500

In Part I of hashing for humans, my objectives were to create a mental way of…

Generating unique passwords for web applications using information available to you on the login page
Generating unique passwords that do not imply each other (somebody finds your password to site A; that somebody cannot guess your password for site B)

Having pondered the topics of password-guess-ability and memorization, I have come up with two more solutions that rely more on the password format/infrastructure, instead of your head. They are quite different approaches to solve a similar problem. These solutions are not new, but it seems that too many web services/applications use forms of authentication that are old and unstandardized to protect their users.

Here are three common scenarios to keep in mind when reading these solutions:

You are at a library and need to use the library’s computers to check your web email
You are at a hotel and want to use the hotel’s computers to access your Facebook account
You are at a friend’s house and want to make a quick purchase on Amazon.com

In each situation, let us assume that the computer is infected with malware that records every keystroke you type (within the web browser as well). How can we minimize the risk of somebody stealing your password and taking over your account?

working on untrusted computers

When working on a computer you don’t trust, you want to minimize the cost to you, should your password be stolen. So let’s use one password for logging in on your home computer and one password for logging in on untrusted computers. The password for untrusted computers will log into your account with less privileges: features such as changing your password/associated email (Facebook, Amazon) and looking at saved credit cards (Amazon)/your current address (Facebook, Amazon) will be unavailable.

Unfortunately, this does not reduce all the risk. Suppose someone learns your less-privileged account password. They will still have access parts of your account and you may never be made aware. So let’s use time-sensitive passwords. You generate a less-privileged password; however, the password will only be valid for an arbitrary amount of time after you have logged in with it for the first time. So if you are going on vacation for 7 days, you can generate a 7-day password that will only be valid for the vacation, assuming you use it on the first day. Yay.

Generating passwords for every account sound like a pain in the ass. How do we standardize this solution to multiple web services/applications? This problem has already been tackled, the most popular implementations being openid and Facebook Connect. Using services like these, users have the ability to login to a site through these authentication services (openid & Facebook connect). Now, if we, as an Internet community, can work to make our services/applications compatible with the previously mentioned services, we have only to remember, at any given time, a normal password and a temporary password.

an alternative to traditional alphabets

I had the pleasure of seeing a demonstration by Authernative, Inc., a company specializing in “user and transaction authentication” at a GTRA conference. One of Authernative’s solutions to authentication was based on remembering shapes, not letters/numbers/symbols.

Instead of choosing a password that meets certain criteria, you choose a shape—a shape that is a sequence of blocks in a grid. In the image above, Figure B shows one such shape for a 3×3 grid, Figure A (yes, I used Adobe Illustrator’s built in symbols). The first block in our shape is the block in the top-left. Every block in our shape is next to its predecessor and successor. The last block in the shape is the bottom-left block. This is what a real login screen from the server would resemble:

To login, all you have to do is look at Figure C, a copy of the grid directly above with our shape overlaid on top. In our shape, the 1st, 3rd, and 4th blocks are 1 (top-left), 3 (center), and 1 (right-center), respectively. Next time you login, they may ask you for the 2nd, 3rd, and 6th blocks in your shape and may use the randomly generated numbers in Figure D instead. Neither people looking over your shoulder nor keylogging software will know your shape because you have only used a subset of all the blocks in the the shape and because each number is in the grid more than once.

Now, for this 3×3 grid, it is not terribly hard to deduce the shape based on a few inputs; however, if the size of the grid were 20×20 or 40×40 and the shape were 10 blocks instead of 7, the time and inputs required to deduce the shape would increase at an increasing rate. What does this curve look like? Well, I’m way too busy/lazy at the moment to do the math, but some day I intend to get around to it.

This last solution is just one solution to authentication that is not traditionally used. There are many untraditional solutions waiting out there to be discovered. The mechanism of authentication often relies on humans; therefore, we must develop methods that better appeal to our lazy, forgetful, stupid minds. People remember shapes and phrases better than they remember random combinations of characters, numbers, and symbols. So security experts and psychologists, figure it the fuck out.

Hashing For Humans: Making Strong Passwords You'll Remember

Wed, 17 Mar 2010 00:00:00 -0400

Chances are you have an online account on multiple web sites. It’s going to be a long time (maybe forever) before authentication is standardized across the web. How do you remember all those passwords?

Hashing for Humans

Hashing is basically a technique used to take something complex or widely varying and create an ordered index for it. That’s an oversimplification, but it will do. Read the wikipedia article if you’re interested.

If you use a simple, mental hashing algorithm to create passwords on websites, you…

won’t have to worry about your other password(s) when one of them is compromised
won’t have to write down your passwords
will be able to have a strong, unique password for every site you visit

So the easiest way to do this is to go to the login screen of a website. As an example, look atgmail.com.

To make a unique password, you need some input from the website itself. And since you’ll see this page EVERY TIME you login, you won’t look stupid when others are watching as you try to ‘remember’ your password. As input, it’s easiest to take the (1) URL, (2) Page Title, or (3) the text around the username/password box. In this case, the page title and domain are basically the same [“Gmail…” and “gmail.com”]. Let’s go with that.

You want to use a hashing algorithm that is easy to remember. So, for example, we could make the first step of the algorithm to take domain name and spell it backwards. This gives us “liamg” or “moc.liamg”, in this case.

Next, we should add numbers, symbols, and capitals to our algorithm to make it stronger. One way to do this is to introduce leet, a way of visually replacing letters and syllables as numbers and symbols. “Magazine” can be “M@g@z1n3″, and “skullHunter” can be “5k0lHun73r”.

If that’s too much for you, you can prefix or append numbers/symbols to your website input. For gmail, we can have “liamg” become “%%LIAMG”. Here, I’ve introduced ‘%’ because “gmail” has 5 letters and ‘%’ is the alternate symbol associated with the ’5′ key on the keyboard. And let’s put two of them, just to boost the length. So far, our algorithm is like this:

Write the name of the site backwards, in all caps: “LIAMG”
Count the length of the password so far and prefix the symbol that corresponds with that length/number on the keyboard, twice: “%%LIAMG”

That’s not too hard, considering it’s all you have to remember for ALL your accounts. The more steps you add to your algorithm, the harder it gets to guess (don’t add too many steps to the algoritm).

NOTE: While probability-wise, we are under the assumption that the guesser is just as likely to try “liamg” as they are “liam6″, YOU are more likely to remember “johnny8pea” than “johnnyypea”—especially if you’re visual person like me. Also, this will protect you from word-dictionary attacks.

Remember, don’t choose algorithms that are self-evident. If you are on gmail.com and your password is “gmail123″, this might indicate that your password on twitter.com is “twitter123″ or “twitt123″. Don’t make it too easy, just in case randomcrappysite.com suddenly becomes compromised and your information gets phished.

You can use some of the following algorithms as a starting point and then vary them slightly if you’re not very creative (these are all based on “gmail.com”):

Write the last syllable of the website backwards: “liam”
Replace each series of vowels with the series’ length: “l2m”
Lather, rinse, repeat for the rest of the title: “l2mg”
Replace each number with the first letter of the English spelling for that number: “ltmg”
Append @s until you’ve reached the desired length: “ltmg@@@@”

Write the first two letters of the last syllable backwards: “am”
Append the last two letters of the first syllable: “amg”
Add the prefix “n.n”, where ‘n’ is the length of the password so far: “3.3amg”
Append the same ‘n’, plus 1: “3.3amg4″
Replace the first number with its corresponding symbol on the keyboard: “#.3amg4″
Add @s as needed: “#.3amg4@”

Write a prefix for your passwords: “335″
Append the first five characters of the website: “335gmail”
Replace all letters that go under the word (‘g’, ‘q’, ‘y’, ‘p’, etc) with ’3′: “3353mail”
Replace all remaining small letters (‘w’, ‘e’, ‘r’, ‘u’, etc) with ’2′: “335322il”
Replace all remaining letters with ’1′: “33532211″

It is very easy if you choose an algorithm that allows you to simply read the input forwards or backwards once, and be done. All the ones I’ve listed here can be done this way, once you understand the algorithm.

Visual rules based on character heights, as used in the last algorithm listed above, are very effective too. Just watch out for font changes!