Re: Preventing account takeovers through expired domains

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On su, 20 helmi 2022, Kevin Fenzi wrote:
On Sun, Feb 20, 2022 at 04:43:13PM -0800, Gary Buhrmaster wrote:
On Sun, Feb 20, 2022, 16:09 Adam Williamson <adamwill@xxxxxxxxxxxxxxxxx>
wrote:

> It used to support these, but the support was lost with the recent
> rewrite. However, it supports Google Authenticator-style OTPs. Folks
> with infra privileges on their accounts (like me) are already required
> to use these. It works fine. I preferred being able to use a yubikey so
> I don't always have to open an app on my phone and retype a six digit
> code when I need to log in to something, but that's just a minor
> annoyance.

The old account system (fas2) used to support yubikeys, but it did not
support U2F. It only supported them in HOTP mode, not U2f.

The new account system is a frontend to IPA, and IPA does not currently
support U2F. There's a RFE ( https://github.com/SSSD/sssd/issues/4322 )
but I don't know where it is on their roadmap. Not only does IPA need to
add support, but then we would need to add support to noggin to
enroll/etc.

We (FreeIPA and SSSD teams) are working on a bit different approach
right now since support of U2F in Kerberos is complicated with a need to
first get a specification agreed between multiple industry participants
and currently there is no one driving that work.

Instead, we are working on an ability to authenticate against OIDC when
acquiring a Kerberos ticket granting ticket. This would turn the need to
choose authentication method to the IdP configured and most IdPs support
use of U2F tokens (as well as other mechanisms).

With this approach, id.fedoraproject.org would be able to handle
authentication on its own way, not Fedora Project's KDC alone like now.
After authenticated, a user would be issued with a 'normal' Kerberos TGT
which then can be used to obtain service tickets to other services and
authenticate to them with GSSAPI. Including, if needed, to authenticate
to id.fedoraproject.org again, this time with GSSAPI.

This is not ready for general consumption but we plan to have something
to submit to Rawhide in a month or so. Enrolling IPA users into this
would be similar to already existing RADIUS proxy authentication path in
FreeIPA.

TOTP (what the authenticator app does),
is, indeed, better than nothing, but U2F
(FIDO), is considered to be stronger.

Yeah.

So, as to the topic of this thread... I agree it's a possible attack
vector, but it seems... like a lot more work than just coming in through
the new maintainer workflow, but I do suppose there might be more
scrutiny there.

When someone makes an account, basically we are saying "This person is
the person who controls that email address". So, if we don't have the
email address, we have to fall back on other data that was added to the
account, like ssh pub key, gnupg key, etc. Or real world information,
like "I know them and met them at the pub", they work for Red Hat and we
can verify them, etc.  In fas2 we also had a 'challenge/response'
thing that someone could fill in, but not many folks did (and the new
system doesn't have that anyhow).

I think some kind of keep alive ping could be worthwhile, although we
have always rejected them in the past for bothering mataintainers too
much.

kevin



_______________________________________________
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 on the list, report it: https://pagure.io/fedora-infrastructure




--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
_______________________________________________
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 on the list, report it: https://pagure.io/fedora-infrastructure




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux