When Can IT Know a Password for a User
-
Now, of course, the obvious (and way, way less secure) alternative is for IT to give a password to an office manager (generally a secretary with that title) who then is tasked with learning a little more computer literacy than others in the office and has to walk around doing the same thing for everyone. Then it's a secretary instead of IT who has done the action. This lowers security a lot, though. It would require transmitting the password to be stored as an interim, and having someone not tasked with being IT knowing all the passwords.
-
@scottalanmiller said in Rocket.chat December Update Removed the Password Field?:
@stacksofplates said in Rocket.chat December Update Removed the Password Field?:
Hopefully none of your clients are under GDPR because this almost certainly violates their password policy.
While the GDPR does a lot of things that seem insane, this really does seem like an impossible thing to be written into their policy. Saving a password "on behalf" of someone seems truly bizarre to be written in. Remember, the user never loses any access to changing the password. They remain 100% in control in both scenarios.
No I mean no one other than the user is supposed to know the password. Clearly this is the exact opposite of that.
-
But in that case, it would just shift with whom you have the same conversation. It's not really unlike any situation with keys. Like going to any website with HTTPS. A temporary session key (which is just a long password) is generated on a user's behalf and often identifies them. That's still working under the GDPR. I think once credentials for users can never be managed on their behalf you start to run into all kinds of unforeseen problems.
It's true, that you can't positively identify that an individual user has done an action, but these are isolated systems. In the Rocket.Chat example, you can't absolutely prove who said what to someone else in the office. A pretty minor point as it is just internal communciations (generally with the helpdesk only.) But countless systems in a normal business have this happen constantly, we just don't think about it because it's a system we don't think about, a manager does it for the end user and doesn't tell IT, it's automated, etc.
-
@stacksofplates said in Rocket.chat December Update Removed the Password Field?:
@scottalanmiller said in Rocket.chat December Update Removed the Password Field?:
@stacksofplates said in Rocket.chat December Update Removed the Password Field?:
Hopefully none of your clients are under GDPR because this almost certainly violates their password policy.
While the GDPR does a lot of things that seem insane, this really does seem like an impossible thing to be written into their policy. Saving a password "on behalf" of someone seems truly bizarre to be written in. Remember, the user never loses any access to changing the password. They remain 100% in control in both scenarios.
No I mean no one other than the user is supposed to know the password. Clearly this is the exact opposite of that.
If that's the case, how would a user ever be given a password at all? Even a password reset link is a temporary password. I don't know of any mechanism in the real world that exists where IT doesn't have the users' passwords until the user decides to reset them.
-
Under the Rocket scheme now, it doesn't stop IT from getting the user's password. We can just look at the email sent out, pull the password from there, and use it. The user could change it on us, but they can do that regardless. It's certainly less effort to just set the password if we wanted to keep it than to have to grab it, but if the GDPR makes it so that IT can never generate a password for someone, then I don't know how any system anywhere works.
-
@scottalanmiller said in Rocket.chat December Update Removed the Password Field?:
@stacksofplates said in Rocket.chat December Update Removed the Password Field?:
@scottalanmiller said in Rocket.chat December Update Removed the Password Field?:
@stacksofplates said in Rocket.chat December Update Removed the Password Field?:
Hopefully none of your clients are under GDPR because this almost certainly violates their password policy.
While the GDPR does a lot of things that seem insane, this really does seem like an impossible thing to be written into their policy. Saving a password "on behalf" of someone seems truly bizarre to be written in. Remember, the user never loses any access to changing the password. They remain 100% in control in both scenarios.
No I mean no one other than the user is supposed to know the password. Clearly this is the exact opposite of that.
If that's the case, how would a user ever be given a password at all? Even a password reset link is a temporary password. I don't know of any mechanism in the real world that exists where IT doesn't have the users' passwords until the user decides to reset them.
Because a password reset forces them to change it. That's the huge difference here. If you're taken to court, a user can say "I've never logged into that before " and you have no recourse, because it was you who logged in for them. I'm not saying it has to be concrete to be proven. I'm saying it costs a ton of money to defend yourself in court. This seems to add to that risk.
-
Now a key security difference, that hasn't been mentioned, is that a reset link triggers the end user to discover that their password was used by someone else if and only if they know the duration of the link expiry and track it.
-
@scottalanmiller said in Rocket.chat December Update Removed the Password Field?:
but if the GDPR makes it so that IT can never generate a password for someone, then I don't know how any system anywhere works.
That's clearly not what was said. You're taking things to the extreme again.
-
@stacksofplates said in Rocket.chat December Update Removed the Password Field?:
@scottalanmiller said in Rocket.chat December Update Removed the Password Field?:
@stacksofplates said in Rocket.chat December Update Removed the Password Field?:
@scottalanmiller said in Rocket.chat December Update Removed the Password Field?:
@stacksofplates said in Rocket.chat December Update Removed the Password Field?:
Hopefully none of your clients are under GDPR because this almost certainly violates their password policy.
While the GDPR does a lot of things that seem insane, this really does seem like an impossible thing to be written into their policy. Saving a password "on behalf" of someone seems truly bizarre to be written in. Remember, the user never loses any access to changing the password. They remain 100% in control in both scenarios.
No I mean no one other than the user is supposed to know the password. Clearly this is the exact opposite of that.
If that's the case, how would a user ever be given a password at all? Even a password reset link is a temporary password. I don't know of any mechanism in the real world that exists where IT doesn't have the users' passwords until the user decides to reset them.
Because a password reset forces them to change it. That's the huge difference here. If you're taken to court, a user can say "I've never logged into that before " and you have no recourse, because it was you who logged in for them. I'm not saying it has to be concrete to be proven. I'm saying it costs a ton of money to defend yourself in court. This seems to add to that risk.
You'd have plenty of recourse. You'd have logs of them having logged in.
You'd also have recourse of "since it's a required part of your job, why were you not logged in?" Claiming to have never done their jobs to pretend to have not logged in seems pretty weak. At that point, your defense in court is always going to be just an end user lying about whatever they think a court will believe and there is no preparation for that kind of stuff.
Even a user who logs in and uses a system for years can just claim someone else was the person who always had that system.
-
@scottalanmiller said in Rocket.chat December Update Removed the Password Field?:
You'd have plenty of recourse. You'd have logs of them having logged in.
No you don't. You have logs of you logging in. They never logged in at all.
-
@stacksofplates said in Rocket.chat December Update Removed the Password Field?:
@scottalanmiller said in Rocket.chat December Update Removed the Password Field?:
but if the GDPR makes it so that IT can never generate a password for someone, then I don't know how any system anywhere works.
That's clearly not what was said. You're taking things to the extreme again.
How was it not said? At some point IT has to generate a log in for the user and the user doesn't have it yet. During that time, IT has a password for the user.
That's not an extreme, that's the standard case we are discussing. The only difference is if we force the user to know what it was, or we don't. But in both cases, all cases, IT knows it for part of the time. And in all cases, the end user can at least optionally know it and control it.
-
@stacksofplates said in Rocket.chat December Update Removed the Password Field?:
@scottalanmiller said in Rocket.chat December Update Removed the Password Field?:
You'd have plenty of recourse. You'd have logs of them having logged in.
No you don't. You have logs of you logging in. They never logged in at all.
That's what they'd say no matter who logged in. The logs show the same thing no matter who it is.
If you log in with your password, or IT logs in with your password, the logs show your password logging in.
-
@scottalanmiller said in Rocket.chat December Update Removed the Password Field?:
@stacksofplates said in Rocket.chat December Update Removed the Password Field?:
@scottalanmiller said in Rocket.chat December Update Removed the Password Field?:
but if the GDPR makes it so that IT can never generate a password for someone, then I don't know how any system anywhere works.
That's clearly not what was said. You're taking things to the extreme again.
How was it not said? At some point IT has to generate a log in for the user and the user doesn't have it yet. During that time, IT has a password for the user.
That's not an extreme, that's the standard case we are discussing. The only difference is if we force the user to know what it was, or we don't. But in both cases, all cases, IT knows it for part of the time. And in all cases, the end user can at least optionally know it and control it.
I replied above. A temporary password with a forced reset is acceptable. Only you knowing their password is not.
-
@stacksofplates said in Rocket.chat December Update Removed the Password Field?:
@scottalanmiller said in Rocket.chat December Update Removed the Password Field?:
@stacksofplates said in Rocket.chat December Update Removed the Password Field?:
@scottalanmiller said in Rocket.chat December Update Removed the Password Field?:
but if the GDPR makes it so that IT can never generate a password for someone, then I don't know how any system anywhere works.
That's clearly not what was said. You're taking things to the extreme again.
How was it not said? At some point IT has to generate a log in for the user and the user doesn't have it yet. During that time, IT has a password for the user.
That's not an extreme, that's the standard case we are discussing. The only difference is if we force the user to know what it was, or we don't. But in both cases, all cases, IT knows it for part of the time. And in all cases, the end user can at least optionally know it and control it.
I replied above. A temporary password with a forced reset is acceptable. Only you knowing their password is not.
Why is it acceptable? I wrote before you responded with that about why it didn't do anything because it doesn't actually tell the logs nor the user anything that is useful unless they know a lot of under the hood details. If the GDPR has this all spelled out, yes, that would do it. But we aren't talking security, we are talking legal insanity for one country. It's important to understand, but it seems completely implausible that they've written this kind of detail into a system - especially when the impact would be so staggeringly broad.
I agree, forcing resets is wonderful. but it effectively enforces by law a level of computer literacy that isn't as common as we all wish that it was, it outlaws the stock practices of nearly every SMB, and it requires some extreme verbage to make valid while not actually changing the reality that there is always a window in which IT can always act as the user and the user not know it and the logs not be able to show it.
-
@scottalanmiller said in Rocket.chat December Update Removed the Password Field?:
@stacksofplates said in Rocket.chat December Update Removed the Password Field?:
@scottalanmiller said in Rocket.chat December Update Removed the Password Field?:
You'd have plenty of recourse. You'd have logs of them having logged in.
No you don't. You have logs of you logging in. They never logged in at all.
That's what they'd say no matter who logged in. The logs show the same thing no matter who it is.
If you log in with your password, or IT logs in with your password, the logs show your password logging in.
No you are the only one who logged in. They open the page with cached credentials.
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?
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.
-
@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.
