Is there a function that will capture a password on login?
Do you mean from your own FileMaker solution, or from a random website or something?
From own system. On login I capture user name and privilege set and a few other things that are logged in a record. I was just thinking that at times users forget a password and it would be interesting to be able to provide it to them, rather than resetting the password.
No way. Passwords can't be read and that's good so. Resetting a password in case of troubles is common - and save..
If you have studied methods used elsewhere, there is no "retrieval" of passwords, but rather a reset and the new password sent. Along with the warning to change the new password immediately upon login, this is a standard way to provide this type of
I can imagine a way to capture the password at the time that the user logs in, but it would require making the solution very vulnerable to hacking. I think that's what was requested here and it is possible, but not a good idea.
philmodjunk wrote: not a good idea.
not a good idea.
That's the understatement of the year.
Storing passwords as data opens it up to any and all access to the data that people can make happen.
Not too long ago someone offered a custom login 'module' for sale here. Took about 5 seconds to open it up and see the master pw because it was logged in exactly that kind of log table. The account that got me there didn't allow full access to the solution but seeing that piece of data I was able to use it to get higher access. These kind of 'attacks' are usually multiple steps so just don't give the data necessary to take the next step. Just don't do it. It's security suicide.
If user's can't remember their pw, just have them reset it.
Some users won't take that for an answer. Trust me. I was just curious. You have no idea the grief I got because somebody forgot a "cherished" password. It was just a thought I had.
BTW, nobody but ME can actually see the log table that I use in my databases.
mrosenhek wrote: Some users won't take that for an answer.
Some users won't take that for an answer.
Totally irrelevant. Security is up not up to the convenience choice of the user. And that is the main confliction point right there. Convenience does get in the way of security. But the emphasis should be on security, not convenience.
You can't have both. So pick one.
mrosenhek wrote: BTW, nobody but ME can actually see the log table that I use in my databases.
That's what the last guy said. Good luck with that.
The way I look at it, the only person that can actually see my log other than me, is the same person that can crack any security in the first place. But thanks for your concern. I do appreciate it.
I should let you speak to one of my clients. Too large a company to fight with and I just want to keep them happy. They are a large part of my income. There is a new contact for me there now that seems to be on the same page as me so this is really a mute point. Just something of interest. There is no function I see or can think of to create that would capture a password and it's not that big a concern for me to pursue it further to tell you the truth.
I'm aborting this mission; it was more of interest than anything else.
BUT, I would be very interested in hearing what you have in mind of how to do this.
I think this thing has gone overboard. I entirely understand the logic behind FM passwords and security. I was not asking if it was a great idea; just if it is possible. As it turns out apparently it is.
This is not the point of my question. And I am aware of password cracking services. I was merely asking if anybody knew a way to capture a password on login.
It may not be a terrific idea for a variety of reasons, but nonetheless it is apparently possible.
mrosenhek wrote: The way I look at it, the only person that can actually see my log other than me,
The way I look at it, the only person that can actually see my log other than me,
I can only hope that is true in your case. In most cases we have found that to not be true.
Trust me, it is true. My question was mostly out of clinical interest, if you will. I won't be doing this in then ear future but I'd like to know how to do it. Be interesting.
Just a couple of thoughts. If you built your own login function, having the db automatically open, you could then use that to capture the user name and password and store it. So yes, I think it can be done, sort of. Capture the FMP password, I wouldn't bother, but you could build a secondary interface for that purpose. If the user is on a Mac and has enabled keychain password saving, the FMP password is in their keychain, available for viewing with the Mac account password. I suspect there is something similar on the Windows side.
I'm siding with everyone else on the point, however, don't do it. Just because it can be done, doesn't mean it should be.
P.S. As to resetting a user password, we always reset to 'password' or something similar and force the user to reset their password the next time they log in. While I know some businesses that require their users to divulge their passwords, we've always had a policy of don't tell us, we don't want to know.
Ya, I hear ya. Thanks. Currently I do capture user name and priv set and do a few more things upon login. A record is then created.
I'd be curious how to capture a password but it's not something I NEED to do.
You have clients that can't remember their password and they want to you to retain a copy? Fine. Do that. It can be part of the service or it can be an extra that you charge for.
If you do decide to provide password management services to your clients you should store their passwords safely. There is dedicated software for that job. Do not store the passwords anywhere within the files that are protected by it. That is the equivalent of putting your house keys under the door mat. ( Which is why everyone here has been so critical of it ).
I cannot keep their passwords. No point, since they can change them whenever they want.
As I have been telling ppl; it was more of a rhetoric question out of interest.
As simple yes or no would have done.
Techt has described how it might be done. And as I said, it makes the file vulnerable as you have to grant access before you can validate them.
Ya, it makes sense to me. I think I can do this, but won't. Just interesting. The granting access part before is a bit scary.
This capture password business can be part of an underlying phishing exploit to steal credentials. In the old XML/XSLT Custom Web Publishing we also had a similar issue.
In the desktop client we need to exercise care. Which is real, which is not?
Don't be trying this as many people have recommended be avoided.
And as for the table with the log-ins, unless that table is completely shut down by all subordinate Privilege Sets, if it's in the file, chances are better that 95% we can make it appear on the screen or otherwise become available for data exfiltration. FileMaker® Pro 16 has many more protections—some of those long-waged efforts I mentioned in another thread—but developers must invoke them all.
Steven H. Blackwell
Platinum Member Emeritus, FileMaker Business Alliance
In this case the table is actually not accessible to the users or even anybody with full access, except for me. But I won't be putting this in to any production file. It was more of a rhetorical question, maybe rhetorical is not the correct word, more like out of curiosity. What made me wonder is because I have a client that is or was wanting this. I do not think I would ever use this ability.
Just to clarify for other readers, because I think I understand what you are trying to say:
1. Any [Full Access] user will absolutely have access to that table.
2. To reiterate what Wim and Steven said, it is very easy to have missed a setting that will allow more access to that table than you anticipated. I have personally tested dozens of these types of setups, and have only run into 1 that I could not elevate my privileges and get access to user passwords.
3. If you are using a script to prevent access to the table, that's even worse. You can NOT guarantee that a script runs or even finishes.
mrosenhek wrote: In this case the table is actually not accessible to the users or even anybody with full access, except for me.
In this case the table is actually not accessible to the users or even anybody with full access, except for me.
Nobody else has full access but me. I am the only one to have access to that table. Sorry if I confused the issue.
I realise that you are asking us all to calm down but your responses are intriguing. If someone else had full access to the file how would they not have access to the log table?
The log table has a different set of accounts.
The log table is not linked via TO or script.
Perhaps the log table is populated via a third party app, such as a web service?
I think I have confused the issue by not explaining myself correctly.
I am the only one with full access so there is no way anybody could actually access the log table or any layout associated with that table.
What I meant by previously writing that "even if they have full access", was incorrect. I did not mean it the way I wrote it. What I meant was that access to the log table has nothing to do with access privileges and is only connected to MY login. Of course if anybody else did have full access, they could ultimately do whatever they want, though I can think of ways to make it difficult ( not impossible but a nuisance) for them to see the data contained therein.
At the end of the day, it's really a mute point now as I have no intentions of actually implementing anything like this. I was just curious. Im sorry I asked ... lol. On the other hand, my question did stimulate a lot of dialog! So I'm good for something after all
"What I meant was that access to the log table has nothing to do with access privileges and is only connected to MY login."
This just further clouds already rather murky waters. If the log table has nothing to do with access privileges, then there is a rather high probability that its information can be exposed, presuming this is a FileMaker Pro table. I haven't seen it, so I do not know for sure. But the entire purpose of access privileges is to govern rights to create, edit, delete, observe, and take actions upon data in a table and take actions upon the business logic found in the file. Removing the log table from any connection with those rights would not seem at first blush to be a recommended method for securing the data in it.
In times past in this venue apparently some folks were of a similar opinion about accessibility. I believe Mr. Ormond became $200 the richer as a result of a bounty paid as a result of that incorrect assumption.
Oh God .... English IS my first language but obviously I do not have the best skills in written communication. I cloud the waters.
Never mind what I previously wrote, here is the situation.
I am the only one with full access to the DB
Gaining access to this table/related scripts and layouts is only available to me. There is no way anybody else's can (unless of course I created another fu access account for another person.
At login, a record of the login is created, who logged in, when and what their privilege set is and a few other bits of info. But nobody but me could possibly navigate there.
I will not implement any method to capture a password as the reality is, I do not really need to.
Because I have a multi-file solution, I have to script the process of changing user passwords.
I do not record the new password, but that could easily be done...
Unless you use External Authentication, then the account management can be done from one place and automatically applies to all your files... it's what it is there for.
Please note Wim's comment. Federated Identity Management is the coming wave for Identity and Access Management. The FileMaker Platform will want to take full advantage of it.
Retrieving data ...