On Wed, 7 Sept 2022 at 08:27, Petr Pisar <ppisar@xxxxxxxxxx> wrote:
V Wed, Sep 07, 2022 at 07:51:15AM -0400, Stephen Smoogen napsal(a):
> On Wed, 7 Sept 2022 at 02:53, Adam Williamson <adamwill@xxxxxxxxxxxxxxxxx>
> wrote:
>
> > On Wed, 2022-09-07 at 08:41 +0200, Vitaly Zaitsev via devel wrote:
> > > On 06/09/2022 23:14, Jonathan Wright wrote:
> > > > Fedora must be looked at as more than just a "hobby project" even
> > though
> > > > it is a hobby for some.
> > >
> > > There are many casual maintainers who maintain one or two packages. We
> > > shouldn't force them to leave Fedora.
> > >
> > > > It's an OS that many rely on and $25 is a somewhat trivial cost for
> > improved security.
> > >
> > > There are many contributors from countries where $25 is a lot. We
> > > shouldn't set up financial barriers. This is a dead end.
> >
> > I think we kind of have two competing factors here, and it's not much
> > use Camp A saying "FACTOR A IS IMPORTANT!" and Camp B saying "NO FACTOR
> > B IS IMPORTANT!" and that just going round in circles.
> >
> > On the one hand, Fedora is not just a hobby project. It's an important
> > upstream in the F/OSS ecosystem. Very important downstreams like
> > CentOS, RHEL, Amazon Linux and others are built out of it. It's
> > absolutely an attractive target for a supply chain attack. We have an
> > ethical responsibility to the F/OSS community to harden ourselves
> > against such attacks, and FIDO2 auth would be a good way to do that.
> >
> >
> So I think all this focusing on FIDO2 as a requirement is the problem. We
> are looking at least 2-3 years before Fedora Infrastructure could actually
> support it at scale. This is not just technical support, but needing
> people to actually handle the problems. We have a hard enough handling OTP
> tokens that people put in and then immediately lose so can't log in or
> change their accounts. Dealing with 100 developers who only put one token
> on their system and then promptly lose it after going for a jog etc is
> going to be a nightmare. [I had to support scientists with one time tokens
> before, and it is a constant 'I lost my token and I need to be verified
> that I am who I am. Can I get a new token?' etc.]
>
> So I am going to say I am in agreement with Vitaly that FIDO2 is not a
> solution we could support at this time. At most we could support HOTP via
> yubikey but we would need to be able to make sure
> 1. That we have some sort of '5 codes which can be used in case of
> emergency'. These are printed on a screen and that is it.
> 2. We make sure that people have 2 additional devices attached before OTP
> is 'enabled'.
>
> Otherwise this is going to end in tears even before we tried to get 'FIDO2'
> set up.
>
Do people lose their tokens more often than forget their passwords?
Yes. People lost or reset their phones or they decided to use one of the 'computer' ones and reinstalled their OS and found woops it's gone. Normally if we see the person is who they are or are not in a group we need secondary confirmation they are who they are (aka packagers) we can clear the token and they can log in afterwards.
Shouldn't we instead start with strengthening the credentials reset even for
password-only authentication? I.e. disallowing the reset. Or enabling having
multiple passwords.
Maybe. What work do you not want done in Fedora for the next couple of years to do this. There are a lot of 'OMG we need this' initiatives and very few volunteers who have the skill level to help anymore.
That said, having multiple passwords without additional tokens attached is a security nightmare. I have dealt with 6 systems which had them because people thought it would cut down work and it either ramped up work or ended up with security compromises which were horrible. Disallowing resets end up requiring about 2-3 people whose main job every couple of minutes is to go through some form to try and confirm a person is who they are and then reset manually. You are welcome to take that over as your full time job.
-- Petr
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
