2 of 2 people found this helpful
Illegality <> liability
What you appear to describe is a potential legal liability issue, not something that is against the law.
Whether something is or is not legal. Whether you might or might not be liable for your actions are not only two different things, but legal issues that will also depend on where you are located as local laws and precedents will vary.
There are a lot of us that are developers and not administrators. This is a line that exists in the real world but not clear in your words of warning. Most of us have a release of liability in our work contracts that basically states "when you start using it, it's your responsibility".
While I'm not disagreeing in principle that you should try to enforce strict policy for security and encourage your clients to do the same; you are exaggerating a fairly large point here, which is implying that administration of database security is the same thing as password sharing.
So yes, if you maliciously develop something to harvest usernames and passwords out of a system and email them to yourself via a backdoor, then you may be prosecuted for it. But if you're developing a solution that just manages security, then it's unlikely that the term CFAA will ever come across your desk.
In addition to philmodjunk's words, this is not a given. The developer only could know the new password if he stores it in some way after the scripted setting of the password. This is an explicit action. Since the action is happening on a different machine for user, if the developer is not storing the value, except temporarily during the script execution, the developer does NOT have a way to know what the password it.
The is an action that happens everywhere. Including in FileMaker's software itself, on Google's services, Amazon, Apple, etc. The venue and UX may vary slightly, but the overall process is similar. It is the goal of most developers to protect that information. That does not imply that the practice is inherently wrong.
2 of 2 people found this helpful
On 2 separate posts (thank you for not hijacking the original OP's thread) you have stated that a developer can obtain a password when scripting and the truth is, of course they can - if they are an unscrupulous developer. In the same way a developer could change data, they could delete all data, export data, sell data, in fact they can do anything with that database and pretend to be whoever they want to be and leave an audit trail incriminating whoever they choose. Of course, this is illegal.
However, from a procedural point of view, automating manual processes within a system using tools provided by the software in a responsible manner is not illegal or irresponsible and implies nothing.
What about using a script to first get the user's preferred new password and then change it via a script in multiple databases? This implies the developer is now able to know the user's new password and could pass it along to others.
In fact, if well written and well documented, it could prove the opposite of any implication.
Be careful with 'the sky is falling' type of threads like this. It's usually more harmful than anything else.
I'm all for security. You have seen me fight for strong security principles all over the forums and social media. But as mikebeargie said, there is a vast different between password sharing and database administration.
CICT also put it nicely. We are talking about internal, software procedure. With this level of paranoia, you almost become harmful to your own cause.
I remember once, a gentleman came into the bank I worked at. He wanted to reorder checks for his account. As part of the security verification, I asked him for the last 4 of his social security number. He wouldn't say it out loud. Which is in itself not that uncommon. So he wrote it on a piece of paper. Then once entered, he insisted I shred it, so he could see it shredded. Also, not an uncommon request. I complied with both.
Next, I asked him for the account number he wanted the checks reordered for. He would neither say the account number, nor write it down. He was afraid that someone would try to steal the money from his account if they got a hold of the account number. If you are following along, you are already laughing. I reminded him, in a gentle and reassuring way, that his money was safe. No one could remove funds from his account without his expressed approval. And since the account number is already on the checks, there was no harm in others accidentally overhearing the number. He looked at me with complete horror. The circus that followed, I can't describe in words. In no particular order, this is what the man did next:
- Demanded he get checks without his account number, address, and name printed on the check.
- Stormed into the Branch Manager's office, and demanded that I be fired for not complying with his demands.
- Called the police. Insisting that we were exposing his money to undue risk.
- Pointed and screamed at me, and told the police that I was the man that "perpetrated the crime".
- Wrote a letter to the bank's president, detailing the complete disregard for security that happens in our branch.
- Came in every day for the next 2+ years to verify his account balance, and all transactions that had gone through.
All because he misunderstood the intent and application of security measures in place.
Take from that story what you will.
The safest way to have no data breaches is, of course, to have NO DATA.
If your clients pay for the convenience of allowing password changes to be scripted, then they also take the responsibility for the developer to add the feature. Otherwise someone with Full access must manually make that change (even with EA - external authentication), & that person (developer or someone at clients') is also responsible.
Every care must be taken to do the most one can. There is still a responsible human making the decision to use whatever method.
The weakest link is between the keyboard and the chair...
My point to developers is simple: if you use a script to set a user's prefered password, then you can be considered as one who knows that password. A scripter could add lines to the script (this is just theorey) to missuse that knowledge and then delete those lines to hide the deed. Suppose that this knowledge was used to harm someone or a corporation? A lawyer could make a case of this being possible, etc. I remember receiving $.50 cents from the group of lawyers who sued Apple for the description of computer monitors as being 15" (they received $millions).
Since a developer only need give a new user a tempororary password or one to a user who forgot, then check the box for requiring the user to select a new password, there is no need for a developer to ever know directly nor through a $$variable the user's password. The user can copy and paste their preferred password so there is no need to waste time doing this for them.
This is more of a logical opinion than a legal one since I am not a lawyer
Everyone can develop as they wish, of course. We've seen how advising someone that rolling your own password rather than using FileMaker's is not a good idea yet people still do it after being told.
1 of 2 people found this helpful
I think you're flogging a dead horse here.
Follow the url's and read the articles that show that password sharing is against the law (in the US at least).
There are very valid reasons for this even though many people disagree, just like the drug addicts who want their drugs legalised.
Please...someone share with me the password for writing checks so I can write myself a big one...
And you are right. I did point out a potential legal liability issue.
Passwords should be private and not shared and the developer should never know what they are. I have a login program that tracks users and I found a former administrator was logging in using the owner and manager's passwords. I had them change their passwords, blacklisted his login ip address and acccount, etc.
Also, the election showed how the DNC and the Democrat committees were sharing passwords. I'm sure Republicans also did this. Results weren't too good...
1 of 1 people found this helpful
While on the subject, an interesting article from the UK Daily Telegraph today:
Why do you label my posts as 'the sky is falling'? Can you not post an opposing view without such an insult?
I enjoyed your story. Reminds me of all the folks decades ago who were rightly concerned about privacy, etc. and who know are part of Big Data where every scrap of information entered on the internet is part of their file. Amazing how much unidentified information falls into place when a phone number or address is entered.
This poor guy would go nuts if he learned that his private information was being maintained in a text file sql database that was recently hacked and is now available to thousands of hackers...
It's safer to flog a dead horse than a live one...