7 Replies Latest reply on Sep 29, 2014 1:28 PM by jormond

    Storing SMTP passwords


      If I were inclined to allow users to store their SMTP credentials in the database so that SMTP credentials could be specified based on user, can I store account passwords so that no user/admin could see the password?


      If not, assume for a moment that admin's access to user passwords is not an issue. Are there any further concerns about storing passwords? I'm scouring the web for info, and I appreciate any knowledge you can share with me on this issue.


      On a side note-when I clicked the specify button for 'password' in SMTP options, I was surprised that no calculations I specified 'stuck.' After clicking the 'OK' button, the password was still empty. I had to copy/paste the calculation into the password field. I'm actually not sure if that's the sign of a potential problem (like perhaps you can't specify passwords?).



        • 1. Re: Storing SMTP passwords

          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.





          • 2. Re: Storing SMTP passwords
            Mike Duncan

            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.




            1 of 1 people found this helpful
            • 3. Re: Storing SMTP passwords

              Thanks Mike.


              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!.

              • 4. Re: Storing SMTP passwords

                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.

                • 5. Re: Storing SMTP passwords

                  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.

                  1 of 1 people found this helpful
                  • 6. Re: Storing SMTP passwords

                    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).

                    • 7. Re: Storing SMTP passwords

                      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.