One username and password for multiple sites.
Yes yes... I know. That's evil. There are valid cases for this type of stuff. I'm a member of a dozen boards (like this one) where I would prefer to have the consistency and there is no real risk to having the same username / password combo.
The primary case for me though is because I am a developer (and will soon need to help QA do this). I carry five or six logins across 5 or more of our own servers, each of whose url can change on me.
I want to create a username password pair that I can favorite and use essentially anywhere. That pair **must ** apply to the page I am on, not start a new page.
Even better would be that functionality tied in with regex url matching! Then I could really go to town (and probably use urls)
1Password Version: 6.7.1
Extension Version: Not Provided
OS Version: OSX 10.12.4
Sync Type: Not Provided
Comments
-
The only way to approximate what you're after is to add additional website entries to the Login that you want to reuse. I definitely understand that there are indeed certain times when the same credentials apply to multiple hostnames, so that's why we allow multiple URLs for a Login.
As for regular expression matching, this isn't something we can do because it would require decrypting the overview of every item in order to execute a regular expression against it, which would be horrendously slow. We keep a couple of hashes of each URL in your items so that we can efficiently look up Logins that match the current page. This wouldn't be feasible for storing regular expressions. The other point about regular expressions is that it is super easy to get them wrong and erroneously allow filling on a page where you really didn't intend it to.
I hope that helps. :)
--
Jamie Phelps
Code Wrangler @ AgileBits
Fort Worth, Texas0 -
Thanks for the answer. Does it help? Well.. I wasn't really hoping for regexes, although I would love to use them.
What is not entirely clear is why not just help enable non-url based 'logins'. In my use case, I have to pick the login anyway, so I am shown a list. It would be nice to mark an item as 'global' in the lists I am presented for websites. Then I just need the fields in the item applied to the active form.
Surely this is a strategy issue, not a technical one.
0 -
Hey @Dilapidus,
Thanks for the answer. Does it help? Well.. I wasn't really hoping for regexes, although I would love to use them.
As @jxpx777 mentioned there are technical reasons why adding support for regexes would be hard, but he also alluded to the fact that adding support for them can make things really easy to get wrong and end up filling data somewhere you didn't want it to be filled. For example, let's say we supported regexes and you could add this to a website field:
facebook.*
. That would then allow that Login item to be filled intofacebook.evilpage.com
.From a strategy point of view, website matching exists to provide the best protection against Phishing we can provide. As we say in our 1Password Security Module article:
1Password only fills passwords on the sites where they were saved. No one can steal your password by pretending to be a site you trust.
Regarding your suggestion:
What is not entirely clear is why not just help enable non-url based 'logins'. In my use case, I have to pick the login anyway, so I am shown a list. It would be nice to mark an item as 'global' in the lists I am presented for websites. Then I just need the fields in the item applied to the active form.
I may be misunderstanding you but it sounds like marking an Login item as "global" in your suggestion would mean that the item would fill regardless of what is in the website field or if the website field was left blank. Would that be correct?
I don't see us adding such an option as it would reduce the built-in phishing protection that is provided by the website field matching. For a non-technical user, toggling the "global" option for a Login item would make it very easy to get that Login item working without this phishing protection.
I hope that helps explain our reasoning.
Best regards,
Matthew0 -
Yes, I truly mean global. Yes I understand the implications and yes I accept the risks. As a class, the 'more technical' user will hardly be more popular, but still, we exist and have some different needs. In my dream world, you might have a sort of 'advanced' mode where I can get away with more, perhaps challenged occasionally to confirm when challenged by 1p.
I think even average users understand the security difference between their login here and the one to their bank account. Despite how easy you make it to carry unique info for each site, I don't really care to do that for low priority stuff even though I do use 1p (with Alfred) as a web page launcher almost exclusively. You have effectively 'coerced' me into better security habits ;-)
I do appreciate the feedback and I quite understand your reasoning. I'm suggesting and wishing, not complaining, so please don't be concerned with my responses. I don't necessarily like the decisions, but that's ok. I build software and understand the business prerogatives.
Thanks!
Rick
0 -
Hey @Dilapidus,
Thanks for understanding, it's always nice to hear suggestions and understand the reasons behind them. We wish we could build all these cools ideas you guys come up for us. Since you're in the business, you'll be well aware that we have to make a call on where to spend our time so that it will benefit the most people.
Hopefully some day we'll be able to accommodate your request for an Advanced mode of operation. For now though, I believe jxpx777's suggestion of adding multiple website fields to a single Login item sounds like it should fulfill your needs. Let us know if that is any use to you or if you've any other questions / suggestions. :chuffed:
Matthew
0 -
Thanks Matthew,
I do that now and it works well enough. I just have to rebuild the urls a lot, not a huge deal compared to the time it saves.
0 -
Glad to hear that method works for what you need.
If you ever need anything else, please don't hesitate to write again. We're always here to help.
Best regards,
Matthew0