[messaging] abusing u2f
tom at ritter.vg
Thu Mar 24 05:10:09 PDT 2016
On 24 March 2016 at 05:58, Michael Rogers <michael at briarproject.org> wrote:
> On 24/03/16 01:11, elijah wrote:
>> One additional security consideration is that for usability, we would
>> probably want the service provider to store the u2f key handle(s), so
>> that a user can sit down at a new computer with their password knowledge
>> and their previously registered u2f dongle and log in. If anyone with
>> the service provider's db then gets the u2f dongle, we are back to just
>> easy brute force attack against the password.
> I'm probably missing something, but it seems to me that if you're using
> the public key only as a (high entropy, easily disposed of) input to
> local key derivation, an ordinary flash drive with some random data
> would work just as well, with the same downsides that (a) anyone with
> access to both the encrypted data and the dongle/drive can brute force
> the password, and (b) malware on the device can record the public
> key/random data for later reuse.
> On the other hand, if you're using the dongle for that purpose and also
> as a second factor for logging into the server, you're sending the
> public key over the network so it's no longer secret - the server knows
> it at least. So it seems to me (and again, I've probably totally
> misunderstood what you're suggesting) that in this scenario you'd be
> strictly better off using a separate flash drive with random data for
> local key derivation, and saving the U2F dongle for logging into the server.
No that's right. The difference and advantage over the flash drive is
major browsers have an API for u2f today, and more (if not all!) will
in a few years.
More information about the Messaging