Multiple account to the same site

Hi,
When I login in to a site first time, then 1P asks me to save the credentials....
If I log in to the same site with another set of credentials, 1P does not ask to save the login...

How do I handle this best?

LastPass, fx, can detect that other credentialt are used and prompts to save. I would like 1P to act more or less this way :)

Comments

  • svondutchsvondutch

    Team Member
    edited February 2015

    1P does not ask to save the login

    @w00dyard It should if you log in with a different password (not an existing password). 1Password's auto-save looks at the domain and the password. If an existing Login item with the same password exist for the domain, then it should not prompt. Otherwise, it should.

  • @svondutch Oh, I see, thanks!
    I think I should try to change one of the passwords then :-)

  • @w00dyard that would be a good idea ;)

    Alternatively you can always save a login manually.

  • darkutzdarkutz
    edited February 2015

    @AlexHoffmann the idea of a grate password manager is to have everything automated.. so maybe its best if 1p should check for different username AND password not just password.

    Asking a user of the app to use different passwords is not a solution!

  • svondutchsvondutch

    Team Member

    1p should check for different username AND password not just password

    @darkutz In older versions we used to show the auto-save prompt if the exact username+password combination wasn't already saved, but it caused problems with lots of logins out there. Looking for domain+password really is the better algorithm.

    Asking a user of the app to use different passwords is not a solution

    @darkutz Actually, you should always have unique passwords. Never reuse the same password.

  • @svondutch I have no idea how 1p works "on the inside" but from my experience in the little coding that I once knew it should not matter.. and here is an even better algrithm.. domain/user/pass this way it checks for a domain match and all the user/pass that might be saved.

    On your second remark please let me mention that I never said that having the same password for multiple accounts is safe/smart or anything else.. the only afirmation I made was that asking a user to change something on his side isnt the solution for the app itself that should work regardless of the password you have. Keep in mind that people have multiple accounts and passwords way before 1p was made so when a new user loggs in to his 1 domain 2 account 1 password 1p should save what the user has and yes.. RECOMMEND a change for one or bouth of the passwords.

  • On your second remark please let me mention that I never said that having the same password for multiple accounts is safe/smart or anything else.. the only afirmation I made was that asking a user to change something on his side isnt the solution for the app itself that should work regardless of the password you have.

    I sort of agree with you from a purely technical perspective, however....

    Keep in mind that people have multiple accounts and passwords way before 1p was made so when a new user loggs in to his 1 domain 2 account 1 password 1p should save what the user has and yes.. RECOMMEND a change for one or bouth of the passwords.

    I looked at implementing a 1Password vault as an opportunity to purge any bad password habits that I may have picked up. I went through all of my logins removing duplicate passwords and setting them all to large random passwords.
    So, rather than encourage bad practice, I'd actually recommend a different change which would be warn the user that they are using the same password on multiple accounts and that they should change one of them.

  • @RichardPayne exactly what I said.. recommend not DO NOTHIN.

  • Sorry, I misread your last sentence @darkutz

  • dtearedteare Agile Founder

    Team Member

    Thank you for trying to help us improve our autosave algorithm, @darkutz. We designed it this way for several reasons that we believe are correct, and it's always great to have discussions like these as they force us to prove our assumptions :)

    Your idea of using the full combination of (username, password, domain) when determining if the autosave window should appear is a good one. It makes perfect sense as all three of these pieces of data are needed to make a useable login. In fact, we used this algorithm for a while on both Mac and Windows as it seemed like the right thing to do.

    The full combination of (username, password, domain) ran into a few edge cases that forced us to rethink the implementation. Here are three edge cases that I can think of OTTOMH:

    1. Some sites use javascript to obscure the username before we have a chance to save it. For example, a [email protected] username could be converted to chu**********ts.com before 1Password has a chance to save it. To make things work, the user would need to edit the username to be the correct value. Now that the username field is different, the autosave prompt will appear for the wrong reason.

    2. Selecting the proper username field is not an exact science. There is no formal specification that websites follow for their login pages and so every website is different and does things in their own unique way. Assigning the username and password designations is more of an art than it is a science and so our algorithm needs to take an educated guess during this assignment. This "fuzzy logic" algorithm will never be perfect and so we need to keep enhancing it. Each time it changes, the selected username could change, and when it does the autosave prompt will appear for the wrong reason.

    3. Many sites separate their login process into multiple pages, with the username on one page and the password on another. This means the username would be blank on one page, and the password blank on another. If two separate logins were saved on the site, using the (username, password, domain) matching would work perfectly fine, but most users prefer to have a single login. If we're not careful, the autosave window will appear again for the wrong reason. While we can guard against blank usernames, our code is fairly aggressive about picking a username to pair with the password so we can accidentally grab another field as the username and so the autosave window will be forced to appear again for the wrong reason.

    There are a couple of other edge cases as well, but these on their own are annoying enough that we decided to change our algorithm to use just the (password, domain) combination when determining if the autosave window should appear.

    While the scientist in me would prefer to have the "perfect" algorithm that avoids all these issues, I don't feel it is the best use of time because one of the fundamental tenets of 1Password is using strong, unique passwords everywhere. We believe strongly that every login should use a strong and unique password that isn't used anywhere else and when doing so this simple autosave algorithm works perfectly.

    Another way to look at this is supporting the bad habit of password reuse would end up punishing users who are using strong, unique passwords everywhere. That just feels wrong to me so I elected to go with the simpler algorithm that simply matches on the (password, domain) pairs.

    I hope this helps shed light on why we are using the simpler and more reliable algorithm.

    As for your idea of recommending a password change, this is also a very good idea. We have a similar feature in the Security Audit section of 1Password, but again I fear doing so in a fully automatic way inside the browser will prove troublesome because of these exact same edge cases with the username.

  • One of those "other" edge cases is Google who lock in the account and just present a password field!

  • As for your idea of recommending a password change, this is also a very good idea. We have a similar feature in the Security Audit section of 1Password, but again I fear doing so in a fully automatic way inside the browser will prove troublesome because of these exact same edge cases with the username.

    That could be covered by using an "ignore warning" type message.

  • Hello @dteare your answer was elaborate enough for me to understand your concerts and things you have to do so that 1p to be a reliable application.. heres an idea.. I dont know if its possible but since you guys work with these things for this app I guess you should know. I am a windows user and my browser of choice is Google Chrome.. this browser has always asked me to save new registrations or new logins and it always stored the right username and password.. so because of this I tend to belive that there is such a thing of a perfect algorithm and if not.. then the next best thing I can think of is that google learned these login/registration forms for each website and Chrome can acces it when it needs to. In bouth cases.. why not talk with them and eather get that perfect algorithm or ask for their colaboration for the login/registration forms database. As far as I can tell 1p is a preatty big application so I dont think this couldnt be a good colaboration for bouth 1p and google.

    Just an idea :)

  • @darkutz how does Chrome handle multiple logins for the same url? Does it work with the edge cases that @dteare described?

  • darkutzdarkutz
    edited February 2015

    @RichardPayne here is a photo of how Chrome stores multiple logins with no problem. Yes it is for gmail account here but it works just the same for any website and registration/login form regardles of what password I have.

  • ok, so all Google accounts in the screenshot. Have you tried some of @dteare's edge cases?

  • To be honest I have nothing to try since Chrome always saved all my logins so I never had this issue but since we are talking about it.. maybe @dteare will also privide some links for the 3 edge cases above so we can try Chrome and see how it handles the form and if it works or not.

  • dtearedteare Agile Founder

    Team Member

    CitiBank is one of the trickiest ones:

    https://online.citibank.com/US/JSO/signon/LocaleUsernameSignon.do?locale=en_US

    Notice how it obscures the username when focus leaves the username field. In my testing Chrome didn't offer to save this login, and neither did Safari or Firefox.

    Another fun site is TDCanadaTrust:

    https://easyweb.td.com/waw/idp/login.htm?execution=e2s1

    Notice how the username field is far away from the password field. Again, in my testing, Chrome didn't offer to save this login. Safari saved it correctly, and Firefox saved the login with the wrong username (it saved the value of the Description field as the username).

    These were off the top of my head but I think they do a sufficient job of demonstrating that this is not a simple issue. With that said, please don't get me wrong: we're constantly trying to improve our username detection and we will continue to do so. The problem is each time the algorithm improves it can cause bogus autosave windows to appear for those users with logins created with an earlier version. This is the primary reason I don't want to use the full (username, password, domain) tuple when determining if we should prompt to save or not.

  • @dteare yes it seams that CitiBank is tricky.. but to be honest I think it is because they are trying to keep passwords managers from saving the login.. so that is a security feature that they made.

    The TDCanada Trust is working fine with 1p and LastPass.

    It seams Chrome dosnt promt to save passwords for https. Maybe its because they do bot want to compromise the security intended for https?

    I realise 1p team is confronted with different issues like this.. and hopefully moast of them will be solved. I think colaboration from 1p and such sites should be implemented if possible.

  • MikeTMikeT Agile Samurai

    Team Member
    edited February 2015

    Hi @darkutz,

    to be honest I think it is because they are trying to keep passwords managers from saving the login.. so that is a security feature that they made.

    I don't think it's against the password managers but rather criminal brute-forcing tools, which is not that simple to tell apart from managers as we're doing almost the same thing. There's nothing bad about using password managers.

    It seams Chrome dosnt promt to save passwords for https. Maybe its because they do bot want to compromise the security intended for https?

    It shouldn't matter, https refers to the encryption between the browser and the server it is talking to, not the local computer. Google can offer encrypted storage of password saved for secure sites and they should be encouraging users to use the https site, not discourage them by not saving these sites. However, that's up to Google to decide. People pick us over the browser's built-in managers for a reason.

    I realise 1p team is confronted with different issues like this.. and hopefully moast of them will be solved.

    Our work on our browser extensions and its filling algorithms is never-ending, we will always work on improving 1Password and with your help by reporting these sites, it will.

    I think colaboration from 1p and such sites should be implemented if possible.

    That is a great idea and we are planning to release a few documents (among a few other things) for web developers to work on to improve the compatibility with password managers. These docs would not benefit 1Password but also any password managers and important accessibility tools that many users use.

  • @MikeT thank you for sheding some light on some of the things.. like I said I am no advance user when it comes to coding.. I just have a basic understanding of how things work and I also know things like this take time and carefull coding for the end user to get such simple things but I just wanted to point out some things that are a "must have" in such a big password manager like 1p.

    Speaking of extensions.. would also love to see some modifications done to the Chrome 1p extension witch from I can see it only connects google with the external 1p Helper that actually stores everything. For me as a user it would be more convenient to not have to install 1p Helper and just have the extension in Chrome. First of all because its just one more thing I have to install after a fresh install of windows and second because Chrome dose such a grate job of keeping my data like history and extensions and bookmarks in sync. For example when I have a fresh installed Chrome I just need to sign in to my google account and it brings up all my history and extensions and bookmarks just the way I left them before the installation of windows or the browser itself.

    Like I said in my other post keep up the good work because it is very apreciated and pdo not take the things Ive said as bad remarks.. just things that I concider "basic" in a password manager. If you ever want me to come up with ideas for the app please ask I will do my best to be creative :)

  • MikeTMikeT Agile Samurai

    Team Member

    Hi @darkutz,

    For me as a user it would be more convenient to not have to install 1p Helper and just have the extension in Chrome.

    It would be nice to do this, it would not only allow you to sync your data only via Chrome Sync but also would make it possible to support ChromeOS and other computers that will not allow installation of the full 1Password desktop app.

    However, extensions are very limited in how much it can do. In 1Password 3 version of the extension, we were able to do a basic Javascript version of 1Password that could be self-contained but we quickly ran into limitations where we could not improve our extensions as it was too slow for our needs.

    Keep in mind that extensions are not full-powered apps, they do not have access to everything, and is only meant to extend your browsers with extra features. Lightweight apps that doesn't rely on a lot of things or rely on cloud services can work just great as standalone extensions or Chrome apps but for full-featured apps like 1Password that has a lot of libraries it needs and keeps your data secure on the local drive only, it's not enough for us.

  • Also, because extensions execute via HTML and JS they are potentially at risk from malicious websites trying to break into them. Keeping all of the encryption code in a compiled module that talks to the extension provides some safety from this.

    The helper also allows features such as app logins to work seamlessly using the same shortcut keys are the browsers.

  • I understand it has a more complex system this way I was just saying that if its possible in the future to just have the extension and not the helper with it.. it would be a lot more easyer and would enjoy it much more.

    Again.. it was just an idea.. if its possible then would love to see it.. if not then I will just have to install the helper every time.

  • brentybrenty

    Team Member

    I agree! Definitely something to think about in the future, as the browsers perhaps give extensions more flexibility over time. :)

  • MikeTMikeT Agile Samurai

    Team Member
    edited February 2015

    Hi guys,

    @RichardPayne, you could run native C/C++ code via Google's PNaCL/NaCL, which is also sandboxed: https://developer.chrome.com/native-client

    Not to mention, Google offer custom keyboard shortcuts support for each extension as well. So, for an isolated Chrome setup (like ChromeOS), it could be possible but it is not something that's common at the moment.

  • So, for an isolated Chrome setup (like ChromeOS), it could be possible but it is not something that's common at the moment.

    Neat, but then you'd effectively be providing a platform specific client. It would not be generically translatable to the Windows desktop environment in general, unless most of the other browsers have similar native code sandboxes.

  • MikeTMikeT Agile Samurai

    Team Member

    Hi @RichardPayne,

    Neat, but then you'd effectively be providing a platform specific client.

    That's correct, it'd be providing an extra native client for a Chrome-based platform, although it can be used on several OS platforms via the Chrome browser on Windows, Mac, Linux, and as well as ChromeOS itself. So, for some companies, it does provide them with a big bang for the bucks.

This discussion has been closed.