One Time Password used to fill regular "username" and "passwords" with 1Password 7.2 and Mojave
Just updated to both Mojave and 1Password 7.2. A specific login I use frequently now gets the OTP populated in the username and password field. I have deleted the item and created a new one. Before adding the OTP to the new item, username and password worked correctly. As soon as I added the OTP to the item, though, it started populating this value into the username and password fields again. Not sure if it's related to Mojave or 1P 7.2 because I updated both at the same time (from High Sierra and 1P 7.1). Things worked fine before the update.
BTW, things seem to work correctly for gmail.
1Password Version: 7.2.1
Extension Version: 7.2.1
OS Version: OS X 10.14
Sync Type: iCloud
Referrer: forum-search:one time password
Comments
-
Hello @tommy_,
It's going to be something quite site specific so how do you feel about sharing the URL with us here in our public forum? We can move the conversation to email if you prefer but I'd definitely like to see the page and by the sounds of it file an issue along with seeing if there is anything we can do to help in the here and now.
0 -
Sure! I should have included that originally. It's for https://www.lds.org/?lang=eng
The sign on page is: https://ident.lds.org/sso/UI/Login?service=credentials
It will be interesting if you can re-create it or if it's "just me".
Thanks for looking into it!
0 -
Hello @tommy_,
So at the moment I can't reproduce the crazy behaviour you're seeing. I tested two scenarios.
- I visited https://ident.lds.org/sso/UI/Login?service=credentials and manually saved a Login item using the steps detailed on How to save a Login manually in your browser. I confirmed filling worked, added a TOTP field and then retested filling.
- I created a Login item from inside of the main 1Password window. I started with only a username and password to confirm it filled correctly and then added a TOTP field and retested filling.
I started in Vivaldi and then tested in Safari in case there was some browser weirdness going on. So far in all my tests filling fills the username and password. I don't have an explanation as to why you're seeing different behaviour at the moment. Just to see if we can get any consistency between us can you test both the ways I've described and let me know if you see the bad behaviour in both.
0 -
I've done quite a bit of testing today trying to isolate the issue. Both of the scenarios you outlined work and fail under certain conditions.
They both work ok if I type in some random numbers to the OTP field in the 1P item.
They both fail if I scan the barcode to get a real OTP for the account. The string value provided when scanning the barcode is like:
otpauth://totp/LDS%20Account:Username?secret=MWERMZLGJK5WIOLDOIUHJKDDMVQWERTY&issuer=LDS%20Account
I kept the same number of characters in the secret, but changed them up. The correct OTP is generated, but it's also pasted into the username and password fields. In fact, I try copying and pasting the above value into an otherwise working item as the OTP value and it does the same thing. Is the string above malformed?
0 -
Hi @tommy_,
That is some fantastic detective work and it explains why I wasn't finding the same results as you. Once I use that string I now see the same filling error and I can get an issue filed to ensure we don't misbehave.
Of course we need to get this working for you now rather than some update later down the lines. What I would recommend is copy the entire OTP URI into a new custom password field on the assumption that you wish to keep a record of it. Then in the TOTP field remove everything but the actual secret so using your dummy example from above (I'm glad you said you changed the secret by the way, saves me worrying about whether it was real and would now need changed) the only bit you would want to keep in the TOTP field will be the
MWERMZLGJK5WIOLDOIUHJKDDMVQWERTYotpauth://totp/LDS%20Account:Username?secret=MWERMZLGJK5WIOLDOIUHJKDDMVQWERTY&issuer=LDS%20Account
(in case that makes it easier).
The secret is the only actual part that is used to generate the code given the URI doesn't specify any of the optional parameters. It will generate the same code but should do so without the demented filling.
Do you find if you adjust the stored TOTP details in this way that more sensible filling occurs?
If you're curious about the TOTP URI the following link seems to be a good resource on the various parts.
https://github.com/google/google-authenticator/wiki/Key-Uri-Format
1Password can either parse a URI or it will use the value stored in the field as the secret which is why we can remove everything else to try and stop the insane filling behaviour.
0 -
After a little more testing with only the value of the secret:
If the secret is 26 or more characters, the problem occurs.
If the secret is 25 or fewer characters, the problem does not occur.This site happens to use a 32-character secret and it doesn't appear to work even if I only use the secret value.
0 -
@littlebobbytables, I'm not nagging to go faster ;) , just curious if you were able to reproduce the same results I got with the different length secrets . . .
0 -
Hello @tommy_,
Sorry, my Friday did not go according to plan at all and I apologise for not getting back to you earlier. If I set the TOTP field in a 1Password Login item to 32 characters made up of uppercase A-Z and digits I find it correctly fills, for me it seems to be some part of the additional parameter
LDS%20Account:Username?that causes 1Password to get confused, at least with the example URI anyway. Unless there is something just weirdly specific about the generated secret I would hope we see similar results.You won't be able to share the real secret of course but is there anything about it that stands out at all and do you see the same result if you use a randomly generated 32 character string?
0 -
I haven't tried very many different strings, but it seems consistent.
As an example, the following causes the problem:
MFRDMZLGME3WIOLDMEYWKOJKLJAnd this does not cause the problem:
MFRDMZLGME3WIOLDMEYWKOJKLThe only difference is that the first example has an additional character. I am using only this string in the OTP field, no other portions of the full syntax is in the field.
Does the first example cause the problem for you?
0 -
Greetings @tommy_,
Something remarkably stupid is going on inside of 1Password.
MFRDMZLGME3WIOLDMEYWKOJKLJmesses up filling.MFRDMZLGME3WIOLDMEYWKOJKLJJfills properly.MFRDMZLGME3WIOLDMEYWKOJKLJJHmesses up filling.MFRDMZLGME3WIOLDMEYWKOJKLJJHRmesses up filling.MFRDMZLGME3WIOLDMEYWKOJKLJJHRDfills properly.MFRDMZLGME3WIOLDMEYWKOJKLJJHRD9fills properly.MFRDMZLGME3WIOLDMEYWKOJKLJJHRD9Sfills properly.For now all I can recommend is you maintain two Login items, one for the username and password of the first stage and a second for the TOTP field until we can correct this insane behaviour. This is some fantastically dumb behaviour, thank you for helping highlight it.
ref: xplatform/filling-issues#290
0 -
That’s super interesting! I’m having a hard time imagining the bug that is causing the problem - it would be interesting to hear the root cause when you get it figured out. I chopped it in half then started adding characters. I didn’t go past the first time I got an error. Thanks for capturing the problem, @littlebobbytables. I’m sure your team will get it fixed quickly.
0 -
I'm with you, I have no idea how this bug managed to exist or what on earth we're doing that would mean we should ever be evaluating a TOTP field in this way that it could affect filling.
0 -
I just want to +1 this issue, I am experiencing the exact same issue as @tommy_ .
0 -
Hello @spaceman_spiff,
The issue is filed and our developers are aware. It will hopefully just be a matter of time to correct whatever is going on and get 1Password to behave more sensibly. Until then, whilst not ideal I hope the workaround I suggested earlier helps.
0 -
+1
0 -
@littlebobbytables thanks and yes, the workaround is very helpful in the meantime. You guys are awesome!
0 -
Hopefully we can get this fixed soon :smile:
0 -
Just a ping on this since it's been a few weeks, any word on a fix for this?
0 -
Hi @spaceman_spiff,
It has been indicated that a future update should correct this but we're talking about code that we're not even testing internally yet and until I've had the chance to test this myself I cannot say anything with certainty. If that all sounds incredibly hand wavy I would agree and I wish I had something more concrete to report. Hopefully I will have something better to report soon.
0 -
@littlebobbytables no problem, thanks for the update!
0 -
No problem sometimes it is worth nudging us just to make sure we haven't forgotten :smile:
0 -
Hello good folks! :)
Thanks for your ongoing patience. While I don't have any meaningful updates, I'd like to echo @littlebobbytables' sentiment; a future update should correct the issue, but we're not sure exactly when that will happen. Stay tuned, and we'll let you know as soon as we have a fix in place. :glasses:
0 -
You can now use the LDS Authenticator app which sends you a push, similar to Duo or Microsoft Authenticator opposed to relying only on a one-time password from 1Password. I wish it wasn't messed up in 1Password but having the app makes things less annoying. Source: https://account.lds.org/help/twoStepVerification
0 -
@jmart75 that’s true, good for people to be aware of!
I really miss the workflow with 1P automatically copying the TOTP value to the clipboard so all I had to do on the next screen was hit Command-V to paste it and then Enter, and away we go. Making a separate item for the TOTP secret as @littlebobbytables suggested is not seamless but for me feels like less of a speed bump that finding my phone, opening it, opening the Authenticator app, clicking the alert.
Thanks @ag_sebastian for the update a few days ago, just FYI this is one I use a lot. I log in at least once a day if not multiple times so a fix here would be awesome. It is probably in my top 3 most used items.
0 -
@spaceman_spiff: 1Password for Mac, 1Password for Windows, 1Password for iOS, and now 1Password for Android (currently in beta) all support copying the TOTP code to the clipboard automatically. Have you tried pasting it? I suspect we'll be able to find a workaround for this particular case, but I did want to be clear that we haven't removed that feature.
0 -
Yep, that's one of my favorite features of 1Password right now! Thanks for checking. What I meant to say is, I miss being able to take advantage of that feature on lds.org. Right now, the handy workaround found by @littlebobbytables requires moving the TOTP secret to a new item. But I'm sure this bug will get squashed sooner or later and we'll be back sailing as smoothly through logins on that site as all the others. :)
0 -
Gotcha! Thanks for the clarification. I understand completely. We'll figure something out. :)
0 -
Hi @tommy_, @spaceman_spiff, @vinny1575, @redneck & @jmart75,
If you've been running 1Password 7 for Mac and experiencing this issue then the latest update, version 7.2.4 includes new filling code that does correct this issue. So you should be able to add the TOTP back to the normal Login item and retain sensible filling.
If you find any examples where this isn't working please let me know. If you're running macOS High Sierra or earlier 1Password 7.1.2 will report that it is up-to-date. That's because we limited 7.2 and later to Mojave from the updater. Earlier versions will be offered the update but we're delaying because 7.2 really needs Safari 12 if you're a Safari user. While Mojave guarantees Safari 12 is present, people may not have updated to Safari 12 yet if they're running one of the slightly older versions of macOS. Downloading a fresh copy of 1Password from "Downloads - 1Password" page and installing over the existing copy will force 1Password to 7.2.4.
0 -
I was able to test this using v7.2.4 on my Mac and it worked as it was supposed to. Thanks to you and your team for fixing this and getting back to us!
Not to look a gift horse in the mouth but is there any word on an update for the Windows client? I tried it with v7.2.617.
Regards,
Jeremy
0
