Delay after entering incorrect (or empty) master password in mini if iCloud sync is enabled

acdx

When using the 1Password mini menubar widget, one can accidentally try to enter an empty master password by quickly hitting enter. This can happen if you're expecting 1Password to already be unlocked. When this happens, it causes a delay of a second or two before you can enter a new password.

1Password should disallow empty master passwords, or provide a preference to disable checking of empty passwords. That way, pressing enter on an empty master password field doesn't cause a password checking delay of several seconds. After all, an empty password provides no security in the first place.

---

1Password Version: Latest App Store
Extension Version: Latest App Store
OS Version: El Capitan
Sync Type: iCloud

Drew_AG

Hi @acdx,

Thanks for taking the time to contact us about that! If I understand, the delay that you're describing is when the 1Password mini window briefly shakes back & forth, right before it shows "Incorrect Password. Please try again." (or the password hint).

If so, I understand what you mean about the empty field being treated as an incorrect master password, when it's not really a password at all. Perhaps an option to disable the "shaking" animation would also help, as long as it allowed you to immediately start typing the master password instead of waiting for a moment? Either way, it's certainly something I can mention to our developers, although I can't promise if/when that will be changed.

Thanks again for letting us know! If you need anything else, we're here for you. :)

acdx

Hi,

I'm referring to the delay that occurs between pressing enter and the shake animation, during which 1Password is deriving a key from the master password. The shake animation is a bit annoying as well, but it's short compared to the time taken to process the password.

I think 1Password should skip trying to check empty master passwords entirely. And perhaps an "allow empty master password" option could be provided in settings as a fallback for those users who, for some reason, have an empty master password set on their vault.

AVS

Always start on a high note: 1Password rules. It has been a HUGE blessing to me and I can't see living without it. I've gotten a ton of friends and family on it and will continue to sing its praises.

Now the "but": Will you please consider getting rid of the delay of the response to an incorrect master password input? I know it's only a second, but it seems interminable and punitive. When you get it right, it the response instantaneous. The jiggle is fine, (it matches Apple's, nice touch) but the delay kills me, on both Mac and iOS. However, iOS is better because I can use TouchID most of the time.

Anyway, I love this product, and this would pretty much round out perfection for me, and I'm sure many others. Thanks so much.

Adam

---

1Password Version: Mac: 5.3, iOS 6.0.1
Extension Version: Mac: 4.4.4
OS Version: OS X 10.11, iOS: 9
Sync Type: iCloud

littlebobbytables

Hello @acdx,

I think the puzzlement I share with Drew is that for me as soon as I press enter the window shakes and I'd put the timespan between pressing enter and the cursor returning at about a second - too short to accurately time without taking a screen recording. I'm just wondering why it seems so slow for you. You mentioned several seconds before, I'm wondering roughly how many would it seem to take for you? Is it a slighter older machine and we're unkindly comparing it to something a bit faster perhaps? I'm just hoping to understand why you're experiencing something different from us.

littlebobbytables

Hi @AVS,

Can I ask a favour, can you check this thread for us please and see if the issue is the same for you? At the moment we're struggling to wrap our heads around it. For example the delay between pressing enter and the jiggling stopping so that I'm returned to the cursor is about a second in total. It seems like you're experiencing something else though as is the other person. Once we understand we can try to look at why and what can be done.

comic_sans

I have the same issue here, same versions and sync type as the first post.

There is a definite 1-2 second delay before any visual cue about wrong password. The delay is not always the same, it varies.

Funny enough, there is no delay when the password is correct.

acdx

Hi,

Yes, it seems to be the same issue as @comic_sans is talking about. Not sure anymore what's causing it, since typing in a correct password doesn't seem to cause a similar delay. Here's a video of it on my late 2013 15-inch MBP (higher end version).

https://www.youtube.com/watch?v=5w08o3gvupg

AVS

Hey there.
I read through it and though his situation is different, the outcome is the same. Whether an incorrect password, or an empty input field, the ~1 second delay is there. Which is strange to me, because when the password is correct, it opens instantly. Zero delay. Logic would dictate that it's not because it's "looking" for the password or anything like that, because it does open instantly when it's correct. It just seems like a setting. It's strange how something so short can seem interminable. But when the correct password is instant, it makes it feel that way and is just so frustrating.

Like the other person said, I can take or leave the jiggle. It's something that I'm used to with OS X, however, it is something that gets in the way of trying again more quickly. But there shouldn't be any delay between hitting enter and the jiggle.

I hope I answered your question. Please feel free to ask me to try anything else.

Adam

comic_sans

Still not fixed in 5.4 update :)

BTW my machine is late 2012 Macbook Pro, so that rules out weak hardware as a cause I guess.

Drew_AG

Thanks @acdx and @comic_sans,

I was about to suggest trying the 5.4 update, but it sounds like comic_sans is a step ahead of me! ;)

Have either of you tried rebooting the Mac to see if it makes any difference? Or if not, would you mind trying that? I'm still unable to reproduce this on my Mac, so I'm not sure what's causing that. I had assumed you were talking about the "shaking" animation, as I don't think I've ever seen a delay before that starts.

comic_sans

Hi @Drew_AG,

yes of course, rebooted multiple times :)

You are right, this is about the delay between hitting the enter key and the start of the shaking animation.

Drew_AG

Hi @AVS, @comic_sans, and @acdx,

I merged both of these threads together, as I believe they're for the same issue. And I have some good news - I was finally able to reproduce this! I didn't think it would have anything to do with the sync method, but I finally tried switching to iCloud sync, and then I was immediately able to recreate the delay you've been describing. The delay doesn't happen if another sync option is being used, or if sync is disabled.

So, I've submitted a bug report to our developers about this, and I apologize for the inconvenience! Since I was able to reproduce it, that should make it much easier for them to figure out why that's happening (I don't have any timeframe for a fix, though). Thank you all so much for bringing this to our attention and helping us to recreate the problem on our end, we really appreciate it! :)

ref: OPM-3337

AVS

Well, this may or may not throw a wrench into the mix, but when I opened the actual 1Password app on my Mac yesterday, and of course typed my master password too fast, it has the delay before the jiggle as well. It's not just the mini version. I knew this but I don't use it nearly as often so I forgot. So, it happens application wide, not just the mini version. And I do remember that happening when I was using Dropbox to sync.

Anyway, I don't know if that helps or hurts, but I thought you should know. Thanks for working on this!

Adam

Drew_AG

Hi @AVS,

Thanks for letting us know! I spoke to a developer and have some additional information about all this, which also explains why you're seeing the same thing happen in the main app.

As it turns out, this isn't a bug. 1Password (main app & mini) can't shake and tell you the master password is wrong until it actually knows that it's wrong. And 1Password doesn't know the master password is wrong until it tests it against the local data, as well as your sync source data (i.e. your sync data in Dropbox or iCloud).

Now, with Dropbox sync, that sync data is stored locally on your Mac, so it's not normally a problem and won't typically cause a noticeable delay before the "shake". But with iCloud sync, we need to use the CloudKit API to check your 1Password sync data in iCloud. So the amount of time that takes depends largely on the speed of iCloud, and that usually takes a bit more time than checking local files on the Mac.

Of course, the delay happens even if you don't enter anything at all in the master password field, and an argument could certainly be made that 1Password shouldn't bother checking to see if a master password is wrong when nothing at all is entered. Perhaps we can do something about that in the future. But as far as entering the wrong master password, I'm afraid a short delay is a bit beyond our control if iCloud sync is being used - it just takes longer to check iCloud than it does to check locally stored sync data.

I'm sorry I don't have a better answer for you about that! But hopefully this at least helps to explain why that delay is happening. If you have more questions about that, please let us know! :)

acdx

Hi @Drew_AG

Is this check done in case you've just changed your master password on another device seconds earlier? That seems like a really rare event not worth checking for every single time a wrong master password is entered, if the check causes a delay like this.

Drew_AG

Hi @acdx,

Yes, that's at least part of the reason it checks your sync data (it's likely there are other reasons as well).

AVS

Hey Drew.

Thank you for all of that. I really appreciate it. The authentication verification time was the first thing I thought of as well. Sadly, there is one major fact that throws a wrench in the theory.

In all three ways to use 1Password, at least on the Mac, (the main application, the main menu input, as well as the browser extension in every browser), when the password is correct the unlock is instantaneous. No exaggeration. It's immediate. And that's why I wrote to you in the first place. I just thought it was the way the app was developed. If the app could verify the correct credentials so fast, it would certainly know if they were incorrect just as fast, right? That's what's throwing me. If there was the same delay for both correct and incorrect input, I wouldn't even think twice about it, and may not have even noticed. (Not that I'm asking for that!) It's just that there is such a (comparatively) noticeable difference when it's incorrect.

I know that this is a VERY minor thing, and I really do appreciate you all spending this amount of CS and development time on such an insignificant thing. However, I'm very glad that you're willing to. It speaks volumes. I can only speak for myself, but I'm sure others join me in my gratitude.

I'm not just blowing smoke. My good friend tried to get me to use 1Password for a year before I caved about six years ago, and it's not hyperbole to say that it's changed my computing world. And now I'm a 1Password evangelist. Things would really stink without it.

Thanks to everyone there.

Adam

comic_sans

Hi again,

I can only agree with @AVS :) So if the check that the password is correct is instantaneous, how come that incorrect password takes more tome to check? As far as I understand, password is incorrect if it is not correct, so... :)

But yes, thank you for this level of support, thumbs up!

acdx

@Drew_AG can correct me, but it seems like 1Password trusts the local data if the password is correct, but checks the remote data if the password you're trying to use is incorrect.

rickfillion

Hi @comic_sans and @acdx,

I can help explain why this is. I coded that feature, and I also wrote a blog post that tries to explain how Master Password Syncing works, which might explain why this is happening. You can read it here.

Determining if your Master Password is correct takes a bit of time, but you're right, it's pretty quick (measured in fractions of a second). Within that same fraction of a second, we'll know that your Master Password is incorrect for your local data. In this case, there are two options for what could be going wrong.

Option 1 : The Master Password is actually really wrong.
Option 2: The Master Password you're using is wrong against against your local data. But on another device you changed your Master Password, and that change was synced up to iCloud, and what you typed could be that new Master Password.

To know whether it's option 1 or 2, we need to fetch your encryption keys from iCloud, and test the password on it. If it's successful, then that means we have Option 2, and in that case we can unlock your vault (via a mechanism I attempt to explain in that blog post) locally. If it's not successful, then we know that it's Option 1.

That fetch of the iCloud data is what's taking time, roughly a second or so.

I hope this helps explain what's going on. If you have any questions, let me know.

Rick

comic_sans

Hi @rickfillion

thank you very much for the explanation, I have no more questions :)

Drew_AG

@comic_sans, on behalf of Rick, you're very welcome! Since he wrote the code for that, he can explain it much better than I can. ;)

@AVS, I wasn't sure if you'd seen Rick's explanation above, so I wanted to ping you here just in case you hadn't. Also, thank you so much for all your kind words, we really appreciate it! We wouldn't be where we are today without awesome users such as yourself, so thank you for cheering us on! :)

AVS

Hey Drew (and Rick)

Yes, I saw Rick's explanation yesterday but hadn't had time to respond. So, thank you, Rick. That seems perfectly reasonable to me. Even though it's a bit off-putting, knowing that there is a perfectly good technical reason for it really does make it OK, for me anyway.

Perhaps if you have an FAQ section, you could add this in there. That could be helpful to others who might wonder the same thing.

I appreciate you all tremendously and thank you caring about your customers enough to take the time to look into this and help us understand just what exactly is going on.

I will continue shouting from the rooftops.

Hope you all have a great week.

Adam

Drew_AG

Hi @AVS,

Thanks for the feedback! I'll let our documentation team know that it would be helpful to explain that delay in our knowledgebase.

And again, thank you for your nice comments! It really puts big smiles on our faces to read things like that. We do love our work and our customers, and it's great to hear that it shows. :)