Disc Image – Why not to use a plain Dictionary Word

In the process of playing with backing up to disc images I wanted to play around how to automate the password entry. I may get into why in a future post. Whatever you do, do not use a plain dictionary word to secure your images. Here is why. I based it on the scripts I found at: http://ask.metafilter.com/47171/How-to-crack-a-disk-image

Modified and tested. Worked like a champ when I added my chosen password to a dictionary text file of words. In the below example I used a path to where I have a large collection of dictionary files used for password cracking in forensics etc. This is not the fastest thing in the world but it works if the chosen password shows up in the word lists you throw at the image.

#!/bin/bash

for word in $(cat /Volumes/ExternalDrive/Dictionaries/test.txt | grep -v “#”)

do

echo -n $word | hdiutil attach /Volumes/iPod/Backup/Backup.sparseimage -stdinpass

if [[ $? = 0 ]]

then

echo “Password found!”

echo $word

exit 0

fi

done

echo “password not found :(”

exit 1

Share

An iGotcha from iGet

I found out one more thing.  iGet is hard coded to the default filename id_rsa for the private key.  Save that with no passphrase in your .ssh folder and iGet will recognize the key and use it.  Nothing else I could do worked.  Even changing the name to iGet from id_rsa so I could recognize the key as being the unsecured key for iGet would not work.   These guys really ought to take a page from Cyberduck.

Share

When does 2 = 1 ?

Talk about the wrong way to make a piece of software. I was helping a friend get iGet working with his mac. We did not want to leave SSH running on port 22. It was getting hit with all sorts of brute force user guessing attacks. Here are some examples

Sep 4 09:29:27 sshd[13637]: Invalid user admin
Sep 4 09:29:37 sshd[13641]: Invalid user stud
Sep 4 09:29:45 sshd[13643]: Invalid user trash
Sep 4 09:29:51 sshd[13645]: Invalid user aaron
Sep 4 09:29:56 sshd[13647]: Invalid user gt05
Sep 4 09:30:00 sshd[13649]: Invalid user william
Sep 4 09:30:03 sshd[13651]: Invalid user stephanie
Sep 4 09:30:40 sshd[13664]: Invalid user gary from
Sep 3 16:51:06 sshd[10423]: Invalid user nagios
Sep 3 16:51:07 sshd[10425]: Invalid user backuppc
Sep 3 16:51:09 sshd[10427]: Invalid user wolfgang
Sep 3 16:51:10 sshd[10430]: Invalid user vmware
Sep 3 16:51:13 sshd[10432]: Invalid user stats
Sep 3 16:51:14 sshd[10434]: Invalid user kor
Sep 3 16:51:15 sshd[10436]: Invalid user wei
Sep 3 16:51:16 sshd[10438]: Invalid user cvsuser

Also we wanted to fix up public key authentication instead of passwords. So we used his Apple airport extreme to map an external port say 3622 to 22 on his Mac in his home network. Then we whipped up public-private key pair. “ssh-keygen -t rsa” was good enough to do that. We of course put a good strong passphrase on it.

Now things like iTerm and Cyberduck on the mac worked great with his new setup. Both the port and the private key. But he has this thing called iGet. It claims key support. But I did let it work with key authentication if the private key had a passphrase. So we had to whip up a second keypair just for that program and append the new public key to his authorized_keys file in his .ssh folder. The worst part is the vendor tried to say that using keys is not inherently more secure than a password because iGet just uses SSH to start the connection then takes over with its own protocol. How stupid. And such a bad attitude. Cyberduck is free and it works way better on key support. Sure iGet has some neat features like access to the remote machine’s spotlight etc. But kiss that advantage goodbye once Leopard comes out. But personally I would not give iGet my money for their product with that attitude and poor private key with passphrase support. By default keys get dumped right into your .ssh folder on a Mac. If there is no passphrase and someone somehow runs code that lets them grab the entire folder contents they would have your access into machines via SSH. At least if it has a passphrase they still have to brute force the key just to use it.

After all it is not two factor authentication if it is just a key without a passphrase.  Its one factor.  Something you have.  Adding something you know (the passphrase) greatly improves the security so in the world of iGet 2=1.

Share

Paypal + Verisign PiP Token

I came back from Birmingham today to find my Paypal security token arrived yesterday.  It came with a nice instruction card on how to add it to your Paypal account.  Only problem it’s wrong.  I tried going to the Token link and logging it.  It did not take me straight to adding the key.  I had to go into my account page then clicking the link to the security key.  From there it is straight forward to add it.

As an added bonus.  If you use Verisign PiP for OpenID you can add the same token to logon authorization there as well.   Then all you do is go to your account details.  Click the Add Credential.  It wants two fields to be filled in.  The top one is the code on the back of your Paypal security token.  The long number over the barcode, the token’s serial number.  The second field is a keycode from the token.  So flip it back over and press the button.  Enter the displayed six digit number into the second field and submit.

Now when you log into Paypal or Verisign PiP you have to know your logon name, password AND the six digit number on your token at the time you sign in.  There is a slight difference in how you enter it though.  On Paypal, append the six digits to your password when you type in your password.  On Verisign logon as normal and it will prompt you for the six digit code after you submit your name and password.

That is it.  Now you have two factor authentication.  Your password (something you know) and  the code the security token provides (something you have).  Without the token your accounts cannot be used.

Share

Passwords: Writing them down

I noticed over on Andy the ITGuy’s blog a post about writing down passwords. I agree completely that passwords should be recorded in a work environment. They are the property of the company as much as any piece of hardware or software. How you write them down and handle them is very important though.

Here is what we do. We keep all our sensitive passwords in an excel spreadsheet in our IT area on our file server. The folder is locked down tightly with group permissions to just the IT group. Next we turned on file and object auditing on the passwords subfolder in that area. Toss in Snare for Windows that sends all the object audit events to my kiwisyslog box. The file is encrypted via PGP. Keys of the local IT staff plus the key of a backup person in our corporate office are used. Finally the kiwisyslog sends its events to a mySQL database so I can run reports whenever I wish. This way I can tell exactly who goes into the folder and decrypts the file any time. The staff just deletes the file once done looking up the password they need.

You cannot just rely on domain permission lockdown alone. What happens if someone gets elevated privileges without authorization. So this is why we use PGP. Only people whose keys were used can get into the file should they even reach it.

Another advantage of using excel. If you rotate passwords you just make a new tab, copy the current tab into it and name the tabs appropriately. Over time you will have an entire history of all your previous passwords. This is important in larger environments where you may not have changed passwords on all equipment like you thought. You can look up older passwords to try without locking yourself out just because no one is around that remembers passwords from months or years ago.

Lastly, print a copy. Whenever we change any passwords we print a new copy of the entire excel workbook. Proper header-footers are set so we can tell which pages are older passwords. Next we seal that in an envelope signing and dating across the seal. Finally we drop it in a fire resistant safe.

Between these methods you have easy access to password lists, a secured electronic copy, the secured copy gets backed up with all other server based data and lastly a hard copy in case the backups or server is unavailable.

All this can still work in a smaller environment. Just that the backup key used to encrypt the file is likely to be a company officer than a second IT person.

Share