The thing is for your personal bank account a 15 character password is acceptable.
But for x many customer credit card details you're really looking for a much longer password that that. I'm talking 64 characters or more of pure random data.
You shouldn't be compromising for the convenience of being able to remember a password when it secures such critical data in my opinion.
Edit: I do agree though that your method is a very good way of remembering password.
So it's short enough to remember and likely has some sort of pattern. There's a limit to what a person can remember, lower if there are several people that have to remember it.
That's just their small device (NEO). I have two of their normal sized one that I use for several sites already for 2-Factor. The YubiKeys are actually pretty robust and safe enough to keep on a keyring.
The key to this is to still require something that you remember like your username (and/or a password), they will get stolen and it is too risky for these tokens to be the only authentication factor.
As long as users are educated that these tokens should in all ways be considered a set of keys then security can only be improved with them.
I understand that there is an expectation for Nokia to resolve this concern in some manner, but why do endpoint sites not simply block requests from the proxy?
I mean if I was a bank it'd properly be in my interest to protect my customers from using a known insecure proxy (regardless of who manages it).
The focus is on enabling others to easily develop their own checks/reviews.
I'll be looking at adding Mercurial and SVN support in the near future.
Would love to hear any feedback you might have.