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

«1

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.

  • 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!

  • Hello @tommy_,

    So at the moment I can't reproduce the crazy behaviour you're seeing. I tested two scenarios.

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

  • 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?

  • 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 MWERMZLGJK5WIOLDOIUHJKDDMVQWERTY

    otpauth://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.

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

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

  • 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?

  • @littlebobbytables

    I haven't tried very many different strings, but it seems consistent.

    As an example, the following causes the problem:
    MFRDMZLGME3WIOLDMEYWKOJKLJ

    And this does not cause the problem:
    MFRDMZLGME3WIOLDMEYWKOJKL

    The 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?

  • littlebobbytableslittlebobbytables

    Team Member
    edited February 2019

    Greetings @tommy_,

    Something remarkably stupid is going on inside of 1Password.

    MFRDMZLGME3WIOLDMEYWKOJKLJ messes up filling.
    MFRDMZLGME3WIOLDMEYWKOJKLJJ fills properly.
    MFRDMZLGME3WIOLDMEYWKOJKLJJH messes up filling.
    MFRDMZLGME3WIOLDMEYWKOJKLJJHR messes up filling.
    MFRDMZLGME3WIOLDMEYWKOJKLJJHRD fills properly.
    MFRDMZLGME3WIOLDMEYWKOJKLJJHRD9 fills properly.
    MFRDMZLGME3WIOLDMEYWKOJKLJJHRD9S fills 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

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

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

  • I just want to +1 this issue, I am experiencing the exact same issue as @tommy_ .

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

  • @littlebobbytables thanks and yes, the workaround is very helpful in the meantime. You guys are awesome!

  • Hopefully we can get this fixed soon :smile:

  • Just a ping on this since it's been a few weeks, any word on a fix for this?

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

  • @littlebobbytables no problem, thanks for the update!

  • No problem sometimes it is worth nudging us just to make sure we haven't forgotten :smile:

  • redneckredneck Junior Member

    +1... looking forward to a permanent solution. Hi @tommy_ nice to bump into you again.

  • ag_sebastianag_sebastian 1Password Alumni

    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:

  • 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

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

  • brentybrenty

    Team Member
    edited December 2018

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

  • edited December 2018

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

  • brentybrenty

    Team Member

    Gotcha! Thanks for the clarification. I understand completely. We'll figure something out. :)

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

  • jmart75jmart75
    edited December 2018

    Hi @littlebobbytables,

    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

Leave a Comment

BoldItalicStrikethroughOrdered listUnordered list
Emoji
Image
Align leftAlign centerAlign rightToggle HTML viewToggle full pageToggle lights
Drop image/file