TOTP password not timing out properly...

kriknosretep

Hello.

I had discussed this issue with AgileBits over Twitter and it was requested that I open a discussion here.

I am using the latest version of 1Password on my iPhone and my Mac. I am also using the latest version of iOS and OS X.

I have noticed that when I use the TOTP feature that you added to 1PW on both the iOS and OS X versions, the password doesn't time out correctly. What I mean is this: On every single site I use a TOTP on (Google, Facebook, Name.com, DropBox, etc.), once the TOTP password expires, I can still use that password to log into any of these sites.

I can write down the password (or copy it to the computer's memory) and literally wait until the timer runs out and a new TOTP appears, and then enter the previous password on the site I am logging into--even after several minutes--and it will still be accepted and I will be logged in. If I wait long enough (I haven't timed it), the previous TOTP will stop working, but it is a significant amount of time after it should have stopped working.

This happens on both the iOS version and the OS X version. I previously used Authy with exactly the same sites and this problem did not exist.

This is obviously a problem that needs to be addressed immediately.

Whoever I was communicating with via Twitter did inform me that he/she was indeed able to replicate the problem.

I await your reply.

Thank you.

Kirk

ag_kevin

Hi @kriknosretep ,

I found the twitter conversation you are referring to, but it doesn't indicate that we could reproduce the problem. Do you have a link to that tweet?

If Authy and 1Password show different TOTP codes, I suggest to go into Authy and find the URL used to generate the code, and compare it to the URL in 1Password. In 1Password, just open the item, and edit it. You can scroll down to the TOTP field and see/copy the URL. Authy support should be able to tell you how to look up the URL in their app. If the two URLs are different, then that would explain why the TOTP codes are different. If they URLs are exactly the same, and the generated codes are different, please let us know.

Now, if the TOTP code continues to work after it has expired, it likely means the server you are connecting to has a grace period to allow for two things:
1. clock drift between your device and the server. Your phone may be ahead of the server by a second or two (or vice versa).
2. slow network conditions that may delay submitting the web page where you entered the current TOTP code.

If Authy's code expired right away, it maybe the service is able to set a grace period per code. It's technically possible that the server provides a different grace period for that URL vs. the one used in 1Password. I don't know for certain if Facebook, Google, or the other services mentioned actually do that.

1Password, or any TOTP client app, can not force a code to work longer because it doesn't send any information to the server at all, so it's not possible for the app to tell the server to accept a code for longer. 1Password simply takes the URL when you set it up and uses that to generate codes. It doesn't send anything to the server. So if a code works later than promised, then the server decided on its own to accept it for a longer amount of time. It's not unheard of for the server to accept the previous one or two codes. After that (i.e. a couple of minutes) they would then not be accepted.

I hope this alleviates your concern. If not, please reply, and let us know if the URLs match between Authy and 1Password. Also, if you have any further questions, please reply.

kriknosretep

Here's the link to the Tweet I mentioned:

https://twitter.com/1Password/status/585199490153504768

ag_kevin

Hi @kriknosretep ,

Thanks for letting us know. The best thing to do now is to compare the URLs between Authy and 1P and see if they are different. You can also try to copy the URL from 1Password and put it in Authy. You should find the codes match then, as well as the expire times. If the codes don't match for the same URLs, let us know.

kriknosretep

Hello.

First off, I have no idea how to find the URL in Authy. There is no way to edit an account in Authy that I can see, and frankly, I don't really want to go to the hassle to contact Authy support. I'm identifying what seems to be a major problem--at least to me--and I think you guys should be willing to do some investigation and not ask your users to do it for you.

Secondly, I did do as you suggested and I copied the URL from 1Password and created a new Authy account for the Gmail account I use at work using that URL.

So, now, in Authy, I have two of these Gmail work accounts set up: The one that I originally set up, using Authy and scanning the QR code that Google displayed on screen while I was setting up the TOTP on their site, and the second one that I manually created an hour ago in Authy using the copied URL from 1Password.

After doing this, the TOTP in 1Password and in Authy was identical for the the test account that I set up in Authy using the copied URL from 1Password. HOWEVER, the TOTP in 1Password (and the test account in Authy) was DIFFERENT than the original Authy account for this same Gmail account that I set up months ago by scanning the aforementioned QR code.

So, yes, you are correct, if I use the URL from 1Password, the TOTP in 1Password and Authy are the same.

Having said all of that, you mention that a server might delay for a second or two because of a time difference between my device and the server before kicking back a TOTP. Please understand this: We are NOT talking a second or two. I just copied a TOTP from 1Password and WAITED FIVE MINUTES before using it and it still worked perfectly and logged me in.

It took at least ten minutes for that code to finally expire and no longer work after it should have expired approximately 9 minutes and 30 seconds earlier.

Respectfully, I don't think this falls in line with what you said above.

Forgive me if I sound frustrated, but I am. Your replies feel like: 1. you aren't taking my concern seriously; and 2. you aren't taking this situation seriously. And when I use a TOTP to make me more secure, I don't think that it's cool that said password should continue to work ten minutes later when it should have expired nine minutes and 30 seconds earlier. I'd be cool with 35 seconds before it expires, but not this.

This behavior exists with the TOTP from 1Password and from the Authy test account that I set up using the 1Password URL, which of course makes complete sense since the URL is the same. This behavior DOES NOT EXIST using the original Authy account that I created months ago by scanning the QR code on Google's website.

I would appreciate it if you guys would take this issue just a bit more seriously, or at least explain to me why this behavior should not be a concern to me.

Thank you.

Kirk

svondutch

For TOTP to work, the clocks of the user's device and the server need to be synchronized. Because not all client/server configurations are, the server will typically accept one-time passwords generated from timestamps that differ by ±1 from the client's timestamp. That being said, 5 minutes sounds like an awful long time.

kriknosretep

Indeed! And it wasn't five minutes before the TOTP expired, it was right around TEN minutes.

Something simply isn't right about that.

svondutch

Some servers are more forgiving than others. That being said, if a server accepts every TOTP that 1Password generates over a period of 5 minutes (or longer), then this sounds like a bug on the server-side.

kriknosretep

But if it's a server side bug, why would this nor occur with Authy?

littlebobbytables

Hi @kriknosretep,

When we add support for TOTP we do so by implementing a very particular algorithm (RFC 6238) that is a function of both a known secret between you and the service and time. The QR code you scan returns a URL identifying it as otpauth but in essence most of the URL can be thrown away as long as the secret remains. This algorithm is completely off-line and by that I mean it does not require any interaction with the service whatsoever. So we don't generate codes with the server but compute the current code based on your secret. The service has the same secret and so as long as your clocks are in sync you will compute the same sequence of codes at the same time.

So our only requirement is to ensure we've implemented this algorithm correctly, everything else is up to the service in question. As long as we're supplying the same sequence of codes as Authy or any other TOTP app and that the codes are changing at the same time then we know we've done our part correctly.

Prior to writing this post I tested 1Password, Authy and another app I found out about today call Duo Mobile. All three were returning the same sequence of codes and change at the same time.

The RFC does cover what it calls Resynchronization and this is in reference to handling delays. Now it doesn't stipulate a maximum number of steps (a step being the duration of a code) and only the service will know how they have configured the validator. As @svondutch says, even 5 minutes sounds like an awful long time as that would be roughly 9-10 steps and 10 minutes is worse. Still, we have no way of knowing how each service has configured their validator.

We do take all issues seriously. TOTP validation though happens server-side and is outside the control of the app being used to authenticate. Gmail for example seem to set theirs at 8 steps for resynchronization which means a window of 4 minutes 29 seconds.

kriknosretep

That's all well and good, but I fail to understand why the code from Authy stops being accepted after 30 seconds while the code from 1Password is accepted for several times that amount. And again, if I use the URL from 1Password in an Authy account then the behavior matches.

What's the difference between scanning a QR code with Authy and scanning the same code with 1Password? Seems like it should produce the same results, but it doesn't.

Kirk

littlebobbytables

Hi @kriknosretep,

For my tests I didn't pass over a URL or the secret, I had all three apps scan in the same QR code to obtain the secret the same way. In one of your previous messages, if I understood correctly, both Authy and 1Password behaved the same when they used the same secret. Did I read and understand you correctly? If I did it seems that the difference is in one 2FA that you set up a while ago for a particular Gmail account.

Now I confess, I'm pretty cavalier when it comes to deleting my own vaults or enabling/disabling the likes of 2FA. I kind of have to if I want to learn and understand what our users see and why. So the first thought that springs to mind is what happens if you disable 2FA on this account and then set it up again, scanning the same QR code in both. Now I can think of two reasons you may not wish to do so. You might have done it at some point in the last couple of days already and that if you have I've missed that part of your post. You may also be reluctant to muck about with it and I can understand that too.

I'm also looking into how we reproduced this as everything I know about TOTP tells me it should not be possible, not from a deterministic algorithm (given knowledge of the variables the results are reproducible) that doesn't interact with the server.