Compromised Login - No, Not Really

RonHeiby

Looked today, and happened to see that my "Feedly" entry is marked as having a "Compromised Login". Cool. Let's go and change it.

Oops. I don't actually have a "Feedly" login. I've told Feedly to use my Google account for authentication, and my login there is not marked as being compromised.

How can I tell 1Password, "There, there. It's OK. Feedly is just fine. Nothing to worry about."? The only thing I can think of is maybe to edit my Feedly entry to give it a password, save it, then delete the phony password, and save it again. Is there anything better?

Thanks.

---

1Password Version: 7.0.4
Extension Version: 70004001
OS Version: macOS 10.13.4
Sync Type: agilebits
Referrer: forum-search:Compromised Login - No, Not Really

rickfillion

Hi @RonHeiby,

Let me make sure that I'm understanding things correctly. On the Feedly site, you're using Google to authenticate? But you still do have a Login item in 1Password whose URL is "https://feedly.com"? Does this login item also have "https://google.com" (or equivalent) to allow you to sign in with that item? Or are you maybe not using that item at all to sign in to Feedly?

If you're not using that item to sign in to Feedly, then I think you have two options:
1. Delete the whole Feedly item, since you're not actually using it.
2. Remove the password from that item. This should mark the item as having a password change after the 'compromise' making it fall out of this list.

If you're using the item and the password field has the same password as your Google password and you've got the Google URL in it, then you could temporarily change the password to something else then change it back. This should mark it as having the password change which is what makes it fall out of the list, and then putting the same password back in should allow you to use that item again.

I hope this helps.

Rick

RonHeiby

I'm not actually using the entry to authenticate. I sign in with my Google credentials and stay signed in on my computer and portable devices. About all that someone could do it they compromised one of them is to mark a bunch of articles as read. The entry doesn't include a Google URL; that's in the Google login entry.

I don't want to remove the entry, as it reminds me in the note that I authenticate with Google, and includes other information.

I can't remove the password, because the entry doesn't have one. Maybe entries without a password shouldn't be marked as having a compromised password. Or maybe there should be a way to say, "No. It's ok. I've got this."

It sounds like the workaround I had suggested is your remaining suggestion. Other thoughts?

AGAlumB

@RonHeiby: I'm in the same boat. Mine just fills "Google" any time I try to login there. Indeed, this is something we're looking into: being able to exclude an item from Watchtower in cases like these. I'm not sure what we'll end up doing, but it's definitely on our radar. Thanks for bringing this up!

socceric

@brenty I'm in the same boat too. I hope the solution is not too far away as it has been 3 months since Ron raised it.

AGAlumB

To be clear, this isn't a bug. It's working very much as intended and won't be as high priority as things we've seen requested frequently since June. But we are looking at ways to accommodate this edge case. Thanks for weighing in!

kjd

I have a similar problem that will be solved with the ability to override specific compromise warnings. I work for a company and one of our many online systems was compromised. However I have logins for dozens of different unrelated systems run by the company and they all show as compromised and there is no way to clear it, even though I long ago changed the password to the compromised system. They have no connection apart from being different sub-domains but within the company's same domain.

Lars

@kjd - yup, that's what we're looking down the road to: allowing users to set their own warnings or at least adjust what is already there. The trouble (other than finding developer time to DO it) is in making sure we do it in such a way as to not allow less tech-savvy users to defeat it altogether, which would sort of negate the point of having those warnings in the first place. We're not ready to announce or release anything on that score just yet, but it is definitely on our developers' radar. In the meantime, I know this is a pain for the few people like you with unusual cases like what you described, so thank you for your patience as we work out how this will look in the future. :)

dmittman

Just a "me, too" post. I have several "bookmark" entries in 1Password, which I keep around for the URL, tags, etc., but that don't have a password entry. Because the website they're associated with apparently had a breach in some part of their authenticated services, my URL-only entry (which doesn't require authentication) is marked as a "compromised login." The only work-around I have to get rid of the orange banner is to actually give the item a password.

AGAlumB

@dmittman: If I'm understanding you correctly, all you need to do is create a new "bookmark" Login item for that site, as the compromise is tied to the date. Because the item predates a known breach, it is going to be marked as compromised until it is updated — and since you can't actually update any login credentials there, it seems like creating a new item might be a better option.

dmittman

Thanks, @brenty, I'll give that a try. What I did already try was to duplicate the entry, but the duplicate as well was marked as "compromised login."

Lars

@dmittman - that's odd -- usually, those types of flags ARE time-based: if you haven't changed a password since the date of the breach, it will be listed as compromised. You're saying that if you give it a password, the item no longer appears as compromised?

dmittman

Yup! I can't go back to triple check, but I do distinctly remember taking an item that was marked "compromised," giving it password, and seeing the "compromised" marking go away. If I removed the password, the marking came back. Duplicating the item resulted in the duplicated item being marked "compromised," although I don't recall playing the password trick on the duplicated item.

Meek

Hey @dmittman, that is indeed strange. I'd like to investigate this a bit further and try to reproduce it on my end. Would you mind letting us know which website you saw this strange behaviour with?

AGAlumB

@dmittman: While I understand it's a bit counterintuitive in a sense, adding a new password where none existed previously is changing the password. I'm not sure it's wrong that 1Password is handling it this way, but I do appreciate that it seems a bit odd in this specific edge case (not having a password saved in the first place). Also, duplicating the item should give you the same password and same date, which is why I suggested creating a new one instead. Does that work?

dmittman

Okay. I used a Login item for my test. The item has (had) no password, and had two URLs: http://www.rootsweb.ancestry.com/usgenweb/il/ilfiles.htm and http://usgwarchives.net/il/ilfiles.htm. I added a simple password ("asdf") and the "Compromised Login" banner did not go away*. I changed the password to "asasdfasdfasdfasdfdf" and banner went away. I removed the password and the banner returned. Passwords classified as "Weak" resulted in the banner remaining. Only when I input a "Fair" password ("asdfasdfasdf") did the banner disappear.

Now, for copying. Duplicating the item with no password resulted in the banner remaining (no surprise there). Duplicating with a strong password also resulted in the banner display. *A surprising behavior is that at some point, using a weak password ("asdf") results in the original and duplicate item displaying a "Weak Password" banner, when earlier in the process, I'm pretty positive that the item displayed the "Compromised Login" banner with the weak password. I could be confused by the fact that the "Compromised Login" and "Weak Password" banners appear to be the same color?

Finally, creating a new item: No luck. The new item also displays the "Compromised Login."

Now, I'm going to do what all bug report recipients hate: introduce a new "bug" report. While working through the above, I had to use the Open in Separate Window feature, which I've never used before. I needed it so I could look at the original item while copying its values to the new item. During this process, I discovered that even though I switched back to Safari to update this text, I couldn't see my Safari window because the 1Password "Separate Windows" were set to always be "on top."

AGAlumB

*A surprising behavior is that at some point, using a weak password ("asdf") results in the original and duplicate item displaying a "Weak Password" banner, when earlier in the process, I'm pretty positive that the item displayed the "Compromised Login" banner with the weak password. I could be confused by the fact that the "Compromised Login" and "Weak Password" banners appear to be the same color?

@dmittman: Interesting. I'm not getting that here, but I'll see if I can reproduce it. But I think you may be right about maybe just misreading the banner before. Indeed, "compromised" and "weak" are the same colour ("vulnerable" as well). Memory is an odd thing, especially after we've been staring at this for so long. ;)

Now, I'm going to do what all bug report recipients hate: introduce a new "bug" report. While working through the above, I had to use the Open in Separate Window feature, which I've never used before. I needed it so I could look at the original item while copying its values to the new item. During this process, I discovered that even though I switched back to Safari to update this text, I couldn't see my Safari window because the 1Password "Separate Windows" were set to always be "on top."

I don't mind a new bug report. I just prefer that a second bug helps explain the first! :lol: However, this is not a bug: the "Open in separate window" feature, much like its predecessor "anchor" (really the same thing, just under a less nautical name now, and with a keyboard shortcut that works even in the item list — ⌘ O) is meant to stay on top so you don't lose the item you're working with by clicking to focus another window — like the web browser. When I open a few of them, they can definitely get in the way, but I find that layering them slightly on top of each other allows me to switch to the one I need with its "title" bar, or grabbing a corner. Let me know if that helps.

Anyway, thank you for your feedback on this! We'll continue to be on the lookout for odd Watchtower behaviour, as we've definitely had some inconsistencies there with the 2.0 release rolling out across very different platforms. Cheers! :)

RonHeiby

Workaround that worked for me was to create a phony "strong" password and prefix it with "Actually, Google Login - " to let me know that it isn't actually real.

AGAlumB

I do the same thing...but I am much less polite to myself than, "Actually..." :lol: