Sending Mail through SMTP while protecting password

[jjjjp]

Is there a way to store an email password in a database so that it remains encrypted or at least inaccessible to everyone who uses the database? I rely on the SendMail using SMTP for sending multiple emails, and the email account used to be a shared institutional account whose password didn't need to be protected form others with access to the database. But all institutional/shared emails at my University must now go out using the credentials of one of the shared account's owners, meaning that personal passwords will be stored in the database. So I would want to protect that password. An alternative might be for me to script a dialogue that prompts for the password but never saves it. Is that feasible? Storing the password in a protected manner would still be preferable.

[comment]

14 hours ago, jjjjp said:

need to be protected form others with access to the database.

I could not understand from your question who are the "others" here. If each user has (or can have) their own email password, then you can store the password in a table of Users and limit the privileges so that each user can access only their own record, based on Get (AccountName). Thus only a user with full privileges will be able to see  someone else's password.

14 hours ago, jjjjp said:

An alternative might be for me to script a dialogue that prompts for the password but never saves it. Is that feasible?

In version 17 or higher, you can show a custom dialog and have the user input the password into a script variable (using a single $ prefix). Such variable will expire as soon as the script has run out. If you're still on version 16, you can use a global field for this and either clear it at the end of the script or let it linger until the end of the session. Users cannot see other users' global field values.

 

[jjjjp]

I set up the database so that the program opens automatically in an admin account, and the user accounts and login are all managed internally through scripts. In any case, there would be somebody other than me with full privileges with access, so leaving my credentials in the database would be unwise even if the security risk were small.

I just heard from IT at my university this morning that I will be able to keep the old credentials working on our shared account even though for all new shared email accounts "owners" must log in through their personal credentials. The account will, apparently, remain a kind of hybrid of the old shared accounts and the new. So I will probably be OK. But if in the future I lose the ability to log in with the old credentials, I will set up a custom dialog as you suggest. Current version is 19, so no problem with a script variable.

Thanks very much for the response.

[comment]

1 hour ago, jjjjp said:

I set up the database so that the program opens automatically in an admin account,=

I don't think that's a good idea.

1 hour ago, jjjjp said:

there would be somebody other than me with full privileges with access, so leaving my credentials in the database would be unwise even if the security risk were small.

I don't know of a way to store something in a database and make it inaccessible to a user with full-access privileges. In theory, you could encrypt the email password and demand a key to decrypt it; in practice, you would only be exchanging one password for another.

I suggest you re-examine your entire security strategy.

1 hour ago, jjjjp said:

Current version is 19

Please update your profile.

 

Edited August 4, 2022 by comment

[jjjjp]

I understand retrospectively that internally managed user accounts would not be considered good practice. I followed the model used by a much larger project at my university, and I also believe that it would have been a problem to give other users outside of my college access to Filemaker in the early days for reasons I don't entirely remember, but I did make enquiries at the time. Note that all users except me (that is, when I code on my developer copy) and my IT support are immediately switched on login over to a non-full-access account with appropriately limited privileges. There is just no way for users to do anything other than log in before they are switched over to the limited-privilege account. They can't access scripts or tables or anything of the kind. In any event, this is too much of a side project for me to consider changing over the whole architecture. The code base has become large, but the time I have to put into development at this stage is fairly restricted. That said, I appreciate the candour.

No worries about not storing something that my IT person with full access would be able to see. I can go with a dialogue and unstored email passwords if the old email account with a single shared password ceases to be grandfathered in the future.

[comment]

16 minutes ago, jjjjp said:

There is just no way for users to do anything other than log in before they are switched over to the limited-privilege account.

I believe you are very much mistaken about that.