Security Issue when not revealing passwords
I love 1password and I really like the new 1p for Teams version. I have been testing with multiple accounts to find out the best option to keep our data save.
One of the options I like a lot it to be able to give users "read only" access and deactivate the option "reveal passwords". The user will then only be able to use the browser extension or the 1P mini app to get logged in on a web-app automatically. The click the entry in 1P and it will take you to the login page and fills in username and password. This works very well but we have a security issue here.
Our clients give us access to their webstore system by creating a user and password. There is no option for us to automatically suspend logins or change passwords all at once. There is also no masterlogin for all the systems at once. So, for security reasons, I would like to give my employees access to the client's system without knowing the password. They can log in using the 1P browser extension but I want to prevent them from copying or writing down the password.
In almost every case, nothing will happen when employees know the username and password but in the case of "emergency", for example when someone leaves the company and "not being nice", I need an option to secure the logins. I can't change all the passwords by hand. So the option "read only" in 1P for Teams in combination with the browser extension is a really good solution.
But.... when entering username and password, almost every browser per default asks me if I want to save this password. As far as I know, I can't deactivate this browser setting with user rights management on the mac. Also, if not the browser, then some will still be able to get these password in clear text using a password manager like lastpass or keypass (no installation needed).
Is there any way to keep the browsers and the users from copying the password if the option "reveal passwords" is deactivated?
Many thanks for your help.
Comments
-
The "Reveal Passwords" access control is meant to prevent casual snooping. Once the login is filled into a web page there are a number of avenues to accessing the plaintext. This setting should prevent non-techie users from viewing the password, but a determined user will be able to find a way.
When setting access control, it is also important to think about the combination of options. In your example, you have everything but "read" disabled, but if you wanted to enable edit, or print, or export... all those could be avenues to accessing the password value regardless of the "Reveal Password" setting.
If you ever have someone leave the company in a "not being nice" manner, you should suspend their 1Password access and change the passwords contained in the vaults they had access to. You can never be sure they didn't make a backup at some earlier point.
We are building audit functionality too, so that, for example, you can see which passwords the user accessed on their last day.
0 -
I like the word "casual" in the reply. When user is restricted to reveal the password, it works but the 'Show web form details' gave out all the details, including that very password that suppose to be invisible to the user. So the feature is for the lazy not for team, a false sense of security.
0 -
Hi @gijsrutten,
I'm sorry. There is no way to prevent people who can use a password from knowing what it is. If I may quote from our white paper (PDF, 450KB) on this. This is in the section that discusses the differences between things that are enforced through cryptography, enforced by the server, or enforced by the client. The "reveal" stuff is enforced by the client. Earlier in that section, several characters are introduced, including a sneaker dog Patty.
The administrators have come to be wary of how the dog Patty (see Story~\ref{story:policy} for background) treats data. They want Patty to have access to the password for the dog door (they want her to be able to leave and enter as she pleases), but they do not want Patty to give that password to any of her friends should her paws accidentally press the "reveal" button.
And so, the administrators limit Patty's ability to reveal the password. She can fill it into the website that controls the dog door (she lives in a somewhat unusual household), but she cannot accidentally press 1Password’s “reveal” button while her friends are watching. This is protected by client policy.
But Patty is a clever dog. When she uses 1Password to fill in the website, she then uses her browser's debugging tools to inspect what 1Password has inserted. She gets the password, and she tells it to all of her friends so they may come and visit.
The house is overrun with Patty's friends running wild, and the administrators have learned an important lesson that client policy controls are easily evaded.
0 -
@dennis_su very correctly warns that the feature to block reveal passwords can give a false sense of security.
I can't promise anything, but we are trying to see if there are ways in which we can present these controls differently. We don't want to add lots of confusing stuff to the user interface, but we are concerned that people will think that the "reveal" control offers as much protection as read access.
ref: b5-557
0 -
Hi
Thank you for the clear discussion.
I have exactly this situation, my 'Patty' is suspected of trying to manipulate the locks on the front door - let alone the pooch porch; hence a rather hurried digital risk asessment towards the end of last week and a sign up to Ip on Friday as I scramble to lock all the silver in a safe place and put a risk mitigation policy in place.
The warning about the ways around the read only cloaking is well taken and I have now developed a secure protocol for changing everything that can't be locked down whilst the dismissal meeting is in progress.
At the moment we are only a 6 strong company but I can see that as we grow this situation is going to become infinitely more complex. Please keep us posted on your progess.
Cheers
Mike0 -
Yes, thanks @chadseld and @jpgoldberg for your answers. I had been wondering about that, too, after an intern commented on being able to figure out the password very easily. He just clicked "copy", opened a new tab ... and voilá.
Incidentally, there might be a bug, which limits the "copy" ability. I´ll have to get back to you on this, though, since I can´t replicate it myself as I don´t have the appropriate hardware: Mac OS X El Capitan, Safari.
0 -
@Unicade_Music please do let us know about that bug when you have access to the right device!
@mikekiy I'm sorry to hear that you have to lock up all your silver :( but I'm glad that @jpgoldberg's explanation made sense
0 -
@nmott Right, I still didn´t have access to the device, but I talked to the guy. After reading a bit more, I think it also might be me mis-using certain control functions. Just read some more ... yup, definitely my fault.
https://discussions.agilebits.com/discussion/comment/277850/#Comment_277850
Disabling "Reveal password" also denies him the ability to copy the password.
Case closed.0 -
@Unicade_Music Glad to hear that other thread cleared things up. The "Reveal password" permission is still something we're ironing out. It can be confusing at times since it doesn't make you think of copy/paste. Thanks for the feedback here. :)
0
