First, storing passwords in a database is just generally a bad idea. It exposes the password to hacking.
Second, no, there's no way you can prevent an admin from seeing the password if you store it in clear text. You could potentially hash it (using some combination of MD5 and seed strings). This would reduce the risk, but not against an admin necessarily, because the admin would have access to the algorithm you use (since he could see the scripting). A clever admin could then reverse engineer your hash algorithm to recover the password.
Third, as to the question of a calculation in the SMTP password field, I don't believe you can put a calculation there. I'm not near a computer at the moment (working from a mobile device), so I can't verify, but I believe that just has to be a text string. I could be wrong, though; someone else please correct me if I am.
1 of 1 people found this helpful
As an option to each individual storing their SMTP passwords in the database, you might set up a dedicated SMTP account to relay email for all users, where they can still send the email so it appears to come from their email address. That way you don't need to store everyone's credentials and it is much lower security risk with just the one account.
You could also use a thrid party service like mandrill to send an email via their SMTP servers or using their web api. This can be eaiser than maintaining your own SMTP server just to send these as well.
I was afraid that was the case, but I haven't turned up any ideal options in my searching. By 'exposing the password to hacking,' do you mean users/admins trying to find out other users passwords within the filemaker's rules for accounts, or do you mean that I should be worried about external hackers gaining access to the database or traffic to the server? I had sort of planned on simply following Filemaker's recommendations with regard to security and just letting Filemaker server 'do its thing.'
I confess I'm a bit clueless when it comes to security and communications. My users/potential users are very small businesses that may rely on web mail accounts for employees. This is why I was looking for a system where a user loggging in automatically calibrates there email settings.
Incidentally a calc in the SMTP password field did work for me (a simple global variable), however I had to paste into the password field. As I mentioned, clicking the specify button opens the calc window, but the calcs don't actually 'stick.'
Thanks for taking the time to reply!.
So is the basic idea here is that user password (for gmail for instance) would still be stored, but on Mandrill's servers and not in the database? The second option you listed was a third party service. Am I to understand by the first option that you are referring to the user running their own server?
Thanks Mike. I'm really trying to get up to speed on the 'network' side of things.
1 of 1 people found this helpful
You should never store the password in the database. There are several ways it could pass to an unauthorized party:
1) An admin could get it, as you point out.
2) Traffic to the server CAN be sniffed if you don’t turn on SSL encryption.
3) It is theoretically possible (although unlikely) to use a man-in-the-middle attack to intercept the SSL certificate and then sniff the network traffic if you don’t use a signed certificate in place of the default self-signed certificate FileMaker provides with Server. (Again, this is unlikely, but theoretically possible.)
4) An individual who has access to the physical file could possibly gain access to the stored data via one of several hacking tools out there if the database doesn’t use encryption at rest (EAR). This means your server admins or anyone else who has access to the directories where the file lives (including backups).
IOW … don’t do it.
Thanks again Mike, very helpful info. Are points 2 and 3 less applicable to a scenario where the password is not stored, but rather entered each sessions (since it doesn't have to re-entered each time after that)? (I do have SSL enabled)
I don't want to take up too much of your time, so no worries if you don't want to delve any further into this topic. I will definitely be pushing my users to use an email client or a third party service like Mandrill (thanks to Mr. Duncan for that suggestion).
Some email services allow you to access their API. In which you could authorized access to send, or receive, via a security token or key instead of the actual password.