Gmail Reuse Old Password

[Madelyn Westfall]

SoI have created a lot of automations for my customer and each of these automations has connection with the gmail app (especially the send an email module).

Each time tha customer change its gmail password, all these scenarios are broken and I should go myself to each scenario and connect every module of gmail again.

This is a very simple chrome extension which detects if you are using the same password for different domains. It can protect users against password reuse and phishing attacks.How it works:This extensions allows you to set your corporate domain (the domain where you usually login with your personal work account) and the corresponding password.If for some reason you'll try to use your corporate password for a different domain, the extension will detect the event and it will show a warning page. This might protect you against password reuse bad practices and even phishing attacks.Important note: since the extension DOES NOT block any request, it might be possible that even if the extension triggered the warning page, your password could have already been sent. So consider to change your password whenever the extension triggered the warning page.Additional note: at some time you'll need to change your password. In order to let the extension to work properly, you need to update the password in the extension's settings as well.

Over the years I've had several situations where EA has reset my password despite my having no evidence of an actual account breach. No activity, no attempts to change details, no unusual purchases - the only thing that's happened is EA claiming something happened and resetting my password. This is rather annoying, as I cannot reuse old ones and it makes it more annoying to remember new ones when I've been forced to make them instead of doing it myself.

I want to get this out of the way: I'm willing to accept the security risk. Yes, I know, it's bad to reuse passwords and I should have 50 different passwords for 50 different things with all different requirements and numbers and cases and all that. If my account gets stolen for my error, it gets stolen, but I'm willing to take the risk that it won't and I understand if it does, it's my fault.

This has happened again today, so I'd like to ask if there is any way I can possibly switch back to an old password, or, failing that, block or dismiss automated password resets in the future instead of being forced to change it?

Security or not, it is immensely frustrating. If I simply don't log in for long enough, it gets reset.

Additionally, email is the primary recovery method? You're not vetting gmail's security standard, so really you are ONLY inconveniencing your users. I personally believe indemnify, and give users the tools to make good decisions. A pop-up that says not good practice is frankly as far as I am convinced you should good.

Let's say that I've a relatively strong password, but I don't want to use many different passwords for each different service, and let's say that those services provide two-factor authentication using a password and a TOTP, for example like Gmail, Facebook, ...etc

If that other factor is enough to protect your security for you, then sure. The point of multiple passwords is that if one is compromised, they aren't all compromised. If you reuse the password and one account is broken, that factor is broken everywhere it is used. If you don't mind a one time code being all that stands between an attacker and your Gmail account, then there is no reason not to use the same password. It is certainly far less secure, but it's also far more usable. It's a personal choice based on what you think the tradeoff is between security and usability.

You will make things easier for someone looking to compromise your password irrespective of that second factor. You're under the impression that any second factor will be more secure than the first. Think about that for a moment.

Imagine you put your trust in Acme Dual Factor company. You trust that they will be your "overseer" in the sense that you have one key, and they have the other. Chicken or the egg concept. If one was that secure, you wouldn't need the other.

What I have done to manage complex passwords each different across many systems is, I have made myself a mental framework to remember them. It's based on the "something you are, something you have, and something you know" concept.

These are things I can NEVER forget. My phone number holding shift. Where I am from, and what is it I have. There are many mechanisms to commit to memory in order to remember ultra strong passwords. My Truecrypt password is 26 characters, my sign in, 21. Completely DIFFERENT passwords. I remember them all because I created my framework. I back them up using Keepass for safekeeping.

Being able to selectively disable/ignore/hide the "Reused Password" prompt would allow for two things. First, the ability to suppress undesired prompts by the user when it is not relevant. Second, enough friction/difficulty that most end users won't choose to suppress this prompt as a means to subvert good security practices (E.g. not reusing a password).

We'd definitely like to find a way to suppress this warning for multiple logins that are essentially for the same account (e.g. Active Directory, as you mentioned). This is one of the major items I've been advocating for recently. I'm hopeful we can find a solution but we do have a lot of other irons in the fire right now, such as prep work for the upcoming Apple OS releases in the fall. Once we get beyond that hopefully we'll be able to have some development time devoted to resolving this.

I just wanted to second the need for a way to disable the Reused Password warning. If you use the Google Cloud Platform, Google will want to use your Gmail account name and password to log into your Google Cloud Platform / Analytics Dashboard. Your Gmail and your Analytics dashboard are on two separate sites with different URLs.

You can 47th this, but someone else already 3rded it. ;) We're well aware of the need, we just need to figure out a good way of doing this that doesn't hamper the purpose of the feature. We've had some good conversations internally on the subject, and the team is well aware of the need for a solution. I can't make any promises, but I will say that I think we're heading in a good direction.

Please support different website usernames as well as the URL. I have some sites that use my Active Directory name and some that use my email address. I tried creating sections for each site with labels that match the form/text field ids.

Thanks @mgenereu. We're aware that Watchtower's alerting doesn't work well in conjunction with SSO/Active Directory authenticated services. I wish I had more encouraging news to share, but we haven't found a way we can agree on to improve this at this point. Our development team is aware of the problem and the debate about how to handle it continues.

We don't currently have any support in the underlying framework of 1Password for different usernames for different sites, other than by saving separate Login items for each of them. But then you have multiple Login items with the same password, which triggers Watchtower's reused password notification. So we do understand the difficulty, and indeed even run into it internally in some cases.

Just give us a button to dismiss the message, that is, to disable the duplicate verification for that item. You can have a confirmation popup reminding the less technical users about the importance of using different passwords.

I work with a whole lot of clients and most of them use AD, causing up to 10 entires per password. Almost every one of my passwords has a big fat warning on top. This prevents me from noticing the passwords that actually need to be changed, defying the purpose of that feature.

Another example (as if you need more). Facebook and Facebook Messenger are different apps, but use the same Facebook login/password, so get flagged. How about you give us the ability to explicitly link two records. I could then say in my Facebook record that Messenger uses the same credentials, which should allow you to short circuit the reused password check.

Hey, @Ben, here's a variation I've not been able to figure out that's another use case for this feature: I teach on a bunch of different machines -- old a new MacOS's, same witn Windows, and ChromeOS. Primary archive is in dropbox. Without a 1password native ChromeOS app, I use the browser plugin -- but the one that ties to a family archive in your cloud. When I copy the very few entries from my primary archive to the family one so I can at least access them on ChromeOS, it calls them duplicates. That doesn't seem to like it ought to cause the same warning, since it's the same credential, just in two archives. Is the feature that you're discussing the one I'm waiting on to solve this type of reuse warning?

I've got to let you know that we're considering other options due to issues such as these. The general consensus in my organisation seems to be that 1password isn't really built for the workplace. We're not seeing much evidence that this might change anytime soon.

Sorry to hear this! If you are using 1Password is your business, I encourage you to reach out to your account manager at busi...@1password.com and raise your concerns there. They will be happy to discuss this with you ;)

Just leaving my comment here as well, similar situation, the same password on multiple sites due to centralised account management but can't merge them into 1 item with multiple sites as they all have different OTOPs.

Could we not "just" (I put just in quotes as I am also a developer and know when a user says that it is never that simple...) get a tag like "reused" to suppress it, like there is the "http" tag to suppress the warning about links like your router not using HTTPS? Instead of trying to come up with logic to do it automagically

It is possible to have multiple labeled TOTP fields on a single item, for what it's worth. :) The tag thing was always a bit of a hack, and the team decided against using that method going forward. Thanks for expressing your interest here.

3a8082e126