Shared computer use case guidance/Feature Request
Greetings,
I've seen a few similar posts here on the forums, but I have what would seem to me to be a pretty common business use case where we're struggling to use 1password that I think might be worth considering as a feature request. Or maybe someone else here has solved this problem and can offer some advice.
We are a business, we have a teams account, we have Active Directory, but 95% of our users run Macs. In the office we have multiple conference rooms. Each room has an identical setup with a large TV connected to a Mac mini. There is a single user account on the Mac mini, which auto-logs on at startup. That account has appropriate permissions to various shares and services.
The issue is that after the first person on one of these machines and logs into 1password, no one else can use 1password on that machine in that account. So we can't use 1password in our conference rooms, which is a big problem that results in people setting weak passwords on sites they're going to be pulling up in the conference rooms. This represents a pretty substantial portion of our usage of 1password and is a significant issue for us.
For clarity, we can't just have everyone log into those machines with their own account, there are 5 conference rooms, over 50 employees, manually managing 250 local accounts is out of the question. Having a 1password account for the user that is automatically logged into the mac minis is out of the question because each user has different vault access and in order for any user using the account in to have access to all their vaults that 1password account would have to have access to ALL the vaults, meaning too much access for various users.
Another potential solution is to have everyone log in with network accounts, but this will be a pain in the butt initially at least, as each user has to go thru the whole new user setup each time they log in for the first time on each machine (so 5 times for each user, 250+ times). We can't save the users profiles on the network because that is all or nothing, meaning if we did, when they log onto their iMacs or Macbooks, it'll have to pull the whole profile across the network, which wouldn't work for anyone with a sizable profile. And each conf room mac mini will have ~50 network accounts, all of which will be unique to that machine, and when you log in you have to choose from 50+ profiles.
Ideally for our situation, any user could sit down at any computer, logged into any account and log in to their 1password account. This is one of the very few things lastpass did that worked better for us than 1password.
Does anyone have a solution for this situation?
Thanks!
Joe Boren
1Password Version: Latest for all platforms
Extension Version: Not Provided
OS Version: OS X 10.10.x Windows 8.1 & 10
Sync Type: Teams Cloud
Comments
-
Hi @jboren! That's a great question! :+1:
Currently, the 1Password apps are pretty much designed for a single person to use. They store their configuration and data on a per-OS-user-account basis, and so generally speaking the preferred way to use them in a multi-user environment is with separate user accounts.
There are two workarounds I can think of that might be of value to you. The first would be to use the web interface for your account; this would still permit access to all of the data each user has access to in their account, while having a built-in mechanism for quickly switching to a different membership (at the sign-in address for your account, click the "Change Accounts" link under the "Sign-In Button"). Particularly for something like a conference room, the web interface is light-weight, and would be one less client app to manage (keep up to date, etc.).
If you would rather use the client app, then you could also have your members use our "start over" procedure. This would allow them to wipe the 1Password app's configuration and data stored in the shared OS user account, allowing them to sign-in again as themselves the next time they launched the app. You can find our procedure for this here: https://support.1password.com/starting-over/
I hope that helps! :chuffed:
0 -
Hey John,
Somehow I never got the notification that you replied and I was just now being annoyed at the Main Conf room computer, so I came to post this question, searched first and realized I'd already asked and never saw your reply.
Thank you! Those are both great ideas, but they both have the same issue. The web interface log-in requires the user to type in 3 things, 2 of which they remember, the third of which (Access Key), no one does. If I don't check "shared computer" in the web interface it saves the access key, but also saves the username/email, and you can't change it. If I don't, it requires all 3 for the next login. Same with the app, if I start over, I now need 4 bits of info, 2 of which (Access Key and Sign-in Address) no one remembers, cause they never need them in the app on their own computers.
Is there any way to make it remember the Access key but not the username/email?
As long as the access key is a necessity for login, I not sure how this can work on a shared computer. Which, honestly, is a sizable problem for us. The fact that no one can use it on the shared computers means they set weak passwords for services they are going to pull up in the conf rooms. Or the same password for everything. Literally the exact reason we make everyone use a password manager.
Any other ideas? The ideal solution for us would be the web interface OR app, but only needing username/email and password, with the AK/Sign-in Address saved. The alternative is probably having the AK saved in a txt file on the desktop of all the Conf Room computers, which is problematic itself, but maybe better than having people using weak PWs because they can't use the password manager on the shared computers.
Thanks again for the help. I really appreciate the suggestions and having someone to bounce these ideas off. Let me know what you think...
Best regards,
Joe0 -
Joe - whilst waiting on some official comment :-
The Access Key is account sign in specific so remembering this on the PC or saving it in a text file would not be applicable because each user would have a different one. Signing in means you would need to know YOUR access key and YOUR master password and this is true for both the App and the Web Interface.
The Access Key forms part of the encryption/decryption process and therefore also helps to protect the password vault if a weak master password is used. LastPass does not implement this additional protection.
0 -
Maybe what is needed, thinking outside the box for a second, is a new feature that provides the ability to specify the data location for the App data (contains the Access Key and cached vault) via 1password application command line argument. Maybe this data locations could be on a network share or USB stick. This would maybe also allow for portable use of 1Password - which is a feature I would be interested in ;-)
0 -
Maybe what is needed, thinking outside the box for a second, is a new feature that provides the ability to specify the data location for the App data (contains the Access Key and cached vault) via 1password application command line argument. Maybe this data locations could be on a network share or USB stick. This would maybe also allow for portable use of 1Password - which is a feature I would be interested in ;-)
@fryrpc: You other comments are appreciated, at the very least for anyone else who might read this discussion! But I did want to respond to this specifically: to be clear, we have no plans to make a "portable" version of 1Password, but storing user data on a USB is an internist idea. There's still a lot to consider with something like that, but I appreciate you bringing it up! :)
0 -
Somehow I never got the notification that you replied and I was just now being annoyed at the Main Conf room computer, so I came to post this question, searched first and realized I'd already asked and never saw your reply.
@jboren: Hey, better late than never, but I'm sorry you've gone all this time without knowing we'd responded. :blush:
Thank you! Those are both great ideas, but they both have the same issue. The web interface log-in requires the user to type in 3 things, 2 of which they remember, the third of which (Access Key), no one does. If I don't check "shared computer" in the web interface it saves the access key, but also saves the username/email, and you can't change it. If I don't, it requires all 3 for the next login. Same with the app, if I start over, I now need 4 bits of info, 2 of which (Access Key and Sign-in Address) no one remembers, cause they never need them in the app on their own computers. Is there any way to make it remember the Access key but not the username/email?
No there is not. But I think we may be coming at this problem the wrong way...
As long as the access key is a necessity for login, I not sure how this can work on a shared computer. Which, honestly, is a sizable problem for us. The fact that no one can use it on the shared computers means they set weak passwords for services they are going to pull up in the conf rooms. Or the same password for everything. Literally the exact reason we make everyone use a password manager.
Thinking the same thing...
Any other ideas? The ideal solution for us would be the web interface OR app, but only needing username/email and password, with the AK/Sign-in Address saved. The alternative is probably having the AK saved in a txt file on the desktop of all the Conf Room computers, which is problematic itself, but maybe better than having people using weak PWs because they can't use the password manager on the shared computers. Thanks again for the help. I really appreciate the suggestions and having someone to bounce these ideas off. Let me know what you think...
Honestly, while these are certainly use cases well continue to consider, we've got our plates pretty full with much more important things for the foreseeable future. I don't mean that as a value judgement, but rather we've got 1Password 7 coming up and plenty of work to do on 1Password 6 and 1Password.com in the mean time. So, "important" in the sense that there are changes that need to be made first which will benefit more users, before we can consider essentially rearchitecting the 1Password apps (across all platforms) with a multi-user model as opposed to the single-user model we've been using for over a decade. It's definitely something we're interested in though.
So my thoughts as far as your use today would be this: I'm willing to bet that most — if not all — of your team members have mobile devices on them anyway. 1Password.com includes ALL of the apps, so I'd encourage you to consider using those as your "vessel" for sensitive information. It's not on the same level as the pipe dream of a device that fits in your pocket that you can just hook up to a monitor and have a computer with all of your stuff anyway (sorry, Microsoft, but Windows Phone was too little too late), but there are two ways that this is useful in this scenario of accessing data on a trusted (presumably) though not personalized machine in the office:
- Need to sign in to a site? Use a randomly-generated, word-based password for that login, which you can view on your mobile device. It's strong and easy to read/type if you have to. This also minimizes risk if that computer happens to be compromised, as you won't be entering all of your 1Password.com account credentials on it and viewing all of the sensitive data inside just to get one or two things.
- Really need to access your 1Password.com account on an auxiliary machine? Your account credentials are stored in the authorized 1Password app on your mobile device, so you can view them there to help you sign into 1Password.com in the browser, using the "public machine" checkbox to avoid saving the credentials — if for no other reason than to make it easier for the next person to do the same.
In both cases, Large Type can be useful for viewing. Even if this isn't exactly what you're asking for, these are options that will work today. Let me know what you think. :)
0 -
@fryrpc Thanks for the info. I did not realize the AK was unique to each user, that's good to know. I get that it's used as a cryptographic key, and I don't know enough about the way 1password does encryption to really know, but I'm not sure that's any more secure than username + password + 2FA using a generator (not SMS). It may be, but I think it's harder for the end user. Thanks for responding, I appreciate it!
@brenty Thanks for the help. The word-based pw's on mobile looks like the most workable solution. Great, now I have to re-train all my users how to generate passwords! :chuffed: They can probably handle it.... I totally understand that you guys have development priorities. We build websites and use agile, jira, sprints, burndown charts, all that fun stuff. I Totally get it. For whatever it's worth, this would be our #1 Pain-point and I would spend all our votes on this as a feature request. I don't know what % of your customers are businesses, but I would be really surprised if this isn't a pain point for a lot of them. It's particularly hard for us because about 30% of the users spend about 50% of their time in meetings, presentations, demos, etc. This affects them every day. But you have to spend your money where you make money, so if you have other, bigger fish to fry, so be it.
Thanks again for the help. I'm pretty sure we can make the word-based passwords work. Please also consider this to be pleading/begging/sniveling feature request for a fully multi-user model. Now that I think about it, I think this might be the only problem we have with 1password...
Cheers, guys, thanks for the help!
Best regards,
Joe0 -
Thanks for the info. I did not realize the AK was unique to each user, that's good to know. I get that it's used as a cryptographic key, and I don't know enough about the way 1password does encryption to really know, but I'm not sure that's any more secure than username + password + 2FA using a generator (not SMS). It may be, but I think it's harder for the end user. Thanks for responding, I appreciate it!
@jboren: It really is more secure. Unlike an SMS/TOTP code, your Master Password and your (128-bit, randomly-generated) Secret Key are both used to encrypt the data. This secures the data itself, rather than merely access to it. 1Password is designed to withstand attack even if the attacker has your data, and doesn't depend on the "security through obscurity" of them not being able to get it off of our server or one of your devices.
Thanks for the help. The word-based pw's on mobile looks like the most workable solution. Great, now I have to re-train all my users how to generate passwords! :chuffed: They can probably handle it.... I totally understand that you guys have development priorities. We build websites and use agile, jira, sprints, burndown charts, all that fun stuff. I Totally get it. For whatever it's worth, this would be our #1 Pain-point and I would spend all our votes on this as a feature request. I don't know what % of your customers are businesses, but I would be really surprised if this isn't a pain point for a lot of them. It's particularly hard for us because about 30% of the users spend about 50% of their time in meetings, presentations, demos, etc. This affects them every day. But you have to spend your money where you make money, so if you have other, bigger fish to fry, so be it.
You raise some really good point, and it definitely helps to know that "multi-user" support is something that's critical to you. Hopefully we'll be able to do something in this area in the future, but I did want to offer some suggestions that could be useful to you now.
Thanks again for the help. I'm pretty sure we can make the word-based passwords work. Please also consider this to be pleading/begging/sniveling feature request for a fully multi-user model. Now that I think about it, I think this might be the only problem we have with 1password... Cheers, guys, thanks for the help!
Likewise, thanks for taking the time to give us this feedback! If we don't hear from folks like you, we'll never add things like that because we don't know they matter to people. I'll be sure to share your thoughts with the test of the team. :chuffed:
0 -
@brenty I just read this thread with great interest as this is a very similar situation in my company. Here are some ideas on how to make this work without having to restructure 1P completely. There are quite a few paths here with multiple options. The following was really a brain dump of my ideas so sorry if it is confusing or I'm rambling on.
So I see 2 hurdles to overcome in this situation.
1. 1P desktop app is not multi-user friendly.
2. Secure access to a vault is not simple.So 1P app would have to be developed in the following ways.
The 1P app is configured in the advanced settings screen to switch to multi-user mode. When in this mode, when the app quits it would delete all vault information (and to be sure, it would do this at launch too). This would happen on a shared computer when the user logs out or the computer reboots. Similar to using the web interface and using the "shared computer" option to not save the user details locally.
Anytime a user logs in and 1P starts, it would go into a simplified "first-time use" mode where it only has the ability to use an existing 1password.com account and not have the option to create an account or local vault. This brings us to #2.
As you mentioned, the employee likely has a mobile phone with them. If they have 1P on their phone, that could be used as the security authentication point. Think of this as the same as 1P Mini communicating with the web browser extension, but in the opposite direction. The 1P desktop app would be just a tunnel to the 1P mobile app.
Oh, just thought of another way. Don't use the 1P desktop app or 1P mini at all. See if there is a way to have the browser extension connect to the 1P mobile app instead. That way all vault info remains on the phone and nothing is saved locally. You could even require that this only works when the browser window is in private/incognito mode!
A connection could be approved in a few ways
- Physical connection. The phone would have to be plugged into the computer using USB. A secured connection is made between 1P on the computer and the 1P phone app. I've used other apps (like Duet Display) that is able to communicate between desktop and mobile so it should be possible for 1P to do the same.
- Over bluetooth. Similar to USB but using BT to link the computer and the phone. Besides the BT pairing, the connection/access into 1P would have to be authorized.
- If neither of those options work, you could use 1P mini to link to their 1password.com account but using 2FA similar to how Google logins require approval using their phone app. The user would open 1P mini on the shared computer and enter their email address, master password, and 1password.com vault URL (which could be remembered locally if the employees use the same URL). 1P would then send a request back to your server which would push a notification to that user's phone. They would have to open the 1P app on the phone to approve the desktop login. One problem is how to get the account key back to 1P desktop so that it can unlock the vault. Perhaps a VPN like tunnel could be made from the desktop to 1password.com then when the mobile app request is approved, another tunnel is made from the phone to 1password.com, which then the 2 tunnels are connected and the desktop communicates to the mobile through this secure tunnel.
For security, when 1P is in multi-user mode, it only has read access to the vault and passwords are always concealed. It would not have the ability to show the passwords on the screen when viewing in the 1P app or 1P mini sub menus.
If you manage to get the browser extension to link directly to the phone app, an option would be to not show anything on the screen. When logging into a website on the computer, the user would locate the entry on their phone and press a button to push the login over to the browser.
Just like I mentioned above where 1P would purge all the information on launch/quit, if the connection to the phone is dropped, 1P would purge and go back to the start. This would happen if the USB is disconnected, the BT connection drops when they leave the room, or even automatically after a timeout period, which the time limit could be selected on the phone when approving the connection (similar to the existing auto-lock timeout feature).
Of course this doesn't have to be limited to just employees. Anyone could have the ability to use a shared/public computer but still have access to the 1P vault on their phone. I've been at a friends house where I needed to log into a site but just used my phone because I didn't want to bother logging into the 1P web interface. If I was able to use their computer but use my phone for authentication, that would be AMAZING!
So, I know this was a lot of info but I hope it opens up some ideas and options on how to make this happen.
0 -
@Smudge: Thanks for taking the time to share your "brain dump"! I have to disagree with you right off the bat, unfortunately, as advanced options are pretty gross. Even in an enterprise setting, I think it's safe to say that not all users are supernerds. But moving a more 1Password.com-web-app-like experience to a native app may have some merit.
Oh, just thought of another way. Don't use the 1P desktop app or 1P mini at all. See if there is a way to have the browser extension connect to the 1P mobile app instead. That way all vault info remains on the phone and nothing is saved locally. You could even require that this only works when the browser window is in private/incognito mode!
Really cool idea. USB is a problem since connecting a mobile device that way (and unlocking it, so a connection can be established) means its entire contents could be dumped. Not a problem for encrypted 1Password data, but I wouldn't want to put the rest of my stuff at risk. Some other alternatives there though. Not sure how that could be done securely, but it's worth investigating.
If I was able to use their computer but use my phone for authentication, that would be AMAZING!
I agree. That would be awesome. :)
So, I know this was a lot of info but I hope it opens up some ideas and options on how to make this happen.
I don't think that this covers the "how", this stuff would require some serious work to make it possible — and that's if it is even possible, not only technically but also with regard to security — but definitely some interesting ideas. I really enjoyed it. Thank you! :chuffed:
0
