Keep displaying expired TOTP token next to the new one

[mkeller]

Aegis has the same UX bug as nearly every other TOTP app. When the timer expires while you are typing a token, you have to start from scratch with the new code.

I know that Aegis has an option to freeze a token when it is tapped, but that's just adding unnecessary work for the user. The right solution would be to make sure the user can always see a token that will stay visible for at least half the TOTP time slot.

The andOTP app implements a simple solution for this: After a token expired, it is still shown on the side (in smaller letters), so that the user can complete their login.

The de-luxe solution would be a sliding window that always shows two tokens:

• Token1 | Token2 // start: future token is shown on the right
• Token1 | Token2 // T1 expired
• ..en1 | Token2 // after 1/3 of the time slot, T1 slides away to the left to make space for an eventual T3
• Token2 | Token3 // last 1/3 of the time slot: new T3 appears
• Token2 | Token3 // T2 expired
• ...

Instead of bold/regular, better use colored/gray text so that the width doesn't change when a token expires.

[ados8]

Really wanting this feature. Aegis is so close to perfect but this has me on the fence to switch over to ente auth. They have backup sync to server across multiple devices and the UI shows your last and current codes.

[claytondaley]

I'm not sure a future code is the best idea since there will definitely be a period of time when it's not valid. It sounds like most websites have a grace period where the old code continues to work. Retaining this code briefly would let someone finish a code they started (if they don't copy/memorize it). If you're going this route, I'd probably go for something like:

[expired code] | [current code]

... and have the expired code fade out over ~5 seconds. That will ensure you're never showing a code that is definitely invalid, but give them a chance to finish a code that might be in a grace period.

[ados8]

As someone who does deployments of MFA it will work for majority of sites. It's commonly one cycle with the past code remaining valid for the life of 1 cycle, usually 30 seconds. This means that you have a lot longer than 5 seconds to use a past code. Once the current code cycle is up it takes the place of the past code but remains usable for the life span of the now new current code. In short you can use a code for up to 1 minute if your cycle is the standard 30 seconds.

[KaKi87]

Hello, Any news on this ? Thanks

[michaelschattgen]

No news on here. We recently had a similar discussion in Matrix about this and this was my response.

It's been a while since we've discussed this internally so I'm open to have another look at this. I'm still leaning towards our initial thought about this issue; most services have a 90 second time window in which your codes will work. Meaning the previous, current and next codes are being accepted. I've never had any issues with the codes from Aegis not working (I tap to freeze the code).

Is there any situation where you really need to see codes other than the current one? In my opinion the UI will look extremely messy with 3 codes per entry.

After this response I tried a few options and the video below is what I came up with. Would swiping an entry be sufficient enough? We still have to discuss this issue internally but in my opinion this might be a good solution without cluttering up our UI.

https://github.com/user-attachments/assets/2d941309-11d2-4571-984c-9258e393db54

[KaKi87]

Personally I would just like the same thing as Ente, i.e. display the next code :

Thanks

[MiCRoPhoBIC]

Personally I would just like the same thing as Ente, i.e. display the next code :

Thanks

I also like this simple and elegant approach.

[michaelschattgen]

I've worked on something a while ago but I wasn't happy with the way it looked. In my opinion it looks cluttered but perhaps we can find ways to improve this...

Besides that (and I keep repeating myself until I get a clear answer): I haven't ran into this issue once where my code didn't get accepted because the 30seconds ran out. All the services that I use do have some kind of grace period. So my question is: what services are you guys using that makes you want this feature?

[ados8]

No news on here. We recently had a similar discussion in Matrix about this and this was my response.

It's been a while since we've discussed this internally so I'm open to have another look at this. I'm still leaning towards our initial thought about this issue; most services have a 90 second time window in which your codes will work. Meaning the previous, current and next codes are being accepted. I've never had any issues with the codes from Aegis not working (I tap to freeze the code).

Is there any situation where you really need to see codes other than the current one? In my opinion the UI will look extremely messy with 3 codes per entry.

After this response I tried a few options and the video below is what I came up with. Would swiping an entry be sufficient enough? We still have to discuss this issue internally but in my opinion this might be a good solution without cluttering up our UI.

qemu-system-x86_64faWgxMiKr0-_Trim.mp4

The problem with that method is it still requires device interaction, at that point freezing the code is more efficient. This is more for no touch interactions or bulk MFA logins whereby your looking down at your phone and entering codes with hands on keyboard.

The instant flaw I noticed with Ente Auth and the main reason I didn't switch is their design is backwards to how it should be. I expected it to work like @claytondaley specified. The current code is front of screen/middle/prominent and when that code is past active it's still readable for another cycle. However Ente doesn't do that, it rips it away and the new code replaces it. The screenshot shows this. The focused white text is the current code and the dim grey is the next, this is titled as such. However your going to read the prominent code but when that runs out it's gone and the previously next code takes its place. So you need to train yourself to read the dim text so when it runs out it takes the bigger white text place and you continue with entering the code. This seems like poor GUI design to me.

[MiCRoPhoBIC]

The main reason is less anxiety and a rush to enter the code before time runs out. Most users are not aware that there is a tolerance with the period. To be honest, I only realized that I was missing this when I saw Ente's interface. About it getting a bit cluttered or out of ideal UX/UI norms - I'm sure that this should be an option in the settings and not on by default. The user will choose whether they want a simple design or more information and less anxiety.

[ados8]

I've worked on something a while ago but I wasn't happy with the way it looked. In my opinion it looks cluttered but perhaps we can find ways to improve this...

Besides that (and I keep repeating myself until I get a clear answer): I haven't ran into this issue once where my code didn't get accepted because the 30seconds ran out. All the services that I use do have some kind of grace period. So my question is: what services are you guys using that makes you want this feature?

Ok I can't speak for everyone but I can answer for me, it's not about the grace period. I suffer from dyslexia, letters and numbers are a major issue for me. I will constantly miss type or swap letters, digits, words in my head. I know of this so I reread and check and correct but this makes me slow. I can also assume people with vision impairments might be aided with having more time.

[ados8]

This is off topic but it would help people with dyslexia if you had a setting to turn on assistive features. One way is to have the numbers alternate in color but there are other known dyslexia assistive text.

[KaKi87]

All the services that I use do have some kind of grace period

That's unlikely, because it's a bad practice, and from my experience, no decent library supports such a feature, so everyone doing that would be writing custom code (or even reimplementing) just for this.

[KaKi87]

The most probable cause for that feeling, would be that your clock is a few seconds ahead of real time, making it look like your codes expire sooner than they actually do.

[michaelschattgen]

That's unlikely, because it's a bad practice, and from my experience, no decent library supports such a feature, so everyone doing that would be writing custom code (or even reimplementing) just for this.

It's... not bad practice. I'm not talking about accepting a TOTP token that has already been used. I'm talking about accepting the previous, current and next code. It's even in the accepted answer in the Stackoverflow post you linked:

If by previous you mean the OTP on or before the current one being generated but not yet used, then no, within limits. Standard implementations of OTPs apply a "window" to overcome sync issues usually.

Also please keep it limited to 1 comment at a time so we don't spam the people watching this issue.

[KaKi87]

I'm talking about accepting the previous, current and next code

That's also what I understood, and that's the issue.

Yes, the standard accepts submitting the current code a little earlier and later than the visible window, but that's not really accepting the previous and next code within the window of the current code.

[fuzzzerd]

I've worked on something a while ago but I wasn't happy with the way it looked. In my opinion it looks cluttered but perhaps we can find ways to improve this...

Besides that (and I keep repeating myself until I get a clear answer): I haven't ran into this issue once where my code didn't get accepted because the 30seconds ran out. All the services that I use do have some kind of grace period. So my question is: what services are you guys using that makes you want this feature?

I understand its a matter of opinion, but I don't think it looks bad. Very much inline with how other apps do it. Additionally, if this is an opt-in setting to display the next code, I think that serves most users well and only those that want it have the extra clutter.

[michaelschattgen]

the standard accepts submitting the current code a little earlier and later than the visible window

earlier: previous code later: next code 'visible window': current code

All I said was that most services have a grace period where usually (at least) two codes are accepted which is not 'bad practice' and is even recommended in RFC 6238.

@fuzzzerd regarding your comment; you're right about it probably being a matter of opinion. While I am not looking forward to have another customization setting for our cards I don't see any other way to get around it. We will discuss this and might choose this route even though we don't really feel the need.

[fuzzzerd]

@michaelschattgen I'm in agreement that its probably good practice to for service providers to be gracious in accepting slightly new/old codes. In practice this works very well most of the time, as many providers do just that.

Since the grace period is opaque to users entering codes, the benefits of a configuration to show the next code are worth an additional setting, IMO, because even in a default configuration with it disabled, the aforementioned grace period will help most users. Only users regularly bumping into this problem will need it, and seek it out.

[mkeller]

After this response I tried a few options and the video below is what I came up with. Would swiping an entry be sufficient enough?

Nice idea, but I'm afraid it's too hard to discover. And it requires user interaction each time the code swapped too early.

To avoid cluttering the initial screen, you could leave that one as is, and only add a

  previous
  123 456

on the right side once the main token got replaced. However, for the problem @MiCRoPhoBIC mentioned:

less anxiety and a rush to enter the code before time runs out.

... that only solves it for experienced users of Aegis who already know and trust Aegis to let them finish entering the code they already started.

[W-i-n-7]

would like to see next code