Not for the faint of heart...
-
Sander Rossel wrote:
Now, I just had a discussion about storing those passwords. "It would be nice if we could send the users their password in case they forget." Out of the question because I hash passwords before I store them. "But we're not storing user data and it would be more practical if we knew these passwords... We won't be hacked and even if we were it wouldn't be a problem since the data is not very important..." Why the [mastadon] am I even having this discussion in 2021 with a fellow IT professional!? X|
Still better than "It would be nice if we could see their passwords to login as them when they're reporting a problem to try reproduction to see if it's a real problem or user error". Not a multinational sized customer but still... ðŸ˜ðŸ˜
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, weighing all things in the balance of reason? Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful? --Zachris Topelius
I worked at a company that had an impersonate button in one of their apps. It had to be a secret as it violated about every privacy law imaginable :laugh: Not as bad as your case as we couldn't see their password, but besides that it's pretty much the same.
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
-
I worked at a company that had an impersonate button in one of their apps. It had to be a secret as it violated about every privacy law imaginable :laugh: Not as bad as your case as we couldn't see their password, but besides that it's pretty much the same.
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
For what they want to do, and considering that the people using it would be the same people who would be running/using reports dumping everything the users entered into the system (so they can fold, spindle, and mutilate it into an conclusion of "our system works, give us another grant to run it next year"), if they would give us a chance to breathe on the flood of new features an impersonate - for everything but saving as the other user - feature is what I wish we had time to give them. As far as privacy rules go when we pushed on needing to do various GDRP related things if they wanted to expand into the EU "our research ethics commission is already so strict on what we're allowed to do that there's no way we'd need to change anything" (no one at my company has ever seen these rules :doh: ), and separately "we asked our universities legal dept and they said 'GDRP means we can do whatever we want'" :omg: :wtf: . But all talk of doing stuff overseas stopped around that point in time. 🤔
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, weighing all things in the balance of reason? Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful? --Zachris Topelius
-
I worked at a company that had an impersonate button in one of their apps. It had to be a secret as it violated about every privacy law imaginable :laugh: Not as bad as your case as we couldn't see their password, but besides that it's pretty much the same.
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
I used to build in an impersonate option, completely bypassed the logon function and set the dev up as the user. Mind you they were desktop applications on a local network.
Never underestimate the power of human stupidity - RAH I'm old. I know stuff - JSOP
-
So two years ago, I created a service for a client, with which their suppliers could connect. It's based on a "standard" (which turned out to be standard-ish) that even pre-dates XML. So anyway, there isn't a GUI that the supplier can use to manage their account. An account is created by the IT department, who creates a username and password and communicates that to the supplier. Communicating passwords is a bit sketchy, but doesn't have to be a problem. Turns out the IT department is using an ascending number (starting at 1) as a password and stores that in an Excel sheet :| Apparently, the only check I have is that a password should be at least 8 characters. I didn't think I needed more than that as we're talking about an IT department here. They simply tell their suppliers "your password to log in is 00000001." and not a single supplier has complained yet. Now, I just had a discussion about storing those passwords. "It would be nice if we could send the users their password in case they forget." Out of the question because I hash passwords before I store them. "But we're not storing user data and it would be more practical if we knew these passwords... We won't be hacked and even if we were it wouldn't be a problem since the data is not very important..." Why the :elephant: am I even having this discussion in 2021 with a fellow IT professional!? X| Still better than their current system which does not run on HTTPS and actually shows your password on screen X| No one can fix it either because no one knows who made it or where/how it's hosted and it's not even that old yet :laugh: In case you're thinking this must be some small local shop, it's actually a pretty large multinational :sigh:
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
-
I worked at a company that had an impersonate button in one of their apps. It had to be a secret as it violated about every privacy law imaginable :laugh: Not as bad as your case as we couldn't see their password, but besides that it's pretty much the same.
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
This brings up an interesting debate I have had with some management members of a corp I do software development for. If the software belongs to the corp, and the person using it is an employee of said corp, and the software is only used for business related data... is it really an invasion of privacy to 1) know their password? or 2) impersonate their user for debugging purposes? I honestly don't have an opinion on this. I have seen both sides of the argument... a case where the problem ONLY came up for that one single user and couldn't be duplicated in any other way... and a case where somebody maliciously used their ability to impersonate a user to get said user into trouble. I guess as with many things in life, good judgement on need and urgency are better than absolute policy.
-
This brings up an interesting debate I have had with some management members of a corp I do software development for. If the software belongs to the corp, and the person using it is an employee of said corp, and the software is only used for business related data... is it really an invasion of privacy to 1) know their password? or 2) impersonate their user for debugging purposes? I honestly don't have an opinion on this. I have seen both sides of the argument... a case where the problem ONLY came up for that one single user and couldn't be duplicated in any other way... and a case where somebody maliciously used their ability to impersonate a user to get said user into trouble. I guess as with many things in life, good judgement on need and urgency are better than absolute policy.
HuntrCkr wrote:
is it really an invasion of privacy to 1) know their password? or
Yes always, there's a very good chance that user uses this password everywhere. If you know their password you could probably login to their Facebook, Google, Instagram and bank accounts. If someone hacks your database and the passwords are not sufficiently secured (and personally I think anything less than a strong hash is not sufficient), those hackers can now login to those accounts too. And if those hackers post everything online, everyone can login to those accounts. It doesn't matter what data a password secures, the password in itself is private and VERY SENSITIVE data. In a perfect world it would be some "unhackable" randomly generated string of at least 24 characters, but we're living in a world where 123456 is still the most used password.
HuntrCkr wrote:
- impersonate their user for debugging purposes?
Depends what the system does. In our case, the application had data on where users went, when they went and how they went. It kept train tickets, parking tickets, locations, times, everything. Now that's pretty sensitive information and the entire team had access to it because of some impersonation feature. But let's assume it's all business data and not linked to any one person... Right now. What if that data is added in the future?
HuntrCkr wrote:
a case where the problem ONLY came up for that one single user and couldn't be duplicated in any other way
Been there, done that. Schedule a call with the user, add boatloads of logging, get only that part what you need from the production database (preferably from a "privileged" individual who has rights to that database). I've never actually needed impersonation to solve a problem.
HuntrCkr wrote:
a case where somebody maliciously used their ability to impersonate a user to get said user into trouble
And that invalidates all reasons why you should have an impersonation button or make passwords recoverable :)
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook)
-
That reads like a story from TheDailyWTF
Did I post on the wrong forum again? :laugh:
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
-
Did I post on the wrong forum again? :laugh:
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
It certainly is a good story to read while relaxing in a lounge chair to lounge music B)
-
HuntrCkr wrote:
is it really an invasion of privacy to 1) know their password? or
Yes always, there's a very good chance that user uses this password everywhere. If you know their password you could probably login to their Facebook, Google, Instagram and bank accounts. If someone hacks your database and the passwords are not sufficiently secured (and personally I think anything less than a strong hash is not sufficient), those hackers can now login to those accounts too. And if those hackers post everything online, everyone can login to those accounts. It doesn't matter what data a password secures, the password in itself is private and VERY SENSITIVE data. In a perfect world it would be some "unhackable" randomly generated string of at least 24 characters, but we're living in a world where 123456 is still the most used password.
HuntrCkr wrote:
- impersonate their user for debugging purposes?
Depends what the system does. In our case, the application had data on where users went, when they went and how they went. It kept train tickets, parking tickets, locations, times, everything. Now that's pretty sensitive information and the entire team had access to it because of some impersonation feature. But let's assume it's all business data and not linked to any one person... Right now. What if that data is added in the future?
HuntrCkr wrote:
a case where the problem ONLY came up for that one single user and couldn't be duplicated in any other way
Been there, done that. Schedule a call with the user, add boatloads of logging, get only that part what you need from the production database (preferably from a "privileged" individual who has rights to that database). I've never actually needed impersonation to solve a problem.
HuntrCkr wrote:
a case where somebody maliciously used their ability to impersonate a user to get said user into trouble
And that invalidates all reasons why you should have an impersonation button or make passwords recoverable :)
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook)
Sander Rossel wrote:
Yes always, there's a very good chance that user uses this password everywhere. If you know their password you could probably login to their Facebook, Google, Instagram and bank accounts. If someone hacks your database and the passwords are not sufficiently secured (and personally I think anything less than a strong hash is not sufficient), those hackers can now login to those accounts too. And if those hackers post everything online, everyone can login to those accounts. It doesn't matter what data a password secures, the password in itself is private and VERY SENSITIVE data. In a perfect world it would be some "unhackable" randomly generated string of at least 24 characters, but we're living in a world where 123456 is still the most used password.
It's actually far worse than that... the users don't even get to choose their own passwords. They are assigned by IT (Not a policy I approve of or had any hand in), so the chances of that password being reused elsewhere is very slim, unless this might be the first password they ever use and they then decide to use it everywhere. But honestly, what's the chances. Edit: Forgot to add that surprisingly enough, these password are quite strong passwords with no pattern on how they are created... not 24 char random strings, but at least decent enough to keep most at bay I would say. For example,
Ap@rtmentDataC0nnect10nwas one memorable one I saw (relax...no longer in use ;P ;) )Sander Rossel wrote:
Schedule a call with the user, add boatloads of logging, get only that part what you need from the production database (preferably from a "privileged" individual who has rights to that database).
Did that before too when working with a client where impersonation was not possible. Sometimes the effort and time involved in getting multiple cycles of changes deployed to a production environment just to debug a problem is not realistic or in the client's best interests. BTW, when I say impersonation, I am by no means advocating something like a button allowing ordinary or even support staff to impersonate someone. I mean impersonation by somebody that in any case has full access to the entire production database(s) and code base. Typically the most senior 2 or 3 devs/architects/whatever on the team would be my exception here, and as you say, only when the system does not store sensitive personal information. <
-
This brings up an interesting debate I have had with some management members of a corp I do software development for. If the software belongs to the corp, and the person using it is an employee of said corp, and the software is only used for business related data... is it really an invasion of privacy to 1) know their password? or 2) impersonate their user for debugging purposes? I honestly don't have an opinion on this. I have seen both sides of the argument... a case where the problem ONLY came up for that one single user and couldn't be duplicated in any other way... and a case where somebody maliciously used their ability to impersonate a user to get said user into trouble. I guess as with many things in life, good judgement on need and urgency are better than absolute policy.
By default I'd make impersonate read-only. If impersonate and save/update needs to be done, I'd make some explicit logging of every save made during impersonation mode.
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, weighing all things in the balance of reason? Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful? --Zachris Topelius
-
Sander Rossel wrote:
We won't be hacked and even if we were it wouldn't be a problem since the data is not very important...
So why bother having a username and password in the first place? :doh:
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
Not surprised a bit!
"When the going gets weird, the weird turn pro." - Hunter S. Thompson
-
So two years ago, I created a service for a client, with which their suppliers could connect. It's based on a "standard" (which turned out to be standard-ish) that even pre-dates XML. So anyway, there isn't a GUI that the supplier can use to manage their account. An account is created by the IT department, who creates a username and password and communicates that to the supplier. Communicating passwords is a bit sketchy, but doesn't have to be a problem. Turns out the IT department is using an ascending number (starting at 1) as a password and stores that in an Excel sheet :| Apparently, the only check I have is that a password should be at least 8 characters. I didn't think I needed more than that as we're talking about an IT department here. They simply tell their suppliers "your password to log in is 00000001." and not a single supplier has complained yet. Now, I just had a discussion about storing those passwords. "It would be nice if we could send the users their password in case they forget." Out of the question because I hash passwords before I store them. "But we're not storing user data and it would be more practical if we knew these passwords... We won't be hacked and even if we were it wouldn't be a problem since the data is not very important..." Why the :elephant: am I even having this discussion in 2021 with a fellow IT professional!? X| Still better than their current system which does not run on HTTPS and actually shows your password on screen X| No one can fix it either because no one knows who made it or where/how it's hosted and it's not even that old yet :laugh: In case you're thinking this must be some small local shop, it's actually a pretty large multinational :sigh:
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
I'm not gonna hint at the sector, but I know of a vendor that sells pretty darn critical software packages, and they get secured by a physical hardware key. Under the hood, it uses decentralized DB shards that connect to a central authentication DB, and only when the entire network is properly meshed, does the hardware key authenticate. And if you don't have enough money for a key, or a certified authentication server, you can just access the DB manually and turn off the security. Yeah. Great design guys. 10/10
-
I worked at a company that had an impersonate button in one of their apps. It had to be a secret as it violated about every privacy law imaginable :laugh: Not as bad as your case as we couldn't see their password, but besides that it's pretty much the same.
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
As a button I think it's a bad idea, but I do have in my code (an include file) a mechanism for me to impersonate any user. I don't see the same things as individual users - and the privilege scheme often means only a few users are affected by a problem. It's the way I avoid telling a user "it's fixed" because I did what I needed to do only to find out it wasn't fixed in their view. Note that this only affects our internal (non-public-facing) website/applications. Not their email or anything like that. With myself, and so many others, working remote and the company personnel in more than one location, this is really pretty essential a feature. Available only to those with admin access to server files and only if they know where to look. Considering I could modify data in the tables, anyway, there's no particular reason for anyone to get upset (if they knew).
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein
"If you are searching for perfection in others, then you seek disappointment. If you seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010
