Hello. Le dim. 9 janv. 2022 à 11:58, Jarek Potiuk <[email protected]> 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: [email protected] For additional commands, e-mail: [email protected]
