[DISCUSSION] 2FA/limited token authenitication for apache accounts

[Jarek Potiuk <ja...@potiuk.com>]

Hello,

Encouraged by discussion with Daniel and Greg I would like to start a
discussion of the current and future of authentication for Apache
accounts.

I am well aware any changes to the way people authenticate is a
difficult task, I think we are about the time where 2FA (2-Factor
Authentication) becomes the best practice to follow, maybe it would be
something to consider for "all" asf account access to follow. Even if
not now, then maybe as a future direction and priority for the ASF.
That includes both 2FA and "token" based authentication.

I opened the issue
https://issues.apache.org/jira/projects/INFRA/issues/INFRA-22705 and I
got the response from Daniel and the Infra team to implement TOTP for
Oauth-authenticated access. This was fantastic, but I think it is only
part of the problem and possibly ASF should look for a process and
solution to protect access with 2FA authentication for all kinds of
accesses.

The 2FA/token  protection has been on a rise for the last few years
and pretty much every serious player follows it. I am well aware of
"just because everyone else does it it does not mean it's good" - but
I personally think it is important to at least consider it.

I believe 2FA/token follows the basic premise of security "Something
you have + something you know". 2FA is the "something you have". Just
authenticating with only a password is "something you know" only. When
paired with 2FA-protected ability of generating limited time expiring
tokens, it brings security of ASF accounts - I believe - to a much
higher level.

There are great examples of companies that responded to the "password"
use - in a good way. Just an example that I interact with on a daily
basis is GitHub, where ~2 years ago you could authenticate with
password, but it's been removed in August 2021 - precisely for the
reasons of security concerns:
https://github.blog/changelog/2021-08-12-git-password-authentication-is-shutting-down/.
As explained in the blog post - those are the properties of the token
approach:

1. Unique – tokens are specific to GitHub and can be generated per use
or per device
2. Revocable – tokens can be individually revoked at any time without
needing to update unaffected credentials
3. Limited – tokens can be narrowly scoped to allow only the access
necessary for the use case
4. Random – tokens are not subject to the types of dictionary or brute
force attempts that simpler passwords that you need to remember or
enter regularly might be

When paired with 2FA-protected accounts, this approach is - I believe
- protecting organizations from a number of threats. Happy to
elaborate further on those if needed.

IMHO there are really significant risks of *not* enforcing 2FA. As I
see it, the potential of an attacker gaining unconstrained, not
time-limited read/write access to important assets without any time
limits and hardware-based protection is something that might become a
significant threat to ASF reputation.

Of course - I might be wrong. Maybe the plain-old password is enough
for the ASF. Maybet the risks I think about are exaggerated. But I
wanted to make sure the potential security about it is raised and that
a conscious decision is taken on whether to follow this direction or
not.

I am perfectly aware of the "acceptable risk" approach. I know very
well that security is not a 0/1 game. It's all about "acceptable
risk". If the security team (from Greg's comment - security team is
responsible for those kinds of decisions) decides that the risk is
"acceptable" - so be it. I have no powers (nor responsibilities) for
this part, so if that will be the security team's decision (and
responsibility behind) - so be it.

I would love to hear what the security team stands for and whether
2FA/token is seriously considered to be enforced, or - as alternative
the non-2FA approach is confirmed as "acceptable risk".

Happy to help with the effort needed (though I probably do not have
enough time to lead it in a significant way - but can at least help
with assessing/prototyping/testing ). I am also happy to accept the
outcome of 2FA is not needed, as long as it is seriously considered
and a conscious decision is taken that not having it is an "acceptable
risk".

J.

---------------------------------------------------------------------
To unsubscribe, e-mail: security-discuss-unsubscribe@community.apache.org
For additional commands, e-mail: security-discuss-help@community.apache.org

Re: [DISCUSSION] 2FA/limited token authenitication for apache accounts

[Shane Curcuru <cu...@apache.org>]

Great discussion topic, but turning on or mandating 2FA for committer accounts is a complex topic, so we definitely need some focused discussion on what specific issues we have - either for security risk from committer accounts, or social factors given that the ASF has thousands of committers, many of whom may only use their accounts rarely.

One difference with security posture versus traditional organizations is that Apache's committers are not connected with employment; thus we have many long-lived committer accounts.  Many committers keep working on their Apache project across multiple employers; we also likely have many committers who stop contributing (and possibly forget about their accounts) once they change employers.  

That means many of the traditional $BigCo mitgation policies around corporate access control and employment changes don't really apply here; and it's likely we have proportionally more "dormant" accounts (from people who've stopped committing, but never told us) than most other organizations.  On the flip side, unless a committer explicitly renounces their account, they can always come back to our stable infra team to request access again if they choose to start contributing again after a hiatus.

Relatedly, for projects using GitHub, Infra policy already requires that Apache committers have setup 2FA with GitHub and explicitly linked their Apache ID and GitHub ID - so in that case, code commits are absolutely protected with 2FA thru GitHub's systems.

Hope that helps,
-- 
- Shane Curcuru
  Member
  The Apache Software Foundation

---------------------------------------------------------------------
To unsubscribe, e-mail: security-discuss-unsubscribe@community.apache.org
For additional commands, e-mail: security-discuss-help@community.apache.org

Re: [DISCUSSION] 2FA/limited token authenitication for apache accounts

[Dominik Psenner <dp...@gmail.com>]

2fa is a great thing because it hardens the authentication process! The two
factors can be many things. I propose to use a framework that allows great
flexibility and serves as a identity provider with a single sign on
service. The sso service could allow for many convenient two factors, i.e.
Otp, generated backup codes, email, sms, hardware tokens like ubikeys,
device certificates, ..
--
Sent from my phone. Typos are a kind gift to anyone who happens to find
them.

On Sun, Jan 9, 2022, 16:10 Jacques Le Roux <ja...@les7arts.com>
wrote:

> Hi,
>
> Could we not use a kind of OTP?
>
> Jacques
>
> Le 09/01/2022 à 15:55, Gilles Sadowski a écrit :
> > Hello.
> >
> > Le dim. 9 janv. 2022 à 11:58, Jarek Potiuk <ja...@potiuk.com> a écrit :
> >> Hello,
> >>
> >> Encouraged by discussion with Daniel and Greg I would like to start a
> >> discussion of the current and future of authentication for Apache
> >> accounts.
> >>
> >> I am well aware any changes to the way people authenticate is a
> >> difficult task, I think we are about the time where 2FA (2-Factor
> >> Authentication) becomes the best practice to follow, maybe it would be
> >> something to consider for "all" asf account access to follow. Even if
> >> not now, then maybe as a future direction and priority for the ASF.
> >> That includes both 2FA and "token" based authentication.
> > What would be the practical steps for authenticating (that would
> > replace the one step of entering a login name and password)?
> >
> > Regards,
> > Gilles
> >
> >> I opened the issue
> >> https://issues.apache.org/jira/projects/INFRA/issues/INFRA-22705 and I
> >> got the response from Daniel and the Infra team to implement TOTP for
> >> Oauth-authenticated access. This was fantastic, but I think it is only
> >> part of the problem and possibly ASF should look for a process and
> >> solution to protect access with 2FA authentication for all kinds of
> >> accesses.
> >>
> >> The 2FA/token  protection has been on a rise for the last few years
> >> and pretty much every serious player follows it. I am well aware of
> >> "just because everyone else does it it does not mean it's good" - but
> >> I personally think it is important to at least consider it.
> >>
> >> I believe 2FA/token follows the basic premise of security "Something
> >> you have + something you know". 2FA is the "something you have". Just
> >> authenticating with only a password is "something you know" only. When
> >> paired with 2FA-protected ability of generating limited time expiring
> >> tokens, it brings security of ASF accounts - I believe - to a much
> >> higher level.
> >>
> >> There are great examples of companies that responded to the "password"
> >> use - in a good way. Just an example that I interact with on a daily
> >> basis is GitHub, where ~2 years ago you could authenticate with
> >> password, but it's been removed in August 2021 - precisely for the
> >> reasons of security concerns:
> >>
> https://github.blog/changelog/2021-08-12-git-password-authentication-is-shutting-down/
> .
> >> As explained in the blog post - those are the properties of the token
> >> approach:
> >>
> >> 1. Unique – tokens are specific to GitHub and can be generated per use
> >> or per device
> >> 2. Revocable – tokens can be individually revoked at any time without
> >> needing to update unaffected credentials
> >> 3. Limited – tokens can be narrowly scoped to allow only the access
> >> necessary for the use case
> >> 4. Random – tokens are not subject to the types of dictionary or brute
> >> force attempts that simpler passwords that you need to remember or
> >> enter regularly might be
> >>
> >> When paired with 2FA-protected accounts, this approach is - I believe
> >> - protecting organizations from a number of threats. Happy to
> >> elaborate further on those if needed.
> >>
> >> IMHO there are really significant risks of *not* enforcing 2FA. As I
> >> see it, the potential of an attacker gaining unconstrained, not
> >> time-limited read/write access to important assets without any time
> >> limits and hardware-based protection is something that might become a
> >> significant threat to ASF reputation.
> >>
> >> Of course - I might be wrong. Maybe the plain-old password is enough
> >> for the ASF. Maybet the risks I think about are exaggerated. But I
> >> wanted to make sure the potential security about it is raised and that
> >> a conscious decision is taken on whether to follow this direction or
> >> not.
> >>
> >> I am perfectly aware of the "acceptable risk" approach. I know very
> >> well that security is not a 0/1 game. It's all about "acceptable
> >> risk". If the security team (from Greg's comment - security team is
> >> responsible for those kinds of decisions) decides that the risk is
> >> "acceptable" - so be it. I have no powers (nor responsibilities) for
> >> this part, so if that will be the security team's decision (and
> >> responsibility behind) - so be it.
> >>
> >> I would love to hear what the security team stands for and whether
> >> 2FA/token is seriously considered to be enforced, or - as alternative
> >> the non-2FA approach is confirmed as "acceptable risk".
> >>
> >> Happy to help with the effort needed (though I probably do not have
> >> enough time to lead it in a significant way - but can at least help
> >> with assessing/prototyping/testing ). I am also happy to accept the
> >> outcome of 2FA is not needed, as long as it is seriously considered
> >> and a conscious decision is taken that not having it is an "acceptable
> >> risk".
> >>
> >> J.
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> security-discuss-unsubscribe@community.apache.org
> > For additional commands, e-mail:
> security-discuss-help@community.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: security-discuss-unsubscribe@community.apache.org
> For additional commands, e-mail:
> security-discuss-help@community.apache.org
>
>

Re: [DISCUSSION] 2FA/limited token authenitication for apache accounts

[Jacques Le Roux <ja...@les7arts.com>]

Hi,

Could we not use a kind of OTP?

Jacques

Le 09/01/2022 à 15:55, Gilles Sadowski a écrit :
> Hello.
>
> Le dim. 9 janv. 2022 à 11:58, Jarek Potiuk <ja...@potiuk.com> a écrit :
>> Hello,
>>
>> Encouraged by discussion with Daniel and Greg I would like to start a
>> discussion of the current and future of authentication for Apache
>> accounts.
>>
>> I am well aware any changes to the way people authenticate is a
>> difficult task, I think we are about the time where 2FA (2-Factor
>> Authentication) becomes the best practice to follow, maybe it would be
>> something to consider for "all" asf account access to follow. Even if
>> not now, then maybe as a future direction and priority for the ASF.
>> That includes both 2FA and "token" based authentication.
> What would be the practical steps for authenticating (that would
> replace the one step of entering a login name and password)?
>
> Regards,
> Gilles
>
>> I opened the issue
>> https://issues.apache.org/jira/projects/INFRA/issues/INFRA-22705 and I
>> got the response from Daniel and the Infra team to implement TOTP for
>> Oauth-authenticated access. This was fantastic, but I think it is only
>> part of the problem and possibly ASF should look for a process and
>> solution to protect access with 2FA authentication for all kinds of
>> accesses.
>>
>> The 2FA/token  protection has been on a rise for the last few years
>> and pretty much every serious player follows it. I am well aware of
>> "just because everyone else does it it does not mean it's good" - but
>> I personally think it is important to at least consider it.
>>
>> I believe 2FA/token follows the basic premise of security "Something
>> you have + something you know". 2FA is the "something you have". Just
>> authenticating with only a password is "something you know" only. When
>> paired with 2FA-protected ability of generating limited time expiring
>> tokens, it brings security of ASF accounts - I believe - to a much
>> higher level.
>>
>> There are great examples of companies that responded to the "password"
>> use - in a good way. Just an example that I interact with on a daily
>> basis is GitHub, where ~2 years ago you could authenticate with
>> password, but it's been removed in August 2021 - precisely for the
>> reasons of security concerns:
>> https://github.blog/changelog/2021-08-12-git-password-authentication-is-shutting-down/.
>> As explained in the blog post - those are the properties of the token
>> approach:
>>
>> 1. Unique – tokens are specific to GitHub and can be generated per use
>> or per device
>> 2. Revocable – tokens can be individually revoked at any time without
>> needing to update unaffected credentials
>> 3. Limited – tokens can be narrowly scoped to allow only the access
>> necessary for the use case
>> 4. Random – tokens are not subject to the types of dictionary or brute
>> force attempts that simpler passwords that you need to remember or
>> enter regularly might be
>>
>> When paired with 2FA-protected accounts, this approach is - I believe
>> - protecting organizations from a number of threats. Happy to
>> elaborate further on those if needed.
>>
>> IMHO there are really significant risks of *not* enforcing 2FA. As I
>> see it, the potential of an attacker gaining unconstrained, not
>> time-limited read/write access to important assets without any time
>> limits and hardware-based protection is something that might become a
>> significant threat to ASF reputation.
>>
>> Of course - I might be wrong. Maybe the plain-old password is enough
>> for the ASF. Maybet the risks I think about are exaggerated. But I
>> wanted to make sure the potential security about it is raised and that
>> a conscious decision is taken on whether to follow this direction or
>> not.
>>
>> I am perfectly aware of the "acceptable risk" approach. I know very
>> well that security is not a 0/1 game. It's all about "acceptable
>> risk". If the security team (from Greg's comment - security team is
>> responsible for those kinds of decisions) decides that the risk is
>> "acceptable" - so be it. I have no powers (nor responsibilities) for
>> this part, so if that will be the security team's decision (and
>> responsibility behind) - so be it.
>>
>> I would love to hear what the security team stands for and whether
>> 2FA/token is seriously considered to be enforced, or - as alternative
>> the non-2FA approach is confirmed as "acceptable risk".
>>
>> Happy to help with the effort needed (though I probably do not have
>> enough time to lead it in a significant way - but can at least help
>> with assessing/prototyping/testing ). I am also happy to accept the
>> outcome of 2FA is not needed, as long as it is seriously considered
>> and a conscious decision is taken that not having it is an "acceptable
>> risk".
>>
>> J.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: security-discuss-unsubscribe@community.apache.org
> For additional commands, e-mail: security-discuss-help@community.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: security-discuss-unsubscribe@community.apache.org
For additional commands, e-mail: security-discuss-help@community.apache.org

Re: [DISCUSSION] 2FA/limited token authenitication for apache accounts

[Gilles Sadowski <gi...@gmail.com>]

Hello.

Le dim. 9 janv. 2022 à 11:58, Jarek Potiuk <ja...@potiuk.com> a écrit :
>
> Hello,
>
> Encouraged by discussion with Daniel and Greg I would like to start a
> discussion of the current and future of authentication for Apache
> accounts.
>
> I am well aware any changes to the way people authenticate is a
> difficult task, I think we are about the time where 2FA (2-Factor
> Authentication) becomes the best practice to follow, maybe it would be
> something to consider for "all" asf account access to follow. Even if
> not now, then maybe as a future direction and priority for the ASF.
> That includes both 2FA and "token" based authentication.

What would be the practical steps for authenticating (that would
replace the one step of entering a login name and password)?

Regards,
Gilles

> I opened the issue
> https://issues.apache.org/jira/projects/INFRA/issues/INFRA-22705 and I
> got the response from Daniel and the Infra team to implement TOTP for
> Oauth-authenticated access. This was fantastic, but I think it is only
> part of the problem and possibly ASF should look for a process and
> solution to protect access with 2FA authentication for all kinds of
> accesses.
>
> The 2FA/token  protection has been on a rise for the last few years
> and pretty much every serious player follows it. I am well aware of
> "just because everyone else does it it does not mean it's good" - but
> I personally think it is important to at least consider it.
>
> I believe 2FA/token follows the basic premise of security "Something
> you have + something you know". 2FA is the "something you have". Just
> authenticating with only a password is "something you know" only. When
> paired with 2FA-protected ability of generating limited time expiring
> tokens, it brings security of ASF accounts - I believe - to a much
> higher level.
>
> There are great examples of companies that responded to the "password"
> use - in a good way. Just an example that I interact with on a daily
> basis is GitHub, where ~2 years ago you could authenticate with
> password, but it's been removed in August 2021 - precisely for the
> reasons of security concerns:
> https://github.blog/changelog/2021-08-12-git-password-authentication-is-shutting-down/.
> As explained in the blog post - those are the properties of the token
> approach:
>
> 1. Unique – tokens are specific to GitHub and can be generated per use
> or per device
> 2. Revocable – tokens can be individually revoked at any time without
> needing to update unaffected credentials
> 3. Limited – tokens can be narrowly scoped to allow only the access
> necessary for the use case
> 4. Random – tokens are not subject to the types of dictionary or brute
> force attempts that simpler passwords that you need to remember or
> enter regularly might be
>
> When paired with 2FA-protected accounts, this approach is - I believe
> - protecting organizations from a number of threats. Happy to
> elaborate further on those if needed.
>
> IMHO there are really significant risks of *not* enforcing 2FA. As I
> see it, the potential of an attacker gaining unconstrained, not
> time-limited read/write access to important assets without any time
> limits and hardware-based protection is something that might become a
> significant threat to ASF reputation.
>
> Of course - I might be wrong. Maybe the plain-old password is enough
> for the ASF. Maybet the risks I think about are exaggerated. But I
> wanted to make sure the potential security about it is raised and that
> a conscious decision is taken on whether to follow this direction or
> not.
>
> I am perfectly aware of the "acceptable risk" approach. I know very
> well that security is not a 0/1 game. It's all about "acceptable
> risk". If the security team (from Greg's comment - security team is
> responsible for those kinds of decisions) decides that the risk is
> "acceptable" - so be it. I have no powers (nor responsibilities) for
> this part, so if that will be the security team's decision (and
> responsibility behind) - so be it.
>
> I would love to hear what the security team stands for and whether
> 2FA/token is seriously considered to be enforced, or - as alternative
> the non-2FA approach is confirmed as "acceptable risk".
>
> Happy to help with the effort needed (though I probably do not have
> enough time to lead it in a significant way - but can at least help
> with assessing/prototyping/testing ). I am also happy to accept the
> outcome of 2FA is not needed, as long as it is seriously considered
> and a conscious decision is taken that not having it is an "acceptable
> risk".
>
> J.

---------------------------------------------------------------------
To unsubscribe, e-mail: security-discuss-unsubscribe@community.apache.org
For additional commands, e-mail: security-discuss-help@community.apache.org