Using a bookmarklet to store passwords is appealingly simple. Alas, after doing some digging, I couldn’t find any viable options.

The first concern I came across is that it is important to use a hash algorithm that’s slow (e.g. bcrypt or scrypt). Otherwise it’s too easy to brute-force the master password based on a site password. Suppose site you visit stores your password in plaintext and gets hacked. That breach then compromises your master password, even though only your site-specific password was revealed.

I couldn’t find a JavaScript implementation of scrypt, but I found a JavaScript bcrypt implementation. Better yet, I found a derivative that tidies up the first one, removing dependencies on e.g. ClipperZ, and wraps it in a simple bookmarklet. SuperGenPass provides a much more user-friendly bookmarklet, so I started gearing up to replace it’s MD5 hashing with bcrypt.

But, alas, SuperGenPass (and any other simple bookmarklet) is not secure in the face of a malicious website that contains JavaScript designed to sniff entry of the master password in to the bookmarklet. PwdHash is a browser extension based approach from the Stanford Security Lab designed to combat the weaknesses of the bookmarklet based approach. Their paper, Stronger Password Authentication Using Browser Extensions, is interesting reading and explains a variety of ways to compromise a bookmarklet based approach. PwdHash has already spawned a number of ports to other browsers and mobile devices, but alas they’re all based on prototype code that uses HMAC-MD5 as the hashing algorithm (even though the paper points out PwdHash is a good candidate for a better hashing algorithm).

I was not able to find any PwdHash derivative that used bcrypt. I did find a simple command-line tool based on scrypt, but that’s not great if you don’t have easy access to your own computer.

Solutions like PassPack offer the potential to solve these problems (extension rather than bookmarklet, use of strong encryption rather than weak hashing), but have an Achilles heel of their own: the service provider has the power to decrypt all your passwords. For now I’ll stick with my moinmoin-client-crypt approach.

 

Quick refresher: self-types are commonly used when writing traits that want to proscribe that they get mixed in to a particular class. For example, the cake-pattern leverages them. In the example below, FooTrait specifies a self-type of FooTraitConfiguration to insure that it is mixed in to a class that provides the expected times val.

import actors.Actor
import actors.Actor._

trait FooTraitConfiguration { val times : Int }

trait FooTrait { self:FooTraitConfiguration =>
  case object Ping
  case object Pong

  val a = actor {
    loop {
      react {
        case Ping =>
          self ! Pong
        case Pong =>
          for(_ <- (1 to times)) { print(".") }
          System.out.println("pong.")
  } } }

  def ping = a ! Ping
  def pong = a ! Pong
}

class Foo extends FooTrait with FooTraitConfiguration { @Override val times = 5 }

But, alas, this fails to compile:

error: value ! is not a member of FooTrait with FooTraitConfiguration
self ! Pong

It seems that the self-trait has broken the Actor API! And indeed, it has. Because self-traits are not usually specified with self! It should have been:
this:FooTraitConfiguration =>

The self-type means that within FooTrait the type of this is considered to be FooTrait with FooTraitConfiguration. Using a word other than this additionally sets up an alias to that type for e.g. use within nested classes. And there’s the rub: Actors depend on a method named self which is shadowed when the alias to the type is named self.

Note to self: Don’t use self when specifying self types!

lankycoder blog © 2011-2012 by Lorrin Nelson Creative Commons License Blog content under CC BY-SA License. Code excerpts from larger projects may be available under more permissive license; see the project. Suffusion theme by Sayontan Sinha