USB security keys

[Robert O'Callahan]

http://googleonlinesecurity.blogspot.co.nz/2014/10/strengthening-2-step-verification-with.html
We should support this.

Rob
--
oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo
owoiotoho oao oboroootohoeoro oooro osoiosotoeoro owoiololo oboeo
osouobojoeocoto otooo ojouodogomoeonoto.o oAogoaoiono,o oaonoyooonoeo
owohooo
osoaoyoso otooo oao oboroootohoeoro oooro osoiosotoeoro,o o‘oRoaocoao,o’o
oioso
oaonosowoeoroaoboloeo otooo otohoeo ocooouoroto.o oAonodo oaonoyooonoeo
owohooo
osoaoyoso,o o‘oYooouo ofooooolo!o’o owoiololo oboeo oiono odoaonogoeoro
ooofo
otohoeo ofoioroeo ooofo ohoeololo.

[Ehsan Akhgari]

On Tue, Oct 21, 2014 at 4:08 PM, Robert O'Callahan <rob...@ocallahan.org>
wrote:

>
> http://googleonlinesecurity.blogspot.co.nz/2014/10/strengthening-2-step-verification-with.html
> We should support this.

Agreed. There's https://bugzilla.mozilla.org/show_bug.cgi?id=1065729 filed
for this...

[Richard Barnes]

> On Oct 21, 2014, at 4:08 PM, Robert O'Callahan <rob...@ocallahan.org> wrote:
>
> http://googleonlinesecurity.blogspot.co.nz/2014/10/strengthening-2-step-verification-with.html
> We should support this.

Maybe I'm just jaded, but given that we're currently in the process of phasing out custom APIs for one specialized hardware platform, I'm not super enthusiastic about adding support for another one.

There's a conversation going on between some folks in the platform security and FxOS security teams working on an overall strategy for secure hardware, so that we don't have to cut fresh code every time someone comes up with a new identity scheme. We will hopefully have something baked enough to share around soon.

Note that that blog post glosses over a couple of important details of the Chrome implementation. First, it's non-native; it's a bundled extension, like Flash. And second, it's only enabled for google.com, so it's not really a web-facing feature.

--Richard

> Rob
> --
> oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo
> owoiotoho oao oboroootohoeoro oooro osoiosotoeoro owoiololo oboeo
> osouobojoeocoto otooo ojouodogomoeonoto.o oAogoaoiono,o oaonoyooonoeo
> owohooo
> osoaoyoso otooo oao oboroootohoeoro oooro osoiosotoeoro,o o‘oRoaocoao,o’o
> oioso
> oaonosowoeoroaoboloeo otooo otohoeo ocooouoroto.o oAonodo oaonoyooonoeo
> owohooo
> osoaoyoso,o o‘oYooouo ofooooolo!o’o owoiololo oboeo oiono odoaonogoeoro
> ooofo
> otohoeo ofoioroeo ooofo ohoeololo.

> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform

[Ehsan Akhgari]

On Tue, Oct 21, 2014 at 4:46 PM, Richard Barnes <rba...@mozilla.com> wrote:

>
> > On Oct 21, 2014, at 4:08 PM, Robert O'Callahan <rob...@ocallahan.org>
> wrote:
> >
> >
> http://googleonlinesecurity.blogspot.co.nz/2014/10/strengthening-2-step-verification-with.html
> > We should support this.
>
> Maybe I'm just jaded, but given that we're currently in the process of
> phasing out custom APIs for one specialized hardware platform, I'm not
> super enthusiastic about adding support for another one.
>

Which specialized hardware platform is that? Also, don't the FIDO Alliance
specs cover more than just one platform?

> There's a conversation going on between some folks in the platform
> security and FxOS security teams working on an overall strategy for secure
> hardware, so that we don't have to cut fresh code every time someone comes
> up with a new identity scheme.

I doubt that's what roc was suggesting. But it's hard to say more without
more details on the said overall strategy.

> We will hopefully have something baked enough to share around soon.
>
> Note that that blog post glosses over a couple of important details of the
> Chrome implementation. First, it's non-native; it's a bundled extension,
> like Flash. And second, it's only enabled for google.com, so it's not
> really a web-facing feature.
>


--

Ehsan

[Doug Turner]

>
> I doubt that's what roc was suggesting. But it's hard to say more without
> more details on the said overall strategy.
>

I think this is an interesting idea and we should look into how much effort it is to add support for this usb security key.

And, I think we can go a long way in fixing the password problem without having to depend on custom hardware. I’d like to see us invest in fixing/improving our built-in password manager and autofill in Firefox. Many 3rd party password managers have made huge strides in reducing the friction of creating unique high-entropy passwords without relaying on custom hardware. I use such a product and it is a game changer — I don’t know any of my password but the master password.

So maybe before we write code to support a new token, we figure out what the Firefox plan around password management is?

[Chris Peterson]

On 10/21/14 8:28 PM, Doug Turner wrote:
> And, I think we can go a long way in fixing the password problem without having to depend on custom hardware. I’d like to see us invest in fixing/improving our built-in password manager and autofill in Firefox. Many 3rd party password managers have made huge strides in reducing the friction of creating unique high-entropy passwords without relaying on custom hardware. I use such a product and it is a game changer — I don’t know any of my password but the master password.
>
> So maybe before we write code to support a new token, we figure out what the Firefox plan around password management is?

btw, neither LastPass nor 1Password are e10s-compatible, which is a big
risk for Firefox users. (See bugs 1008768 and 1042195, respectively.)

Passwords are a major usability hassle and security risk. Password leaks
even make mainstream news. Mozilla could be leading in this space with a
strong story around password management that regular users could
understand. And with Firefox Account integration between desktop and
Android, it could be an opportunity to upsell Android users on Fennec.


chris

[Jonas Sicking]

On Tue, Oct 21, 2014 at 8:28 PM, Doug Turner <do...@mozilla.com> wrote:
>>
>> I doubt that's what roc was suggesting. But it's hard to say more without
>> more details on the said overall strategy.
>>
>
> I think this is an interesting idea and we should look into how much effort it is to add support for this usb security key.
>

> And, I think we can go a long way in fixing the password problem without having to depend on custom hardware. I'd like to see us invest in fixing/improving our built-in password manager and autofill in Firefox. Many 3rd party password managers have made huge strides in reducing the friction of creating unique high-entropy passwords without relaying on custom hardware. I use such a product and it is a game changer -- I don't know any of my password but the master password.

>
> So maybe before we write code to support a new token, we figure out what the Firefox plan around password management is?

The spec here could help a lot with improving the password/login situation.

http://mikewest.github.io/credentialmanagement/spec/

It does a few things as currently drafted. One of which is to allow
websites to more explicitly interact with our password manager. It
currently only covers the case of getting a username+password to log
the user in, but the plan is to extend it to also cover the case of
generating a password to use for the website. With that we could
create very good integration with password managers like 1Password.

Another thing it does is to help with federated ID providers such as
facebook and firefox accounts.

What's really good about the spec though is that it solves the
chicken-and-egg problem that we've struggled with for a while. It
enables websites to do exactly what they are doing today but slowly
take advantage of features from the spec at whatever pace they see
fit. It also doesn't require federated ID providers to make any
changes in order work with the API.

The spec also provides a good first step towards getting the browser
more involved in the login flow. This could make it easier for us to
do things like add hardware tokens in the future.

/ Jonas

[Gavin Sharp]

Improved password management is one of the top-line initiatives that
we're currently discussing as a focus for Firefox in 2015, so you'll
probably hear more about it soon.

Gavin

[Jonas Sicking]

On Wed, Oct 22, 2014 at 2:04 PM, Gavin Sharp <ga...@gavinsharp.com> wrote:
> Improved password management is one of the top-line initiatives that
> we're currently discussing as a focus for Firefox in 2015, so you'll
> probably hear more about it soon.

That's great to hear! We should definitely try to improve it as much
as we can within the current constraints of what the web platform
provides (i.e. mainly automatic form-fill). But it'd be great, both
for web developers and users, if we tried to expand the capabilities
of the web so that we can build even better experiences.

Is that option being considered too?

/ Jonas

> Gavin
>
> On Tue, Oct 21, 2014 at 9:03 PM, Chris Peterson <cpet...@mozilla.com> wrote:

>> On 10/21/14 8:28 PM, Doug Turner wrote:
>>>
>>> And, I think we can go a long way in fixing the password problem without
>>> having to depend on custom hardware. I'd like to see us invest in
>>> fixing/improving our built-in password manager and autofill in Firefox.
>>> Many 3rd party password managers have made huge strides in reducing the
>>> friction of creating unique high-entropy passwords without relaying on

>>> custom hardware. I use such a product and it is a game changer -- I don't

>>> know any of my password but the master password.
>>>
>>> So maybe before we write code to support a new token, we figure out what
>>> the Firefox plan around password management is?
>>
>>
>> btw, neither LastPass nor 1Password are e10s-compatible, which is a big risk
>> for Firefox users. (See bugs 1008768 and 1042195, respectively.)
>>
>> Passwords are a major usability hassle and security risk. Password leaks
>> even make mainstream news. Mozilla could be leading in this space with a
>> strong story around password management that regular users could understand.
>> And with Firefox Account integration between desktop and Android, it could
>> be an opportunity to upsell Android users on Fennec.
>>
>>
>> chris
>>