password

For the past decade or so, I've been working to automate as much of a Jenkins server build process as possible. There are a few 'hacky' bits to doing so, like managing some Jenkins XML files (or if you really want to go crazy, storing your entire $JENKINS_HOME somewhere in a source control repository!).

One of the most annoying things about automating Jenkins is using the jenkins-cli.jar file to interact with Jenkins on the CLI. It doesn't come with any automated solution for authenticating with Jenkins, and is meant for running either on the same server where Jenkins is running, or really anywhere that has SSH access. I generally don't like putting any Jenkins bits (including the CLI tool) on servers outside the actual Jenkins instance itself, so I've traditionally used the --username and --password method of authenticating with jenkins-cli.

However, it seems those CLI flags were deprecated and removed at some point in the past few months (maybe around 2.130 or so?), and now I get the following error when running CLI commands that way:

From time to time, I use the incredibly powerful Migrate module to migrate a subset of users from one Drupal 7 site to another.

Setting up the user migration class is pretty straightforward, and there are some great examples out there for the overall process. However, I couldn't find any particular documentation for how to preserve user passwords when migrating users from D7 to D7. It's simple enough to set the 'md5_passwords' boolean for Drupal 6 to Drupal 7 user migrations, so passwords will be updated when a user logs in the first time on the D7 site... but it's not as straightforward if you want to simply move the salted/hashed passwords from D7 to D7.

During the migration, when the user account is saved, Drupal will re-salt and re-hash the already-hashed-and-salted password you pass in through your field mappings, and users will have to reset their passwords to log in again.

To override this behavior, you need to implement the complete() function in your user migration, and manually overwrite the just-saved user account password field:

If you use Mac OS X, add the following line to your .bash_profile:

Whenever you need a password (like when you're registering a new account or resetting your password because yet another online service you used was hacked), just fire up the Terminal and type in passme. Then paste the password that's copied to your clipboard into the password fields, and into your password manager (I use 1Password).

This alias simply uses openssl to generate a random base64-encoded string with 48 characters (you can change that value to whatever you want). If the online service you use doesn't allow 48 characters in the password field, you should file a support request with that online service, telling them they're being silly only allowing X characters in a password.

In light of the many high-profile hacking cases that have recently exposed millions and millions of user passwords (LinkedIn, Sony, etc.), I thought I would write down my password management practices, and some practical thoughts for others looking to secure their access to various online services.

Shared Passwords (major no-no)

For a long time, I had three passwords: a weak, eight-character password that I'd use on forums and places I didn't really care about. I had a ten-character password with a number, a capital letter, and a symbol, for medium security (like sites that had my credit card in my account). And I had a fourteen-character password which was truly random (generated by Keychain Access on my Mac) for a couple services that I needed to be extremely secure.

But, none of these passwords are truly adequate nowadays—especially since I reused the passwords on a variety of sites and services! Additionally, I often had trouble remembering which password I used on what site, and had to try all three before successfully logging in.

[Update: Back when this was written, very nice password managers like 1Password and LastPass didn't exist or were not very capable of managing passwords as well as they are today—please ignore the advice below and use a password manager to generate very long, random passwords, and use the password manager instead of memorizing anything.]

Every month or so, another scary story about a huge security compromise (a.k.a. a hack) surfaces on the Internet, and this month is no exception. Earlier this month, the whole Twitter corporate heirarchy had a lot to worry about, as a hacker (that's kind of a misnomer... hackers are usually nothing more than persistent, patient and sly computer users) accessed many Twitter employees' email, iTunes, Google, etc. accounts, all because of the fact that one of the employees (probably not the only one, though) left an open door via a few small missteps, security-wise.

The hacker, after gathering tons of personal information gleaned from all over the web, was able to recover a user's Gmail password by guessing a few personal questions Gmail asks on the password recovery form (i.e. "Who was your favorite actor?," "What is your maiden name?," etc.). Then the hacker simply searched through the user's emails for something like "username password," because he knew that a lot of websites (like the Joomla! forums, some gaming sites, online stores, etc.) simply send an email upon a new user registration that contains the person's username and password. Once the hacker got ahold of a few more passwords this way, he was on his way to 'hacking' all the user's accounts... because like most people online, the user had only one or maybe two passwords he used for everything.

...but using the same password for multiple sites/services isn't necessarily a bad thing. Not if you follow these steps: