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