ML
    • Recent
    • Categories
    • Tags
    • Popular
    • Users
    • Groups
    • Register
    • Login

    When Can IT Know a Password for a User

    IT Discussion
    4
    36
    969
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • stacksofplatesS
      stacksofplates @scottalanmiller
      last edited by

      @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?:

      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.

      Rather than have them put it on a sticky note? It reduces it a lot.

      No I mean increases from the fact that your tram member is the only one who knows the password (whether they remember it or not doesn't matter) and they log into something with a client's password on the clients system.

      That's going to be very hard to defend if something happens with any of that data

      scottalanmillerS 2 Replies Last reply Reply Quote 0
      • scottalanmillerS
        scottalanmiller @stacksofplates
        last edited by

        @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?:

        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.

        Rather than have them put it on a sticky note? It reduces it a lot.

        No I mean increases from the fact that your tram member is the only one who knows the password (whether they remember it or not doesn't matter) and they log into something with a client's password on the clients system.

        That's going to be very hard to defend if something happens with any of that data

        No different than inputting a password for anyone, ever. We have to trust that they will change their passwords and maintain them. That we know that the client is not hiring people who will do that and not enforcing through HR any literacy or security measures doesn't really fall under our problem in court. Doctors have a responsibility to security even when IT is not involved. Pretty much no IT department anywhere never hands out passwords. Some do force users to change them themselves, rather than leaving it to common sense or HR to make that decision. But it's not IT's place to enforce something HR doesn't want. That's an HR decision, we don't have authority to override.

        So I think it's so defendable that it doesn't need to be defended. As we are IT, we have access to reset passwords or just open the database anyway. So that if something were to happen due to us having access, that risk already exists just the same. If the data is stolen because the client never knew their password, we can trivially show that security was better than normal rather than at or below par. Since normally you have users storing and reusing passwords over and over again that are weak; not reusing a very hard password makes it really easy to show just how much more security than normal there is.

        1 Reply Last reply Reply Quote 2
        • scottalanmillerS
          scottalanmiller @stacksofplates
          last edited by

          @stacksofplates said in Rocket.chat December Update Removed the Password Field?:

          and they log into something with a client's password on the clients system.

          That's just every day SMB IT support. It's how the entire industry works. Until you have F500 HR departments enforcing literacy standards, and C suite pushing practices, that stuff is the only way it works. It sounds great to say you can't do this stuff, but it's how every SMB works. You tell an SMB business owner that their cheap labour has to do things that the owners don't want them to for security in that manner and they will laugh and you and get someone else. Because it's not putting their data at risk (IT can get it anyway) and it's not putting the end user at risk (the end user always has the option to manage their own password) and it decreases the risk of hacking (single user, very hard, non-recorded passwords) so why would they want a different process, especially if it costs them money?

          SMBs rely on IT to perform loads and loads of actions on behalf of users who can't do it themselves. This is an every day thing. Is it good? No. Would I do it with my own company? No. But are MSPs and internal IT departments required and paid to do this day in, day out in the SMB realm? Yes.

          stacksofplatesS 1 Reply Last reply Reply Quote 1
          • scottalanmillerS
            scottalanmiller
            last edited by

            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.

            DashrenderD 1 Reply Last reply Reply Quote 0
            • stacksofplatesS
              stacksofplates @scottalanmiller
              last edited by

              @scottalanmiller said in Rocket.chat December Update Removed the Password Field?:

              @stacksofplates said in Rocket.chat December Update Removed the Password Field?:

              and they log into something with a client's password on the clients system.

              That's just every day SMB IT support. It's how the entire industry works. Until you have F500 HR departments enforcing literacy standards, and C suite pushing practices, that stuff is the only way it works. It sounds great to say you can't do this stuff, but it's how every SMB works. You tell an SMB business owner that their cheap labour has to do things that the owners don't want them to for security in that manner and they will laugh and you and get someone else. Because it's not putting their data at risk (IT can get it anyway) and it's not putting the end user at risk (the end user always has the option to manage their own password) and it decreases the risk of hacking (single user, very hard, non-recorded passwords) so why would they want a different process, especially if it costs them money?

              SMBs rely on IT to perform loads and loads of actions on behalf of users who can't do it themselves. This is an every day thing. Is it good? No. Would I do it with my own company? No. But are MSPs and internal IT departments required and paid to do this day in, day out in the SMB realm? Yes.

              Generating a password and giving it to a user is completely different than logging into their service for them, not telling them the password, and checking the always remember me box. One is a normal practice, the other is not. My point was if you are questioned on this, you have no way to defend your employees if they are suspected of using those credentials. This seems like an invitation to court waiting to happen.

              Hopefully none of your clients are under GDPR because this almost certainly violates their password policy.

              scottalanmillerS 2 Replies Last reply Reply Quote 0
              • scottalanmillerS
                scottalanmiller @stacksofplates
                last edited by

                @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?:

                and they log into something with a client's password on the clients system.

                That's just every day SMB IT support. It's how the entire industry works. Until you have F500 HR departments enforcing literacy standards, and C suite pushing practices, that stuff is the only way it works. It sounds great to say you can't do this stuff, but it's how every SMB works. You tell an SMB business owner that their cheap labour has to do things that the owners don't want them to for security in that manner and they will laugh and you and get someone else. Because it's not putting their data at risk (IT can get it anyway) and it's not putting the end user at risk (the end user always has the option to manage their own password) and it decreases the risk of hacking (single user, very hard, non-recorded passwords) so why would they want a different process, especially if it costs them money?

                SMBs rely on IT to perform loads and loads of actions on behalf of users who can't do it themselves. This is an every day thing. Is it good? No. Would I do it with my own company? No. But are MSPs and internal IT departments required and paid to do this day in, day out in the SMB realm? Yes.

                Generating a password and giving it to a user is completely different than logging into their service for them, not telling them the password, and checking the always remember me box. One is a normal practice, the other is not. My point was if you are questioned on this, you have no way to defend your employees if they are suspected of using those credentials. This seems like an invitation to court waiting to happen.

                You have equal grounds to defend knowing a password in both cases. In both cases, you know the password and have no way to know if someone else has used it. It might feel like there is something weird about the client never knowing the password, but that the password knows it or not doesn't change the actual situation which is the IT person at some point knows the password. That's the crux and remains uniform in both scenarios.

                1 Reply Last reply Reply Quote 0
                • scottalanmillerS
                  scottalanmiller @stacksofplates
                  last edited by

                  @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.

                  stacksofplatesS 1 Reply Last reply Reply Quote 0
                  • scottalanmillerS
                    scottalanmiller
                    last edited by

                    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.

                    1 Reply Last reply Reply Quote 0
                    • stacksofplatesS
                      stacksofplates @scottalanmiller
                      last edited by

                      @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.

                      scottalanmillerS 1 Reply Last reply Reply Quote 0
                      • scottalanmillerS
                        scottalanmiller
                        last edited by

                        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.

                        1 Reply Last reply Reply Quote 0
                        • scottalanmillerS
                          scottalanmiller @stacksofplates
                          last edited by

                          @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.

                          stacksofplatesS 1 Reply Last reply Reply Quote 0
                          • scottalanmillerS
                            scottalanmiller
                            last edited by

                            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.

                            stacksofplatesS 1 Reply Last reply Reply Quote 0
                            • stacksofplatesS
                              stacksofplates @scottalanmiller
                              last edited by

                              @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.

                              scottalanmillerS 1 Reply Last reply Reply Quote 0
                              • scottalanmillerS
                                scottalanmiller
                                last edited by

                                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.

                                1 Reply Last reply Reply Quote 0
                                • stacksofplatesS
                                  stacksofplates @scottalanmiller
                                  last edited by

                                  @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.

                                  scottalanmillerS 1 Reply Last reply Reply Quote 0
                                  • scottalanmillerS
                                    scottalanmiller @stacksofplates
                                    last edited by

                                    @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.

                                    stacksofplatesS 1 Reply Last reply Reply Quote 0
                                    • stacksofplatesS
                                      stacksofplates @scottalanmiller
                                      last edited by

                                      @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.

                                      scottalanmillerS 1 Reply Last reply Reply Quote 0
                                      • scottalanmillerS
                                        scottalanmiller @stacksofplates
                                        last edited by

                                        @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.

                                        stacksofplatesS 1 Reply Last reply Reply Quote 0
                                        • scottalanmillerS
                                          scottalanmiller @stacksofplates
                                          last edited by

                                          @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.

                                          stacksofplatesS 1 Reply Last reply Reply Quote 0
                                          • stacksofplatesS
                                            stacksofplates @scottalanmiller
                                            last edited by

                                            @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.

                                            scottalanmillerS 1 Reply Last reply Reply Quote 0
                                            • 1
                                            • 2
                                            • 1 / 2
                                            • First post
                                              Last post