otp resets

[Kevin Fenzi]

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]

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&gt;
Fedora Project Leader

[Aurelien Bompard]

>  > * 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.

[Alexander Bokovoy]

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

[Aurelien Bompard]

>  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

[Stephen John Smoogen]

On Sat, 10 Apr 2021 at 02:46, Aurelien Bompard <abompard(a)fedoraproject.org&gt;
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/[e-mail]...
>  Do not reply to spam on the list, report it:
>  https://pagure.io/fedora-infrastructure
>  

-- 
Stephen J Smoogen.

[Kevin Fenzi]

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

[Aurelien Bompard]

>  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.

[Kevin Fenzi]

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

[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.

[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

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/[e-mail]...
>  Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure

[Akash Rao]

Drunken monkey
Otp okay I guess
Thank you for your monitoring

On Fri, Apr 16, 2021, 14:07 Michal Konecny <mkonecny(a)redhat.com&gt; 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/[e-mail]...
>  > 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/[e-mail]...
>  Do not reply to spam on the list, report it:
>  https://pagure.io/fedora-infrastructure
>

[Kevin Fenzi]

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

[Aurelien Bompard]

>  > 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.