Jun 152011
 

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 a 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 into 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 the undesirably fast 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.

UPDATE 2012-05-19: PassPack does not store your packing key on their servers afterall. (LastPass does not either, nor does Clipperz.) But you still must trust them, as they are in a position to insert backdoors into either the browser add-ons or web-based access they provide. This is less of an issue with ClipperZ, since you can run the Community Edition on your own hardware. Some brief comparisons here and here. Also there is some interesting discussion in the comments of the previously linked PassPack critique. Gabriel Weinberg has LastPass amongst his list of services used at DuckDuckGo. LastPass did possibly have a data breach, but they handled it well. Some more details on PassPack’s packing keys and master keys.

Jun 052011
 

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!