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
_______________________________________________
Qi Hardware Discussion List
Mail to list (members only): [email protected]
Subscribe or Unsubscribe:
http://lists.en.qi-hardware.com/mailman/listinfo/discussion
