Re: Preventing account takeovers through expired domains
On Wed, Feb 23, 2022 at 10:33:16AM +0100, Vitaly Zaitsev via devel wrote: > On 22/02/2022 12:33, Daniel P. Berrangé wrote: > > Given that the accounts system already supports these OTPs, what > > is the reason for not mandating this OTP based 2FA for*all* > > contributors today, as oppposed to merely infra people ? > > I like it, but many Fedora contributors won't be happy. Google said that > only 10% of their users use OTP. > > We need to fix Fedora's OTP implementation first. Sending password+CODE is > the worst idea, I ever seen. You can't even use a password manager to > auto-enter it. > > My suggestions: > 1. Change password entry dialog on id.fedoraproject.org with > accounts.fedoraproject.org version (with a separate OTP field). We have this change already done, but are waiting for a upstream ipsilon release. > 2. Kinit should ask for password and OTP code in different prompts (check > how it works with SSH + OTP plugin). This is being worked on by IPA folks. kevin signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Preventing account takeovers through expired domains
On Wed, Feb 23, 2022 at 10:33:16AM +0100, Vitaly Zaitsev via devel wrote: > On 22/02/2022 12:33, Daniel P. Berrangé wrote: > > Given that the accounts system already supports these OTPs, what > > is the reason for not mandating this OTP based 2FA for*all* > > contributors today, as oppposed to merely infra people ? > > I like it, but many Fedora contributors won't be happy. Google said that > only 10% of their users use OTP. I presume you're referring to Google services like GMail, etc. I can totally understand that kind of metric for the global population in general, but I don't think the comparison is relevant or valid. Contributing to the Fedora project comes with responsibilities, and being asked to keep your account secured with 2fa is not an unreasonable request from a project such as Fedora, whose output is consumed by a huge number of users. 2fa is a standard best practice expected from any organization that takes user account security seriously. There are significant implications for reputational damage to Fedora if a contributor's account is compromised and that is then successfully used to compromise software and get it shipped to millions of users. We got lucky in the past with scope of damage after an account compromise, but we should not assume that will be the case next time... Regards, Daniel -- |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o-https://fstop138.berrange.com :| |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :| ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Preventing account takeovers through expired domains
On 22/02/2022 12:33, Daniel P. Berrangé wrote: Given that the accounts system already supports these OTPs, what is the reason for not mandating this OTP based 2FA for*all* contributors today, as oppposed to merely infra people ? I like it, but many Fedora contributors won't be happy. Google said that only 10% of their users use OTP. We need to fix Fedora's OTP implementation first. Sending password+CODE is the worst idea, I ever seen. You can't even use a password manager to auto-enter it. My suggestions: 1. Change password entry dialog on id.fedoraproject.org with accounts.fedoraproject.org version (with a separate OTP field). 2. Kinit should ask for password and OTP code in different prompts (check how it works with SSH + OTP plugin). -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Preventing account takeovers through expired domains
On 23/02/2022 00:03, Gary Buhrmaster wrote: a TPM(2?) chip as a possible secure processor. In some countries, TPM can't be pre-installed on all new PCs/Laptops due to regulation issues. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Preventing account takeovers through expired domains
On Mon, Feb 21, 2022 at 7:17 PM Vitaly Zaitsev via devel wrote: > OTP is absolutely free. FIDO2 requires the purchase of a special > hardware token. Not necessarily. Not only can some mobile devices present the needed credentials (as if they were an external hardware token), but as I recall U2F specifies a TPM(2?) chip as a possible secure processor. While I don't remember where, I think I did once see a reference to where someone had created a TPM based FIDO implementation. But I agree there are some known problems in obtaining a $10(US) FIDO2 token. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Preventing account takeovers through expired domains
On Tue, Feb 22, 2022 at 9:54 PM Kevin Fenzi wrote: > I don't think there's any way in IPA to require otp as a requirement for > group membership currently. (Please let me know if there is). > Which would leave us checking after the fact and removing people without > one set, which is a big pile of hassle. :( Well, should such a policy be enacted, there is the one time check for existing packagers, and then just one more step to check box to check for those that are requesting to be added to the packager group. Not ideal, but I would expect doable (unless there is a lot more churn in the packager group than I am aware of). > Enforcing otp per group also would require dev work from what I > understand. :( Probably. Although the requirement to enforce the most restrictive requirement(s) on a user that any group requires that the user is a member of is something that is certainly desirable of better implementations (and if a group later is changed to have higher requirements, users that do not conform would need to be addressed (removal from group entirely, not getting the group authorizations, something). ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Preventing account takeovers through expired domains
On Tue, Feb 22, 2022 at 11:33:55AM +, Daniel P. Berrangé wrote: > On Sun, Feb 20, 2022 at 04:08:43PM -0800, Adam Williamson wrote: > > On Sun, 2022-02-20 at 16:42 +, Gary Buhrmaster wrote: > > > Unfortunately, last I checked, the FAS account > > > system did not support adding something > > > like a FIDO2 security key to an account(**). > > > Even if it did, I suspect not all the other parts > > > of the system would support FIDO keys. > > > > 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. > > Given that the accounts system already supports these OTPs, what > is the reason for not mandating this OTP based 2FA for *all* > contributors today, as oppposed to merely infra people ? All contributors? ie, require an otp to make an account? Or did you mean all packagers? or something else? I don't think there's any way in IPA to require otp as a requirement for group membership currently. (Please let me know if there is). Which would leave us checking after the fact and removing people without one set, which is a big pile of hassle. :( > We know that Fedora contributors have had their passwords compromised > in the past [1], so not using 2FA of any kind is a risk to Fedora. > > I understand these simple OTPs are not as secure as FIDO2, but > they have the clear advantage of actually being supported in > Fedora's auth system today. These OTPs are good enough that 1000's > of companies globally use them, rather than relying on plain passwords > only. > > By all means have FIDO2 supported as the desired long term goal, but > it feels dubious to stick with only plain passwords in the meantime. > FIDO2 support requires significant dev work on a service that is not > under Fedora's control and make take many many years to arrive in a > form that is usable. Enforcing otp per group also would require dev work from what I understand. :( kevin signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Preventing account takeovers through expired domains
On 2/22/22 06:33, Daniel P. Berrangé wrote: > On Sun, Feb 20, 2022 at 04:08:43PM -0800, Adam Williamson wrote: >> On Sun, 2022-02-20 at 16:42 +, Gary Buhrmaster wrote: >>> Unfortunately, last I checked, the FAS account >>> system did not support adding something >>> like a FIDO2 security key to an account(**). >>> Even if it did, I suspect not all the other parts >>> of the system would support FIDO keys. >> >> 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. > > Given that the accounts system already supports these OTPs, what > is the reason for not mandating this OTP based 2FA for *all* > contributors today, as oppposed to merely infra people ? I very much would support this change. > We know that Fedora contributors have had their passwords compromised > in the past [1], so not using 2FA of any kind is a risk to Fedora. > > I understand these simple OTPs are not as secure as FIDO2, but > they have the clear advantage of actually being supported in > Fedora's auth system today. These OTPs are good enough that 1000's > of companies globally use them, rather than relying on plain passwords > only. > > By all means have FIDO2 supported as the desired long term goal, but > it feels dubious to stick with only plain passwords in the meantime. > FIDO2 support requires significant dev work on a service that is not > under Fedora's control and make take many many years to arrive in a > form that is usable. I wholeheartedly agree with this statement. > With regards, > Daniel > > [1] > https://lists.fedoraproject.org/pipermail/announce/2011-January/002911.html -- Sincerely, Demi Marie Obenour (she/her/hers) OpenPGP_0xB288B55FFF9C22C1.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Preventing account takeovers through expired domains
On Sun, Feb 20, 2022 at 04:08:43PM -0800, Adam Williamson wrote: > On Sun, 2022-02-20 at 16:42 +, Gary Buhrmaster wrote: > > Unfortunately, last I checked, the FAS account > > system did not support adding something > > like a FIDO2 security key to an account(**). > > Even if it did, I suspect not all the other parts > > of the system would support FIDO keys. > > 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. Given that the accounts system already supports these OTPs, what is the reason for not mandating this OTP based 2FA for *all* contributors today, as oppposed to merely infra people ? We know that Fedora contributors have had their passwords compromised in the past [1], so not using 2FA of any kind is a risk to Fedora. I understand these simple OTPs are not as secure as FIDO2, but they have the clear advantage of actually being supported in Fedora's auth system today. These OTPs are good enough that 1000's of companies globally use them, rather than relying on plain passwords only. By all means have FIDO2 supported as the desired long term goal, but it feels dubious to stick with only plain passwords in the meantime. FIDO2 support requires significant dev work on a service that is not under Fedora's control and make take many many years to arrive in a form that is usable. With regards, Daniel [1] https://lists.fedoraproject.org/pipermail/announce/2011-January/002911.html -- |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o-https://fstop138.berrange.com :| |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :| ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Preventing account takeovers through expired domains
On 22/02/2022 04:17, Ian McInerney via devel wrote: The only viable option I see for requiring the use of hardware keys would be if RedHat (or another sponsor) provided them to packagers when needed. There is another problem - the US export/sanctions policies. You can't ship such cryptographic devices to contributors in sanctioned regions. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Preventing account takeovers through expired domains
On 22/02/2022 03:14, Demi Marie Obenour wrote: Developing a roadmap to encourage, and eventually require, the use of hardware authenticators to submit packages is a reasonable precaution in this threat environment. A hardware authenticator could be a FIDO2 token, smart card, etc. Who will pay for this equipment? -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Preventing account takeovers through expired domains
On 2/21/22 22:17, Ian McInerney via devel wrote: > On Tue, Feb 22, 2022 at 2:15 AM Demi Marie Obenour > wrote: > >> On 2/21/22 14:16, Vitaly Zaitsev via devel wrote: >>> On 21/02/2022 19:25, Demi Marie Obenour wrote: FIDO keys are significantly more secure than OTPs, and FAS should get support for them. OTPs are still phishable, whereas FIDO2 generally isn’t. >>> >>> OTP is absolutely free. FIDO2 requires the purchase of a special >>> hardware token. >> >> One must remember that anyone in the packagers group can (with a >> modicum of effort) get code execution on a huge number of machines, >> and is thus an incredibly attractive target for phishing attacks. >> Developing a roadmap to encourage, and eventually require, the use of >> hardware authenticators to submit packages is a reasonable precaution >> in this threat environment. A hardware authenticator could be a FIDO2 >> token, smart card, etc. >> > > While it may make sense from the security standpoint, we also need to > factor in the community/economic factor for Fedora contributors. Requiring > the use of a hardware key then means that contributors have to spend their > money to buy such a key, adding an additional hurdle for them to go > through. Having to get the hardware key may also be prohibitive for > contributors coming from developing countries, or who are > low-income/unemployed, where they may already have a computer to use, but > the added cost of a new hardware key could be a large burden. > > The only viable option I see for requiring the use of hardware keys would > be if RedHat (or another sponsor) provided them to packagers when needed. > This is probably prohibitive to do for the entire packager group, so > instead it would make more sense to focus on the group that would expose > the largest amount of the distribution - the proven packager group. This > set of packagers is a smaller group, and they would have shown a dedication > to the community/Fedora in the past to be approved by FESCO. It would > probably be easier to convince Redhat/the Fedora Council to sponsor > hardware keys for that core group than the community at large should the > decision to require them be made. > > -Ian Proven packagers are definitely a good place to start, along with maintainers of core packages such as glibc. Next should be the maintainers of any package that is a dependency (either at build-time or runtime) of any package that is either (1) included in any default install or (2) used in Fedora’s own infrastructure. That leaves the Supplements: hole still open, which needs to be dealt with some other way. -- Sincerely, Demi Marie Obenour (she/her/hers) OpenPGP_0xB288B55FFF9C22C1.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Preventing account takeovers through expired domains
On Tue, Feb 22, 2022 at 2:15 AM Demi Marie Obenour wrote: > On 2/21/22 14:16, Vitaly Zaitsev via devel wrote: > > On 21/02/2022 19:25, Demi Marie Obenour wrote: > >> FIDO keys are significantly more secure than OTPs, and FAS should get > >> support for them. OTPs are still phishable, whereas FIDO2 generally > >> isn’t. > > > > OTP is absolutely free. FIDO2 requires the purchase of a special > > hardware token. > > One must remember that anyone in the packagers group can (with a > modicum of effort) get code execution on a huge number of machines, > and is thus an incredibly attractive target for phishing attacks. > Developing a roadmap to encourage, and eventually require, the use of > hardware authenticators to submit packages is a reasonable precaution > in this threat environment. A hardware authenticator could be a FIDO2 > token, smart card, etc. > While it may make sense from the security standpoint, we also need to factor in the community/economic factor for Fedora contributors. Requiring the use of a hardware key then means that contributors have to spend their money to buy such a key, adding an additional hurdle for them to go through. Having to get the hardware key may also be prohibitive for contributors coming from developing countries, or who are low-income/unemployed, where they may already have a computer to use, but the added cost of a new hardware key could be a large burden. The only viable option I see for requiring the use of hardware keys would be if RedHat (or another sponsor) provided them to packagers when needed. This is probably prohibitive to do for the entire packager group, so instead it would make more sense to focus on the group that would expose the largest amount of the distribution - the proven packager group. This set of packagers is a smaller group, and they would have shown a dedication to the community/Fedora in the past to be approved by FESCO. It would probably be easier to convince Redhat/the Fedora Council to sponsor hardware keys for that core group than the community at large should the decision to require them be made. -Ian > > -- > Sincerely, > Demi Marie Obenour > (she/her/hers)___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > 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@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Preventing account takeovers through expired domains
On 2/21/22 14:16, Vitaly Zaitsev via devel wrote: > On 21/02/2022 19:25, Demi Marie Obenour wrote: >> FIDO keys are significantly more secure than OTPs, and FAS should get >> support for them. OTPs are still phishable, whereas FIDO2 generally >> isn’t. > > OTP is absolutely free. FIDO2 requires the purchase of a special > hardware token. One must remember that anyone in the packagers group can (with a modicum of effort) get code execution on a huge number of machines, and is thus an incredibly attractive target for phishing attacks. Developing a roadmap to encourage, and eventually require, the use of hardware authenticators to submit packages is a reasonable precaution in this threat environment. A hardware authenticator could be a FIDO2 token, smart card, etc. -- Sincerely, Demi Marie Obenour (she/her/hers) OpenPGP_0xB288B55FFF9C22C1.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Preventing account takeovers through expired domains
On 21/02/2022 19:25, Demi Marie Obenour wrote: FIDO keys are significantly more secure than OTPs, and FAS should get support for them. OTPs are still phishable, whereas FIDO2 generally isn’t. OTP is absolutely free. FIDO2 requires the purchase of a special hardware token. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Preventing account takeovers through expired domains
On 2/20/22 19:08, Adam Williamson wrote: > On Sun, 2022-02-20 at 16:42 +, Gary Buhrmaster wrote: >> Unfortunately, last I checked, the FAS account >> system did not support adding something >> like a FIDO2 security key to an account(**). >> Even if it did, I suspect not all the other parts >> of the system would support FIDO keys. > > 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. FIDO keys are significantly more secure than OTPs, and FAS should get support for them. OTPs are still phishable, whereas FIDO2 generally isn’t. -- Sincerely, Demi Marie Obenour (she/her/hers) OpenPGP_0xB288B55FFF9C22C1.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Preventing account takeovers through expired domains
On Mon, Feb 21, 2022 at 8:35 AM Alexander Bokovoy wrote: > 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. Excellent news that there is progress! And, yes, I do understand there are many more steps to go to get to where some of us would like to be. Thanks. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: 2FA (was: Preventing account takeovers through expired domains)
Also it's possible to use gopass which is able to store the OTP seed secured by GPG and keep the GPG keys on a Yubikey to ensure their safety. Best, Fale On Mon, Feb 21, 2022, at 11:03, Björn Persson wrote: > Adam Williamson wrote: > > 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. > > You can produce compatible OTPs with a yubikey if you want. Install > yubioath-desktop. You open an app on your workstation/laptop instead of > on the phone, and paste from the clipboard instead of retyping. (Still > not as good as U2F of course.) > > Björn Persson > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > 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@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure > -- Fabio Alessandro Locati fale.io ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
2FA (was: Preventing account takeovers through expired domains)
Adam Williamson wrote: > 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. You can produce compatible OTPs with a yubikey if you want. Install yubioath-desktop. You open an app on your workstation/laptop instead of on the phone, and paste from the clipboard instead of retyping. (Still not as good as U2F of course.) Björn Persson pgpxs9kMwtLFb.pgp Description: OpenPGP digital signatur ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Preventing account takeovers through expired domains
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 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@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org 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@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Preventing account takeovers through expired domains
On Sun, Feb 20, 2022 at 04:43:13PM -0800, Gary Buhrmaster wrote: > On Sun, Feb 20, 2022, 16:09 Adam Williamson > 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. > 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 signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Preventing account takeovers through expired domains
On Sun, Feb 20, 2022, 16:09 Adam Williamson 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. > TOTP (what the authenticator app does), is, indeed, better than nothing, but U2F (FIDO), is considered to be stronger. > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Preventing account takeovers through expired domains
On Sun, 2022-02-20 at 16:42 +, Gary Buhrmaster wrote: > Unfortunately, last I checked, the FAS account > system did not support adding something > like a FIDO2 security key to an account(**). > Even if it did, I suspect not all the other parts > of the system would support FIDO keys. 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. -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
2FA (was: Preventing account takeovers through expired domains)
Demi Marie Obenour wrote: > Security keys are the only form of 2fa that is immune to > phishing attacks. U2F and FIDO2 are said to be immune to phishing. HOTP, TOTP and various proprietary challenge-respone protocols are not immune. Björn Persson pgp_7IhtLa4JI.pgp Description: OpenPGP digital signatur ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Preventing account takeovers through expired domains
Mattia Verga via devel wrote: > Il 19/02/22 19:38, Björn Persson ha scritto: > > Zbigniew Jędrzejewski-Szmek wrote: > >> I think it'd be better to check the status weekly and only require > >> account reconfirmation if the quarantine status is detected ⌊N / 7 - 1⌋ > >> times in a row (where N=quarantine length in days). > > It will be fine as long as it's done before the domain is released for > > registration. Let's just not make it so tight that a little unscheduled > > downtime can open an attack window. > > > But this covers just the case where a domain is expired and free to take. Correct. I'm not saying it would be a panacea. > I agree this would be the easiest attack vector, but what about if it's > the user email only to expire and free to take? There are (at least, I'm > sure there were) some free email services that expire email addresses > not used for a year or so. Also, in a previous comment in this thread, > someone pointed out that also email addresses from universities or other > institutions can be "recycled". These are harder attack cases, but > they're possible. Do these services and institutions publish lists of expired email addresses and dates when they will be recycled? In that case they could be handled the same way as expired domains. > That's why I proposed a check against user activity rather than a check > against domain or email reachability. Doing one does not prevent doing the other. Disabling inactive user accounts makes sense because abandoned accounts are more likely targets for takeover. It can be expected to reduce the risk somewhat, but it's not a reliable way to prevent takeovers entirely. Zbigniew said that some registries use quarantine times as short as 14 days. You can't disable packagers just because they take a two-week vacation. Monitoring for expired domains is a reliable way to eliminate one attack vector, but not other attack vectors. Other countermeasures against other attack vectors are also needed. Existence of other attack vectors is not a valid argument against eliminating one attack vector. Björn Persson pgpN620LIbtFj.pgp Description: OpenPGP digital signatur ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Preventing account takeovers through expired domains
On Sun, Feb 20, 2022 at 4:01 PM Demi Marie Obenour wrote: > I think we should also require security key-based 2fa for all > packagers. In a previous discussion on this topic that was suggested (and at least partially rejected(*)). Many (larger) orgs have decided that issuing hardware security keys to all their staff can eliminate entire classes of vulnerabilities. Unfortunately, last I checked, the FAS account system did not support adding something like a FIDO2 security key to an account(**). Even if it did, I suspect not all the other parts of the system would support FIDO keys. For a community organization such as Fedora, requiring packagers to obtain (and register) security keys would be a large step(***), and might end up adding enough impedance to the new packager process to discourage new packagers (and/or drive away some existing packagers). There is also the problem of replacement keys when they are lost/damaged(), and they will, eventually, be lost/stolen/damaged. All said, I agree that requiring packagers to have and register (something like) FIDO keys is a good goal. Lastly, a question, if some of the RedHat employees on the list are at liberty to comment, does RH require hardware security keys, or other OTP technologies, to access certain apps, or are passwords considered good enough? Gary (*) Well, rejected might be too strong, but it was not agreed upon as a way forward. (**) There may be alternatives, but the FIDO / U2F approach seems to be the one most are moving towards. (***) I suppose if there was "magic money" the project could issue them to those that have been approved as new packagers. () Replacement security keys are always a problem, even when the org has a direct connection to the individual. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Preventing account takeovers through expired domains
On 2/20/22 05:00, Mattia Verga via devel wrote: > Il 19/02/22 19:38, Björn Persson ha scritto: >> Zbigniew Jędrzejewski-Szmek wrote: >>> I think it'd be better to check the status weekly and only require >>> account reconfirmation if the quarantine status is detected ⌊N / 7 - 1⌋ >>> times in a row (where N=quarantine length in days). >> It will be fine as long as it's done before the domain is released for >> registration. Let's just not make it so tight that a little unscheduled >> downtime can open an attack window. >> > But this covers just the case where a domain is expired and free to take. > > I agree this would be the easiest attack vector, but what about if it's > the user email only to expire and free to take? There are (at least, I'm > sure there were) some free email services that expire email addresses > not used for a year or so. Also, in a previous comment in this thread, > someone pointed out that also email addresses from universities or other > institutions can be "recycled". These are harder attack cases, but > they're possible. > > That's why I proposed a check against user activity rather than a check > against domain or email reachability. > > Mattia I think we should also require security key-based 2fa for all packagers. Security keys are the only form of 2fa that is immune to phishing attacks. In the future, I would like to see a requirement that uploads be digitally signed, which Debian already enforces. I would also like to see certificate pinning implemented for all Fedora Project infrastructure. -- Sincerely, Demi Marie Obenour (she/her/hers) OpenPGP_0xB288B55FFF9C22C1.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Preventing account takeovers through expired domains
Il 19/02/22 19:38, Björn Persson ha scritto: > Zbigniew Jędrzejewski-Szmek wrote: >> I think it'd be better to check the status weekly and only require >> account reconfirmation if the quarantine status is detected ⌊N / 7 - 1⌋ >> times in a row (where N=quarantine length in days). > It will be fine as long as it's done before the domain is released for > registration. Let's just not make it so tight that a little unscheduled > downtime can open an attack window. > But this covers just the case where a domain is expired and free to take. I agree this would be the easiest attack vector, but what about if it's the user email only to expire and free to take? There are (at least, I'm sure there were) some free email services that expire email addresses not used for a year or so. Also, in a previous comment in this thread, someone pointed out that also email addresses from universities or other institutions can be "recycled". These are harder attack cases, but they're possible. That's why I proposed a check against user activity rather than a check against domain or email reachability. Mattia ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Preventing account takeovers through expired domains
Zbigniew Jędrzejewski-Szmek wrote: > I think it'd be better to check the status weekly and only require > account reconfirmation if the quarantine status is detected ⌊N / 7 - 1⌋ > times in a row (where N=quarantine length in days). It will be fine as long as it's done before the domain is released for registration. Let's just not make it so tight that a little unscheduled downtime can open an attack window. Björn Persson pgpqiv4u1U4Nr.pgp Description: OpenPGP digital signatur ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Preventing account takeovers through expired domains (was: Do we have any policy for disabling inactive users)
On Sat, Feb 19, 2022 at 02:18:38PM +0100, Björn Persson wrote: > Possible step 3: A program on a Fedora Project server notes that > example.net has been deactivated. The program removes the address > j@example.net from J. Doe's account, or disables sending to the > nonexistent address. ... > Step 4: The quarantine period ends. The registry releases example.net > for registration. This means we would create the domain entering quarantine period almost like it being deactivated. That's very harsh… Based on a quick search, it seems that the quarantine varies, but is 14-40 days. I think it'd be better to check the status weekly and only require account reconfirmation if the quarantine status is detected ⌊N / 7 - 1⌋ times in a row (where N=quarantine length in days). Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Preventing account takeovers through expired domains (was: Do we have any policy for disabling inactive users)
Vitaly Zaitsev via devel wrote: > We're talking about potentially hacked accounts, right? In this subthread I'm talking about *preventing* account takeovers so that they don't happen in the first place. One specific method of takeover that the Fedora Project would be able to prevent. I thought the quote I posted was perfectly clear. Evidently it wasn't. Allow me to explain the scenario step by step: Step 1: J. Doe joins the Fedora Project using a working email address, j@example.net. J. Doe gets sponsored and makes some packages. All is well so far. Step 2: Much later, the holder of example.net stops paying the renewal fee. The registry removes the domain from DNS. j@example.net ceases to exist. J. Doe forgets to update the address in their Fedora account. This has happened to 2818 NPM accounts according to the article I quoted. It can happen to Fedora accounts too. Possible step 3: A program on a Fedora Project server notes that example.net has been deactivated. The program removes the address j@example.net from J. Doe's account, or disables sending to the nonexistent address. Question: Does step 3 happen? I suspect that this program doesn't exist. I haven't seen any mentions of it. Step 4: The quarantine period ends. The registry releases example.net for registration. Step 5: Malicious Mallory registers example.net, sets up a mail server and configures the alias "j.doe". Suddenly j@example.net exists again, but now this address quite legitimately belongs to Mallory. Step 6: Mallory enters J. Doe's username into https://accounts.fedoraproject.org/forgot-password/ask and clicks on "Send". Branch 6A: If step 3 was not done, then a passphrase reset email is sent to j@example.net and is received by Mallory. Mallory takes over J. Doe's account and replaces any SSH and OpenPGP keys with his own. Malicious Mallory is now a Fedora packager in the name of J. Doe, and is empowered to insert malware into J. Doe's packages. Branch 6B: If step 3 was done, then no passphrase reset email is sent. Mallory's attack fails. Step 7: J. Doe tries to log in. Branch 7A: If step 3 was not done, then none of J. Doe's credentials work anymore. Mallory has control of the account and J. Doe is locked out. Branch 7B: If step 3 was done, then the account still belongs to J. Doe. The account system tells J. Doe to enter a new email address. The system sends a verification code to this new address. This is not a passphrase reset. It's an email address verification code, which J. Doe must paste into the web interface while logged in, to prove that the address belongs to the right person. After the new address is verified, J. Doe's account works normally again. Note that Mallory must do step 5 before step 6 for the attack to work, and the registry won't allow step 5 to happen before step 4. Therefore doing step 3 before step 4 ensures that step 6 cannot happen before step 3. That way the Fedora Project could reliably prevent this kind of attack. I hope this explanation is clear enough to be understood. In case of TL;DR, the short version is four posts upthread from here. So, does step 3 exist? Björn Persson pgpPIYU3U_oGq.pgp Description: OpenPGP digital signatur ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
