2:41 p.m.
Greetings.
FAS2 (The old account system) supported 2fa tokens, but they were not in
the main interface, you had to go and find a infra sop and go to the
right place or run the right command line tool. This was fine as the
only thing we were using them for was sudo (so only sysadmins were
affected). In order to reset a token in this setup, we required a gpg
encrypted email or other proof of you being who you say you are before
resetting. Since this was admins, it was just a few per month (if that).
In the new account system, they are integrated right into the interface,
so tons of people are playing around with them. A number of folks are
not able to properly save their token, or run into problems adding it
and need to have that token removed so they can try again. Many of these
are new users that don't have a gpg key set in their account. We have
been getting a lot of these of late. ;(
So, the questions are:
1. How can we cut down on the people who are not able to enroll/run into
problems with their token requesting removal?
Random thoughts:
* Could we require someone enter their password + token before accepting
the token? ie, they try and enroll, ipa adds it, they have to verify, if
they can't, it's removed?
* Could we add 'recovery codes' so if someone enrolls and it's
wrong/broken, they could use a code to login and add a new token and
remove the old broken one?
* Could we perhaps make a 'dev' noggin that people could test with and
wipe all accounts from every day or something? Then ask people to test
there if they are unsure how to add otp
* Could we 'hide' the otp setup until you have X groups or something?
2. How can we verify identity on people who request the removal of their
last otp? Do we just tell them to make a new account?
Random ideas:
* If they are not in any groups, how about we just reset based on email?
* Or perhaps if they are not in any sysadmin* groups?
* If they are Red Hat employees we can use the internal verify thing
* We could use gpg signed email if there is a gpg key assigned to the
account.
* Could we use ssh key to verify them?
Any thoughts welcome.
kevin
4:35 p.m.
On Thu, Apr 08, 2021 at 12:41:43PM -0700, Kevin Fenzi wrote:
so tons of people are playing around with them. A number of folks
are
not able to properly save their token, or run into problems adding it
and need to have that token removed so they can try again. Many of these
are new users that don't have a gpg key set in their account. We have
been getting a lot of these of late. ;(
Or some of them are, like, project leaders who also make mistakes. :)
* Could we require someone enter their password + token before
accepting
the token? ie, they try and enroll, ipa adds it, they have to verify, if
they can't, it's removed?
This is _very_ common in other implementations.
* Could we add 'recovery codes' so if someone enrolls and
it's
wrong/broken, they could use a code to login and add a new token and
remove the old broken one?
Likewise!
* Could we perhaps make a 'dev' noggin that people could test
with and
wipe all accounts from every day or something? Then ask people to test
there if they are unsure how to add otp
We probably _should_ have this for other reasons, but I don't think it's a
good solution to this problem. It adds complexity while still not
guaranteeing that what's done on the production instance will work.
* Could we 'hide' the otp setup until you have X groups or
something?
While this might help some people... ....... ..... .
2. How can we verify identity on people who request the removal of
their
last otp? Do we just tell them to make a new account?
Random ideas:
* If they are not in any groups, how about we just reset based on email?
* Or perhaps if they are not in any sysadmin* groups?
I think packager groups should also not be reset just based on email.
* If they are Red Hat employees we can use the internal verify thing
Yes. Is there a way we could extend something similar to non-RHers?
* We could use gpg signed email if there is a gpg key assigned to
the
account.
* Could we use ssh key to verify them?
That at least increases the barrier to impersonation.
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
1:46 a.m.
> * Could we require someone enter their password + token before
accepting
> the token? ie, they try and enroll, ipa adds it, they have to verify, if
> they can't, it's removed?
This is _very_ common in other implementations.
Yeah, but there is no API in IPA to do that (we did consider it when
writing the code).
I've been working on this issue yesterday, trying to find a
workaround, but my tests didn't give something usable. I've asked the
FreeIPA folks on IRC and they had no solution (but they had meetings,
so maybe later).
I've noticed that Christian proposed a possible (hackish) way of doing
it yesterday evening in the AAA channel, I'll try that on Monday.
> * Could we add 'recovery codes' so if someone enrolls
and it's
> wrong/broken, they could use a code to login and add a new token and
> remove the old broken one?
Likewise!
Again, there is no API in IPA to do that. Christian suggested a
workaround where we could use a HOTP token to get a similar result,
however the user would still need to enroll the hotp token, so if they
can't enroll their TOTP or if it fails, there's little chance
enrolling the HOTP token will not fail as well.
> 2. How can we verify identity on people who request the removal
of their
> last otp? Do we just tell them to make a new account?
>
> Random ideas:
>
> * If they are not in any groups, how about we just reset based on email?
> * Or perhaps if they are not in any sysadmin* groups?
I think packager groups should also not be reset just based on email.
I can log the creation of OTP tokens in Noggin, and we could maybe
decide that if you ask us to delete a token you've created in the last
20 minutes, we do it based on email?
> * If they are Red Hat employees we can use the internal verify
thing
Yes. Is there a way we could extend something similar to non-RHers?
That would be interesting, how does it work? Can we replicate it in some way?
> * We could use gpg signed email if there is a gpg key assigned
to the
> account.
> * Could we use ssh key to verify them?
Like asking them to edit a file on people.fp.o? But I suppose not
everybody will have an ssh key either.
A.
2:17 a.m.
Hi Aurelien,
Yeah, but there is no API in IPA to do that (we did consider it when
writing the code).
I've been working on this issue yesterday, trying to find a
workaround, but my tests didn't give something usable. I've asked the
FreeIPA folks on IRC and they had no solution (but they had meetings,
so maybe later).
There is an API to verify the token during LDAP bind. However, it only considers active
and not disabled tokens.
There is also an API to synchronize token values during LDAP bind. It also only looks into
enabled tokens.
So technically you can have something like:
- create OTP token and mark it disabled
- show OTP token configuration details to a user
- ask user for this token validation: enter a password and a value
- enable token
- verify token
- if verification fails, disable the token again
I've noticed that Christian proposed a possible (hackish) way of
doing
it yesterday evening in the AAA channel, I'll try that on Monday.
Again, there is no API in IPA to do that. Christian suggested a
workaround where we could use a HOTP token to get a similar result,
however the user would still need to enroll the hotp token, so if they
can't enroll their TOTP or if it fails, there's little chance
enrolling the HOTP token will not fail as well.
You can enroll that token automatically and disable it.
--
/ Alexander Bokovoy
2:27 a.m.
So technically you can have something like:
- create OTP token and mark it disabled
- show OTP token configuration details to a user
- ask user for this token validation: enter a password and a value
- enable token
- verify token
- if verification fails, disable the token again
Some of the "I'm locked out please disable my token" emails I've seen
mention their browser crashing while displaying the token (I suppose
it's not easy to enroll a token on your phone if you're viewing the
page on your phone too, switching app can easily kill background apps
on phones). In that case we wouldn't get a chance to disable the token
after a failed validation. I would prefer not enabling a token until
it's been verified, but if I don't find a way I'll try that, thanks
for the suggestion.
> Again, there is no API in IPA to do that. Christian suggested a
> workaround where we could use a HOTP token to get a similar result,
> however the user would still need to enroll the hotp token, so if they
> can't enroll their TOTP or if it fails, there's little chance
> enrolling the HOTP token will not fail as well.
You can enroll that token automatically and disable it.
Could you explain a bit more how that would work for users? I'm not
getting how a HOTP token could be used for recovery codes.
Thanks for your input!
Aurélien
8:58 a.m.
On Sat, 10 Apr 2021 at 02:46, Aurelien Bompard <abompard(a)fedoraproject.org>
wrote:
> > * If they are Red Hat employees we can use the internal verify thing
>
> Yes. Is there a way we could extend something similar to non-RHers?
That would be interesting, how does it work? Can we replicate it in some
way?
This internal verify only works if both people can login and send back and
forth a secret. It does not work if one party can not log in. The backup
method requires IT to have access to certain personal information from HR
which they can use to work out how trustworthy the person on the other side
is. This is cost prohibitive for us (in both time and wanting to store PII
safely).
> > * We could use gpg signed email if there is a gpg key
assigned to the
> > account.
> > * Could we use ssh key to verify them?
Like asking them to edit a file on people.fp.o? But I suppose not
everybody will have an ssh key either.
A.
_______________________________________________
infrastructure mailing list -- infrastructure(a)lists.fedoraproject.org
To unsubscribe send an email to
infrastructure-leave(a)lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedora...
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
--
Stephen J Smoogen.
11:18 a.m.
On Thu, Apr 08, 2021 at 12:41:43PM -0700, Kevin Fenzi wrote:
...snip...
2. How can we verify identity on people who request the removal of their
last otp? Do we just tell them to make a new account?
Random ideas:
* If they are not in any groups, how about we just reset based on email?
* Or perhaps if they are not in any sysadmin* groups?
* If they are Red Hat employees we can use the internal verify thing
* We could use gpg signed email if there is a gpg key assigned to the
account.
* Could we use ssh key to verify them?
Any thoughts welcome.
So, we have at least a half-dozen of these pending now. ;(
I'm going to just process them later today unless there's strong
objections. My rationale being that we are in a grace period after the
new account rollout, we hope to improve things so people can't get in
this state as easily, and none of them are in 'high security' groups.
We still need a longer term policy, but I don't want all these people
locked out while we figure it out.
kevin
1:10 p.m.
So, we have at least a half-dozen of these pending now. ;(
I have implemented a verification step for OTP tokens, it's currently
under review:
https://github.com/fedora-infra/noggin/pull/584
Once it's merged and deployed, the tokens will only be enabled once
users have proven that their app works, so it should cut down on those
"I'm locked out" requests.
A.
2:43 p.m.
On Tue, Apr 13, 2021 at 08:10:02PM +0200, Aurelien Bompard wrote:
> So, we have at least a half-dozen of these pending now. ;(
I have implemented a verification step for OTP tokens, it's currently
under review:
https://github.com/fedora-infra/noggin/pull/584
Once it's merged and deployed, the tokens will only be enabled once
users have proven that their app works, so it should cut down on those
"I'm locked out" requests.
Thanks a ton!
kevin
12:06 p.m.
Once it's merged and deployed, the tokens will only be enabled
once
users have proven that their app works, so it should cut down on those
"I'm locked out" requests.
OK, it's merged and deployed on staging. If you folks want to test it
out, it's at
https://accounts.stg.fedoraproject.org/
Please tell me if it doesn't work for you.
Thanks!
A.
3:37 a.m.
I tested it and it works.
Just one note: I'm not sure how the token generation works in noggin,
but usually you get a few seconds to use the old code when the new one
is generated, but I just got invalid code when the new one was generated
during typing the old one.
And one question: Is there a way to get rid of the token on staging? I
don't want to enter OTP token each time I want to login on staging.
Michal
On 15. 04. 21 19:06, Aurelien Bompard wrote:
> Once it's merged and deployed, the tokens will only be
enabled once
> users have proven that their app works, so it should cut down on those
> "I'm locked out" requests.
OK, it's merged and deployed on staging. If you folks want to test it
out, it's at
https://accounts.stg.fedoraproject.org/
Please tell me if it doesn't work for you.
Thanks!
A.
_______________________________________________
infrastructure mailing list -- infrastructure(a)lists.fedoraproject.org
To unsubscribe send an email to infrastructure-leave(a)lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedora...
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
7:46 a.m.
Drunken monkey
Otp okay I guess
Thank you for your monitoring
On Fri, Apr 16, 2021, 14:07 Michal Konecny <mkonecny(a)redhat.com> wrote:
I tested it and it works.
Just one note: I'm not sure how the token generation works in noggin,
but usually you get a few seconds to use the old code when the new one
is generated, but I just got invalid code when the new one was generated
during typing the old one.
And one question: Is there a way to get rid of the token on staging? I
don't want to enter OTP token each time I want to login on staging.
Michal
On 15. 04. 21 19:06, Aurelien Bompard wrote:
>> Once it's merged and deployed, the tokens will only be enabled once
>> users have proven that their app works, so it should cut down on those
>> "I'm locked out" requests.
> OK, it's merged and deployed on staging. If you folks want to test it
> out, it's at
> https://accounts.stg.fedoraproject.org/
> Please tell me if it doesn't work for you.
> Thanks!
>
> A.
> _______________________________________________
> infrastructure mailing list -- infrastructure(a)lists.fedoraproject.org
> To unsubscribe send an email to
infrastructure-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedora...
> Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
_______________________________________________
infrastructure mailing list -- infrastructure(a)lists.fedoraproject.org
To unsubscribe send an email to
infrastructure-leave(a)lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedora...
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
11:32 a.m.
On Fri, Apr 16, 2021 at 10:37:06AM +0200, Michal Konecny wrote:
I tested it and it works.
Just one note: I'm not sure how the token generation works in noggin, but
usually you get a few seconds to use the old code when the new one is
generated, but I just got invalid code when the new one was generated during
typing the old one.
I guess this is a question for IPA team...most systems have a window
where the last token is still valid to avoid clock issues, etc. I guess
by default IPA doesn't...
And one question: Is there a way to get rid of the token on staging?
I don't
want to enter OTP token each time I want to login on staging.
Nope... and we don't want you to. You need to use a token if you have
sudo anywhere. We don't want any sudo access to be password only.
kevin
12:11 p.m.
> Just one note: I'm not sure how the token generation works
in noggin, but
> usually you get a few seconds to use the old code when the new one is
> generated, but I just got invalid code when the new one was generated during
> typing the old one.
I guess this is a question for IPA team...most systems have a window
where the last token is still valid to avoid clock issues, etc. I guess
by default IPA doesn't...
Actually, this check is done entirely in Noggin. I can add a validity
window, yeah, if you found it annoying (it'll be by 30 seconds though,
it's always a multiple of the counter).
A.
1103
days inactive
1111
days old
infrastructure@lists.fedoraproject.org
13 comments
7 participants
participants (7)
-
Akash Rao -
Alexander Bokovoy -
Aurelien Bompard -
Kevin Fenzi -
Matthew Miller -
Michal Konecny -
Stephen John Smoogen