When Can IT Know a Password for a User
-
@stacksofplates said in Rocket.chat December Update Removed the Password Field?:
This whole discussion is proving my point. You think you are going to be able to explain this to a lawyer who has zero understanding of how this works?
My point is that you have to explain this to a lawyer anytime a user makes this claim, regardless of what mechanism is used. They simply claim you had access and this discussion has to happen. What mechanism you have used doesn't change that.
Do I think that it can be explained? Well I hope no one can pass the bar and not be able to understand this, it's really simple.
You can explain it with a key...
You have a door installed on your house. The guy who installed the door has to install the lock. The lock has a key. At some point the installer had the key and not you. If that key was used, there is no way to know if it was used by the lock guy or the customer because any log of its use would just log that the key was used. And that the customer never used the key is just a claim that they make after having been given the key.
"Oh sure, your honor, I had the key but I never used it. Even though it was my job to use it. And my house."
It's valid that they might never have used it. But anyone can make that claim, no matter how often they have used the key. And there is no situation where the locksmith guy didn't have to have the key in his possession for at least a little bit.
-
@stacksofplates said in Rocket.chat December Update Removed the Password Field?:
You can do whatever you want with your business obviously. I'm not telling you to do one thing or another. I'm saying this opens you up to extra risk.
I understand that. What I'm trying to say is that I feel the additional risk is negligible because for it to be used against you, you are in a situation where you didn't need to do this for the user to claim you did anyway. Even if you use ever best practice possible, all the end user has to do is claim that you had access and you have this risk and have to explain and defend it. Lying is pretty powerful for the end user here because it's all too complicated for a court to just understand at face value.
The bigger risk, I feel, is losing tons of clients if you work in the SMB sector and losing the business because you try to enforce security that they don't deem valuable or functional. It comes across as just trying to rack up billable hours and not being helpful. End users force this kind of behaviour from every MSP. I feel we are at the most extremely secure. For example, we store no customer passwords. We refuse. And I know other MSPs do this too, but they are rare. I don't know of any first hand that don't. It's standard practice for MSPs (and SMB IT departments) to keep users' passwords recorded! It's pretty much universal in the SMB space. And customers know they, they call their MSPs to get the passwords that they have forgotten! It's crazy, but that's what people pay MSPs to do for them very broadly.
-
@scottalanmiller said in Rocket.chat December Update Removed the Password Field?:
@stacksofplates said in Rocket.chat December Update Removed the Password Field?:
This whole discussion is proving my point. You think you are going to be able to explain this to a lawyer who has zero understanding of how this works?
My point is that you have to explain this to a lawyer anytime a user makes this claim, regardless of what mechanism is used. They simply claim you had access and this discussion has to happen. What mechanism you have used doesn't change that.
Do I think that it can be explained? Well I hope no one can pass the bar and not be able to understand this, it's really simple.
You can explain it with a key...
You have a door installed on your house. The guy who installed the door has to install the lock. The lock has a key. At some point the installer had the key and not you. If that key was used, there is no way to know if it was used by the lock guy or the customer because any log of its use would just log that the key was used. And that the customer never used the key is just a claim that they make after having been given the key.
"Oh sure, your honor, I had the key but I never used it. Even though it was my job to use it. And my house."
It's valid that they might never have used it. But anyone can make that claim, no matter how often they have used the key. And there is no situation where the locksmith guy didn't have to have the key in his possession for at least a little bit.
So one hand you say "we have them a temporary password that resets when it's used, you can't log in more than once with that password". The other hand you have to say "well our users don't want to type something, so we create a password for them, log into their machine, log into the service with that password and check the remember me box. They never know what the password is so we think that's more secure."
-
I see it as a secure middle ground, balancing things. If you demand your customers have a level of skill that they lack, or a willingness to do what is needed that they don't have, you lose clients and that's the same as losing in court over a rare made up claim against you.
If you store their passwords you risk being a point of breach and that's extremely bad and crosses customer boundaries. Eekk.
Doing security on behalf of customers, using their systems in extra secure ways, raising their security far above what they would do themselves, never storing that data, and never taking away their ability to manage and secure themselves seems to protect against all but the most predatory court (which doesn't care about the law anyway) while also allowing for keeping clients that are paying their IT to do many things on their behalf.
-
@stacksofplates said in Rocket.chat December Update Removed the Password Field?:
So one hand you say "we have them a temporary password that resets when it's used, you can't log in more than once with that password". The other hand you have to say "well our users don't want to type something, so we create a password for them, log into their machine, log into the service with that password and check the remember me box. They never know what the password is so we think that's more secure."
Not really. What I'm saying is that if IT sends you a password reset and you ignore that email (as customers like this do so reliably that you could do it day in and day out they'd never notice; or you could completely intercept it and never have it go to them at all) even just for an hour, IT can use that reset to set a password and log in all that they want until you issue yourself a reset - which is likely never. It's not "one use" in the real world, it's unlimited use. Yes, technically the password itself changes, but that IT has the password continuously doesn't change.
My point was that in both cases, the concern si that IT has the password and the end user doesn't. And that risk exists in both cases.
-
@scottalanmiller said in Rocket.chat December Update Removed the Password Field?:
@stacksofplates said in Rocket.chat December Update Removed the Password Field?:
So one hand you say "we have them a temporary password that resets when it's used, you can't log in more than once with that password". The other hand you have to say "well our users don't want to type something, so we create a password for them, log into their machine, log into the service with that password and check the remember me box. They never know what the password is so we think that's more secure."
Not really. What I'm saying is that if IT sends you a password reset and you ignore that email (as customers like this do so reliably that you could do it day in and day out they'd never notice; or you could completely intercept it and never have it go to them at all) even just for an hour, IT can use that reset to set a password and log in all that they want until you issue yourself a reset - which is likely never. It's not "one use" in the real world, it's unlimited use. Yes, technically the password itself changes, but that IT has the password continuously doesn't change.
My point was that in both cases, the concern si that IT has the password and the end user doesn't. And that risk exists in both cases.
No it is literally one use. Just because you can reset it again doesn't change that. It forces a password change so it's one time use.
But semantics aside, again not telling you what to do. Just pointing out it's not the norm and it could open you up to extra risk.
-
Obviously, tracking things like IP addresses for login and such help. But for something like Rocket, IT has unlimited access... to change the DB, to change the code, to change the logs. While Wall St. firms can reasonably lock that stuff down, no SMB can afford what that takes. And it's never 100%, it just gets pretty good. At some point, as the rule has always been, IT has to be trusted not to use the power of unlimited access to access things.
The importance of the "secure, unique" password process is that logging into something trivial like Rocket.Chat for an end user is vastly more secure to the business than what the end user would do themselves. So from a business perspective, not a user perspective, it's an absolutely increase in security all around. And from a user perspective, that's between them and the business, not them and IT.
We are really just talking about an end user in a business, saying something to another user in a business, and then claiming IT said and that they didn't. And the business caring about what was said.
-
@stacksofplates said in Rocket.chat December Update Removed the Password Field?:
No it is literally one use. Just because you can reset it again doesn't change that. It forces a password change so it's one time use.
Yes, I realize you get just one use before it is reset. But the process gives you unlimited uses from the password process. You get the new password from the reset.
-
@stacksofplates said in Rocket.chat December Update Removed the Password Field?:
Just pointing out it's not the norm and it could open you up to extra risk.
But that's what I'm explaining. It's way, way more secure than the norm in the SMB (which is for the user and IT to know the password, probably management to know it too, and for it to be reused in several places, and probably written down physically.)
What is normal in the SMB is so bad. This is an attempt to dramatically increase security and reduce liability.
-
To give some context...
It's common for workstation in a medical practice to have standard, shared passwords. Often just one user account. So if you were to tie application logins to desktop logins, which would be a great answer in many situations like AD with unique users, that would solve the problem. The app in question (Rocket in the example) would never have a password at all.
But when the desktop login doesn't identify the user, you can't use that. So every application has to have its own security from itself or a third party. So often it is because users aren't used to having password at all that creates the problem.
-
@stacksofplates said in When Can IT Know a Password for a User:
@scottalanmiller said in Rocket.chat December Update Removed the Password Field?:
most of our customers can't handle password resets and ask us to handle it and to put the password into their desktop for them and have it sign in automatically
I get that this is easy money, but with a client's in the medical field I don't see how this doesn't greatly increase your liability.
When HR authorize IT to set the password so the business can access files from the user account directly.
-
@scottalanmiller said in When Can IT Know a Password for a User:
When working with doctors, one of the first things we see everywhere is that they commonly require the same password for all staff and have it published everywhere. That our Rocket.Chat logins are the one secure thing in a sea of insecurity makes it the absolute last point of concern in their entire environment.
ug - so true...
