On 9/15/22 08:57, Stephen Smoogen wrote:
On Wed, 14 Sept 2022 at 18:36, Simo Sorce <simo(a)redhat.com>
wrote:
> On Wed, 2022-09-14 at 15:11 -0700, Adam Williamson wrote:
>> On Wed, 2022-09-14 at 10:25 -0500, Michael Catanzaro wrote:
>>>
>>> On Wed, Sep 14 2022 at 06:58:12 AM +0000, Tommy Nguyen
>>> <remyabel(a)gmail.com> wrote:
>>>> I'm not entirely convinced. See this paper:
>>>>
https://eprint.iacr.org/2020/1298.pdf
>>>
>>> I only read the abstract of this paper, but looks like the researchers
>>> have found that FIDO is indeed unphishable. Seems their attack relies
>>> on websites allowing downgrade to weaker forms of 2FA.
>>
>> Yup. The thrust of the paper is: in the real world FIDO2 is usually
>> deployed alongside older/weaker forms of 2FA, so an attacker can
>> pretend to the victim that FIDO auth didn't work and convince them to
>> try a weaker method instead, then phish that.
>>
>> Which is a reasonable point, but not necessarily relevant to us. We
>> *could* require only strong auth and not have weaker fallback methods.
>
> So I have been thinking about this, how do you deal with the inevitable
> fact that keys get lost or stop working if there is no alternative
> authentication method?
>
>
Inevitable is usually about 4 to 5 emails a week to admin(a)fedorproject.org
from someone unable to log in and saying they lost their phone, token or
other things. This is out of the couple hundred accounts currently with two
factor enabled.
Does that mean that individual 2FA devices last 200/5 = 40 weeks on average?
> I guess people can enroll 2 separate keys (if Feodra Infra will
allow
> that), but not everyone has the means to do that.
>
>
Basically the system would have to enforce that you have to have a GPG key
and verify that the system can decode a message from the person. Then all
that security is left to how many developers set their gpg password to
'123456' or 'password1' and then upload their secret keys to public
websites so it is convenient for them. From relevant experience with
Fedora, that number is non-zero.
Yeah, the only solution to *that* is a hardware token with remote
attestation. That allows one to ensure that the user could not reveal
their secret key even if they wanted to.
--
Sincerely,
Demi Marie Obenour (she/her/hers)