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: [email protected] For additional commands, e-mail: [email protected]
