Fwd: Re: password safe / mouse (was Re: What's the real problem with wireless on the Ben?)

Bas Wijnen wijnen at debian.org
Fri Sep 16 14:53:33 EDT 2011


On 16-09-11 20:05, Werner Almesberger wrote:
> Bas Wijnen wrote:
>>> Of course, this could easily encompass solutions that
>>> include a password on top of something else, e.g., the kind of
>>> challenge-response authentication with a "pocket calculator" better
>>> banks use.
>>
>> The Ben could well be used for that. Actually, it can be much
>> better, because it can input a 200-character code instead of a
>> 6-digit one.
>
> Ah, but for this you'd have to get the bank or whatever to cooperate
> on the authentication mechanism. Don't expect this to happen before
> you've already sold a few tens of millions devices :)

I was actually thinking of other sites using this. I'm not expecting 
banks to disclose the algorithm of those devices they use, because I 
think they still believe in security through obscurity. :-(

>>> Comfort removed an impediment to the use of longer and more cryptic
>>> passwords (harder to brute-force, if Eve gets her hands on the
>>> password hashes).
>>
>> That makes things a bit safer indeed. And with cryptographically
>> generated passwords, it even makes things real safe :-) But that
>> requires (web)server-side support,
>
> Naw, you can keep it simple. Say, integrate a password generator.
> Pick length and structure. Since the Ben remembers the password for
> you, it can be "nasty". If you combine this with atusb-as-keyboard,
> you could even go as far as never intentionally revealing the
> password the user. (The user could of course extract it easily.)

Hmm, and if you encrypt the atben-atusb link (which requires no external 
cooperation, but does require a custom "encrypted keyboard" driver on 
the desktop machine), you get rid of hardware keyboard sniffers as well. 
With a good OS, you can also guarantee the absence of software keyboard 
sniffers. So only a https link is still needed, and (almost) everyone 
already uses that for passwords. :-)

>> Conclusion, if you want this, write a firefox-plugin to support
>> public-key authentication and get big sites like facebook to use it
>> for their login system. :-)
>
> Hmm, step 1: get Mozilla to write a lot of press releases praising
> your project and announcing they're betting all their money on it.
> Step 2: see if anyone bites :)

That sounds like an even more viable strategy! Still I have some doubts 
about step 1...

>> But that's a path that you control and can change to suit your
>> needs. Also, this isn't a real issue. If you are worried about
>> people with sniffing devices for such an obscure protocol, then you
>> should definitely use something better than passwords for
>> authentication.
>
> You want to be success-proof. If the device catches on, then the
> protection of obscurity would vanish rapidly.

Of course.

> And you also want to
> avoid bad press that you may get via curious security researchers
> even before the crooks catch on.

It should of course be on the todo list from the start, and the design 
should support it. But it doesn't have to be a priority. Then again, 
setting up an encrypted link isn't actually hard, so there's no reason 
not to do it from the start. :-)

Thanks,
Bas




More information about the discussion mailing list


interactive