Discussion:
otp resets
Kevin Fenzi
2021-04-08 19:41:43 UTC
Permalink
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
Matthew Miller
2021-04-08 21:35:15 UTC
Permalink
Post by Kevin Fenzi
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. :)
Post by Kevin Fenzi
* 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.
Post by Kevin Fenzi
* 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!
Post by Kevin Fenzi
* 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.
Post by Kevin Fenzi
* Could we 'hide' the otp setup until you have X groups or something?
While this might help some people... ....... ..... .
Post by Kevin Fenzi
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?
* 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.
Post by Kevin Fenzi
* 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?
Post by Kevin Fenzi
* 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
<***@fedoraproject.org>
Fedora Project Leader
_______________________________________________
infrastructure mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-***@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/***@lists.fedoraproject.org
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastr
Aurelien Bompard
2021-04-10 06:46:34 UTC
Permalink
Post by Matthew Miller
Post by Kevin Fenzi
* 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.
Post by Matthew Miller
Post by Kevin Fenzi
* 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.
Post by Matthew Miller
Post by Kevin Fenzi
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?
* 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?
Post by Matthew Miller
Post by Kevin Fenzi
* 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?
Post by Matthew Miller
Post by Kevin Fenzi
* 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 -- ***@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-***@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/***@lists.fedoraproject.org
Do not reply to spam on the list, rep
Alexander Bokovoy
2021-04-10 07:17:52 UTC
Permalink
Hi Aurelien,
Post by Aurelien Bompard
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
Post by Aurelien Bompard
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
_______________________________________________
infrastructure mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-***@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/***@lists.fedoraproject.org
Do not reply to spam on the list, report it: https://pagure.io/fed
Aurelien Bompard
2021-04-12 07:27:43 UTC
Permalink
Post by Alexander Bokovoy
- 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.
Post by Alexander Bokovoy
Post by Aurelien Bompard
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
_______________________________________________
infrastructure mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-***@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/***@lists.fedoraproject.org
Do not reply to spam on the list, report i
Stephen John Smoogen
2021-04-10 13:58:09 UTC
Permalink
Post by Aurelien Bompard
Post by Matthew Miller
Post by Kevin Fenzi
* 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).
Post by Aurelien Bompard
Post by Matthew Miller
Post by Kevin Fenzi
* 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.
_______________________________________________
To unsubscribe send an email to
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
https://pagure.io/fedora-infrastructure
--
Stephen J Smoogen.
Kevin Fenzi
2021-04-13 16:18:07 UTC
Permalink
On Thu, Apr 08, 2021 at 12:41:43PM -0700, Kevin Fenzi wrote:
...snip...
Post by Kevin Fenzi
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?
* 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
Aurelien Bompard
2021-04-13 18:10:02 UTC
Permalink
Post by Kevin Fenzi
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.
_______________________________________________
infrastructure mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-***@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/***@lists.fedoraproject.org
Do not reply to spam on the l
Kevin Fenzi
2021-04-13 19:43:54 UTC
Permalink
Post by Aurelien Bompard
Post by Kevin Fenzi
So, we have at least a half-dozen of these pending now. ;(
I have implemented a verification step for OTP tokens, it's currently
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
Aurelien Bompard
2021-04-15 17:06:09 UTC
Permalink
Post by Aurelien Bompard
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 -- ***@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-***@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/***@lists.fedoraproject.org
Do not reply to spam on the list, report
Michal Konecny
2021-04-16 08:37:06 UTC
Permalink
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
Post by Aurelien Bompard
Post by Aurelien Bompard
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.
_______________________________________________
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
_______________________________________________
infrastructure mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-***@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/***@lists.fedoraproject.org
Do not reply to spam on the list, report it: https://pagure.io/fedora-i
Akash Rao
2021-04-16 12:46:07 UTC
Permalink
Drunken monkey
Otp okay I guess
Thank you for your monitoring
Post by Michal Konecny
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
Post by Aurelien Bompard
Post by Aurelien Bompard
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.
_______________________________________________
To unsubscribe send an email to
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
Post by Aurelien Bompard
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
https://pagure.io/fedora-infrastructure
_______________________________________________
To unsubscribe send an email to
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
https://pagure.io/fedora-infrastructure
Kevin Fenzi
2021-04-16 16:32:04 UTC
Permalink
Post by Michal Konecny
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...
Post by Michal Konecny
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
Aurelien Bompard
2021-04-16 17:11:47 UTC
Permalink
Post by Kevin Fenzi
Post by Michal Konecny
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.
_______________________________________________
infrastructure mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-***@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/***@lists.fedoraproject.org
Do not reply to spam on the list, report it: https://pag

Loading...