Travel-related tech

I recently took a trip, and here are a few notes about some of my technology-related experiences.

I knew I'd probably want Internet access at the hotel, but I figured it would be wireless, and I was hoping for some kind of VPN. In the past I've used ssh's socks proxy feature, but I've found it to be pretty slow. So I thought I'd give wonderproxy a try. You can get a VPN account for a month for around $5, and I thought it worked really well. It was fast, and it made me feel a little better about using the hotel's wireless.

I bought a Macbook Air not long ago, and I like it. So I took it with me on the trip. I took some pictures, and I used iPhoto to copy the pictures off the camera onto the laptop. Then I tried using iPhoto to upload the photos to flickr, and that didn't work well for me. iPhoto crashed at one point during an upload of a bunch a photos, and there was no obvious way to resume the upload. I was able to figure out where it quit, and then I just told it to upload the photos it missed. But many of the photos on flickr don't have the original size--the largest version of many of them is 1024x768 (there should be three larger sizes). So I have to upload those images again or just be OK with the smaller sizes on flickr. So I'm glad I hadn't told iPhoto to delete them off the camera.

I also told iPhoto to mark several of the photos as private, and they ended up as public on flickr.

So I probably won't be using iPhoto any more.

And although southwestvacations.com did a great job of booking the trip, they totally FAIL in password security. When I created the account, I used a password generator to create a long password with all four character classes, and I saved the password in my password wallet. At one point during the trip, I needed to access something in my account. But when I tried to log in, I got invalid username/password errors. I ended up using the "forgot my password" link, thinking it would send me a login token. Nope, it sent me my password. It wasn't even my original password (which is why I was having trouble logging in). The original was around 20 characters long, but what they sent me was the first 10 characters of the password I'd created. So southwestvacations.com

• restricts password complexity (they truncated my password at 10 characters--the 11th was a percent sign, so I don't know if it was the length or the character)
• they truncated my password without warning me
• they store non-hashed passwords
• and they'll send passwords by email

FAIL.

Otherwise, it was a lovely trip. Have a look, if you like.

shadow passwords with openssl

I once had to break in to a CentOS box, because I'd forgotten root's password and didn't know the passwords to any other users (I think it had been shut down for a while). So I booted with a rescue disc (I think it was a CentOS installation disk, and I typed "linux rescue" at the prompt). The rescue disc mounted the filesystems, and I tried running passwd in a chroot. I got some kind of error message, and it wouldn't reset the password for root in /etc/shadow on the filesystem. I ended up editing /etc/shadow by typing in a password I got out of /etc/shadow on another box.

As I'm writing this, it occurs to me that if I knew the password to some other user (at this point I don't remember if I did or not), I could have just edited /etc/sudoers to give root to that other user, rebooted, logged in as that user, and done "sudo passwd" to reset root's password.

But if you ever need to create /etc/shadow entries by hand for some weird situation, here are a few suggestions involving openssl's passwd utility.

Incidentally, if you have trouble finding the man page for openssl's passwd ("man passwd" is likely to get you the man page for thing that resets your login password), try "man 1ssl passwd" (Ubuntu) or "man sslpasswd" (Red Hat 5).

The hashed passwords in /etc/shadow look something like this:

$1$.oDCRZmb$mYZm6IzfMWVfe38Pr4fHt0

The shadow entry has three parts delimited by dollar signs. The 1 indicates that this shadow entry was computed with the MD5 password algorithm. The next section (".oDCRZmb") is the salt, and the final portion is the hashed password.

You can generate these yourself. If you type the following (the "-1" requests the MD5 algorithm)

echo password | openssl passwd -1 -stdin

you should get something resembling

$1$DcuakEM4$c4WDkEXKd6YXNYjAfN2Sh/

You can reproduce this by providing the salt:

carl@stilgar:~$ echo password | openssl passwd -1 -stdin -salt DcuakEM4
$1$DcuakEM4$c4WDkEXKd6YXNYjAfN2Sh/

And it looks like openssl is smart enough to strip the newline:

carl@stilgar:~$ echo -n password | openssl passwd -1 -stdin -salt DcuakEM4
$1$DcuakEM4$c4WDkEXKd6YXNYjAfN2Sh/

Without the "-1" argument, openssl uses the standard crypt algorithm. The first two characters from crypt output are the salt, and this is what the Apache webserver's htpasswd uses for making passwords (at least, crypt seems to be the default algorithm for the Ubuntu and Red Hat 5 packages):

carl@stilgar:~$ echo password | openssl passwd -stdin
BxZPctq22eZ4M
carl@stilgar:~$ echo password | openssl passwd -stdin -salt Bx
BxZPctq22eZ4M

passwd also knows the Apache variant of the MD5 algorithm:

carl@stilgar:~$ echo password | openssl passwd -apr1 -stdin
$apr1$z4cUIQjr$fXbDk6ypzyZIIIb/OIp0I.
carl@stilgar:~$ echo password | openssl passwd -apr1 -stdin -salt z4cUIQjr
$apr1$z4cUIQjr$fXbDk6ypzyZIIIb/OIp0I.

Looks like Ubuntu uses the sha-512 algorithm for hashing passwords, and openssl's passwd doesn't support this. If you want to try making /etc/shadow entries w/ sha-512, try saving the following file as passwd.c:

#define XOPEN_SOURCE
#include 
#include 

int main(int argc, char *argv[]) {
    if ( argc < 2 ) {
        printf("usage: %s password salt\n", argv[0]);
        return;
    }
    printf("%s\n", (char *)crypt(argv[1], argv[2]));
    return;
}

And then try this:

gcc -lcrypt -o passwd passwd.c
./passwd password '$6$salt$'