Google safing passwords

Apparently, lots of places on the net, prominently including all WordPress blogs, use unsalted hashes for password verification, i e you get to log in if hash(given password) == hash stored in the password database; commonly using cryptographic hash functions like MD5 or SHA1. If that password database leaks, people can fairly effortlessly use Google as an O(1) lookup function from hash to plaintext, for most weak passwords.

The problem is easily avoided by using salted passwords -- i e hashing the password concatenated with a random component, say 32 bits long, and storing this salt next to the hash, in plaintext. Net effect: your password database, if compromised, will not be susceptible to the same attack, as the search space is 4,294,967,296 times as large, making it less likely that Google knows how to reverse map the hash for you.

I whipped up a quick tool to see whether a password is susceptible to the Google lookup or not (for MD5 and SHA1, and optionally, whether the plaintext password itself is found on the web too, though I discourage using it for reasons of potential snooping of your traffic). The hack uses some neat client side tools to query Google's Searchmash, using Yahoo! Pipes to decorate its JSON result with the JSONP callback they apparently lack (Google unfortunately still rarely gets that right), and some micro-libraries I've started accumulating recently:

Sample Google for a password dictionary attack on:

Check the checkbox to query google for the plaintext version of your prospective password, and not just cryptographic hashes of it. (Anyone snooping your, Google's or Yahoo's network traffic, will see it.)

User scripting new GMail messages

With the recent change in how GMail works, lots of prior user scripts improving the service, like a small hack that removes <font size="+1"> tags from mails broke, in the wake of the DHTML improvements (which make the site more difficult to augment via user scripting).

The GMail developers, generously, were not very far behind to release a smallish Greasemonkey API, somewhat alleviating the problem -- but it still is less than trivial to target mail bodies with your user scripts.

I took a stab at it the other night, to figure out what would go into it, and managed to come up with a new font manhandler (it targets a rather local nuisance on the Greasemonkey mailing lists). As I have been trying out MailPlane for a while for reading my mail I decided to see if I could make the script run both in Firefox on Greasemonkey and Safari/WebKit/MailPlane on the GreaseKit user script manager. That turned out quite doable. The script, in its entirety:

// ==UserScript==
// @name           Gmail - deBill:ifier
// @namespace      http://code.google.com/p/ecmanaut/
// @description    Manhandles all font size tags to stop all the yellin'
// @include        https://mail.google.com/*
// @include        http://mail.google.com/*
// ==/UserScript==

window.addEventListener("load", loader, false);

function loader() {
  var api = typeof unsafeWindow != "undefined" && unsafeWindow.gmonkey ||
    (frames.js ? frames.js.gmonkey : null);
  if (api) api.load("1.0", init);
}

function init(gmail) {
  function viewChanged() {
    var view = gmail.getActiveViewType();
    if ("cv" == view) {
      var div = gmail.getActiveViewElement();
      div.addEventListener("DOMNodeInserted", deBill, false);
    }
  }
  gmail.registerViewChangeCallback(viewChanged);
}

function deBill(event) {
  var font = event.target.getElementsByTagName("font");
  for (var i = 0; i < font.length; i++)
    font[i].removeAttribute("size");
}

Feel very free to base your own hacks on the recipe. I recommend starting out with an action function that does something basic like setting event.target.outline = "1px solid red", to see where it does what it does -- since the callback runs for every conversation view change, including updates to the ad pane on the right, not only when expanding mails you read.