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]
