360Works Email 2.17, a "less secure app" for GMail?

[Eric Matthews]

I'm just now trying the demo of the plugin.

I could not Connect IMAP to Gmail: "An error occurred: [ALERT] Please log in via your web browser: https://support.google.com/mail/accounts/answer/78754 (Failure)"

It seems that Gmail classifies the plugin as a "less secure app"
https://support.google.com/accounts/answer/6010255
because it only works when I "Allow less secure apps: ON"

How can we get 360Works Email 2.17 classified as a "more secure app" so that we can buy and install the Enterprise License for our organization?

 

 

 

 

"

Edited April 7, 2016 by Eric Matthews

[Eric Matthews]

Google answers the following:

Quote

 

What criteria is used to identify an application as being “less secure”?

Applications that rely on plain username/password authentication to access an account programmatically are considered less secure than those using modern day security standards such as OAuth 2.0.

https://support.google.com/a/answer/6260879?hl=en

 

 

Edited April 7, 2016 by Eric Matthews

[Josh Ormond]

Note that FileMaker Pro's built in email functions also fall into the 'less secure' category. Because of the authentication technology they are currently using.

[Eric Matthews]

22 minutes ago, Josh Ormond said:

Note that FileMaker Pro's built in email functions also fall into the 'less secure' category. Because of the authentication technology they are currently using.

Perhaps categorically, but FileMaker Pro's built in email functions to GMail work without producing that error or requiring us to "Allow less secure apps: ON".

[Josh Ormond]

Really? I've never gotten FileMaker's email to work without turning that on. Unless you are just using Open URL and have mailto: set use Gmail.

[Eric Matthews]

43 minutes ago, Josh Ormond said:

...I've never gotten FileMaker's email to work without turning that on. Unless you are just using Open URL and have mailto: set use Gmail.

I just learned something after trying to send just now. Apparently, we have been using a system SMTP account on GMail to send for so long that I forgot; and I can't see how it is set. Considering that account works and a recent test of my account doesn't, you are probably correct.
Now I have to pester both 360Works AND FMI.
I don't suppose anyone gets that Cram-MD5 Authentication to work with GMail?
 

Edited April 7, 2016 by Eric Matthews

[Eric Matthews]

On GMail:
Does allowing "less secure apps" incur a risk while using 360Works EMail plugin?

Does simply allowing "less secure apps" incur a risk of the account being hacked?

Edited April 8, 2016 by Eric Matthews

[Caleb360Works]

The advantage of OAuth2 vs "less secure" is you don't expose your password. If someone gains access to your database they can only access the stored OAuth2 tokens which can be revoked easily.

Google defines it as a "less secure app" because the password has to be stored as plaintext (or some sort of encryption) in the client utilizing the credentials. For some applications this can be a risk because they will store your credentials in plaintext.

Our 360Works Email Plugin does not store your credentials - your credentials will be stored however you decide to set it up within your FileMaker database. If your database is compromised, your credentials could be exposed. However, this would also be the case with OAuth2 except that you can revoke the OAuth2 token without having to change your password.

In short, the security implication here rests on the database designer and the methods you choose to keep the credentials secure. I personally use random passwords as my password in Google and store it in LastPass. That way if my credentials get exposed, I merely have to change my password to another random one and I don't risk any other credentials for other software.

 

Disclaimer: This does not take into account connection methods. With both routes be sure to only utilize TLS or SSL connections to the mailservers so you don't expose your credentials to man-in-the-middle attacks.

Edit: Microsoft Outlook 2016 (and earlier versions) doesn't support Google's OAuth2 implementation, if this tells you anything. Another thing to mention is if you use two-factor authentication Google allows you to generate app-specific passwords so you expose that password instead of exposing your Google password. For reference: https://productforums.google.com/forum/#!topic/gmail/RdAVxF_GTsc;context-place=topicsearchin/gmail/Billow

[Eric Matthews]

1 hour ago, Caleb360Works said:

...Google defines it as a "less secure app" because the password has to be stored as plaintext (or some sort of encryption) in the client utilizing the credentials. For some applications this can be a risk because they will store your credentials in plaintext. However, in the case of the 360Works Email Plugin it does not store your credentials - your credentials will be stored however you decide to set it up within your FileMaker database. If your database is compromised, your credentials could be exposed. However, this would also be the case with OAuth2 except that you can revoke the credentials without having to change your password. In short, the security implication here rests on the database designer and the methods you choose to keep the credentials secure. I personally use random passwords as my password in Google and store it in LastPass. That way if my credentials get exposed, I merely have to change my password to another random one and I don't risk any other credentials for other software. Disclaimer: This does not take into account connection methods. With both routes be sure to only utilize TLS or SSL connections to the mailservers so you don't expose your credentials to man-in-the-middle attacks.

This information is very helpful. Thank you. This and the e-mail I received to the same inquiry certainly testify to 360Works' depth of knowledge and ability to support.

Now, I'm wondering how to most securely implement the plugin on server. I suppose I could have users enter their own passwords into a global field each time they need to connect to IMAP, and empty the global right after they connect. 
What would you think of the risk of keeping a users' password in a global for their entire FileMaker file session?

Edited April 8, 2016 by Eric Matthews

[Caleb360Works]

1 hour ago, Eric Matthews said:

This information is very helpful. Thank you. This and the e-mail I received to the same inquiry certainly testify to 360Works' depth of knowledge and ability to support.

Now, I'm wondering how to most securely implement the plugin on server. I suppose I could have users enter their own passwords into a global field each time they need to connect to IMAP, and empty the global right after they connect. 
What would you think of the risk of keeping a users' password in a global for their entire FileMaker file session?

Considering that field gets blanked when their session ends it seems safe. However, I would be concerned with keyloggers on the user's computers. Having to retype the password saves you from the concerns of storing it in the DB but increases the chance of a middleman on the client computer. However if someone is compromised their email password getting intercepted is the least of their concerns, and not your fault. I actually like the idea of storing it as a session variable. A tad bit easier approach than full blown 2-way encryption.

[Stickybeak]

I am evaluating 360 mail.

I get this message on the inbound imap connection: "An error occurred: [ALERT] Please log in via your web browser: https://support.google.com/mail/accounts/answer/78754 (Failure)"

I have no idea what to do or what the problem is.

Help? Please?

Edited December 23, 2016 by Stickybeak

[Josh Ormond]

Do you use 2-Step Verification? If yes. I think you need to setup an App password. Not sure how that part of it works with multiple users.

[CKonash]

Hello, 

I am also receiving the following error "An error occurred: [ALERT] Please log in via your web browser: https://support.google.com/mail/accounts/answer/78754 (Failure)"

I have confirmed that the 2 step verification is OFF and ALLOW LESS SECURE APPS is ON. 

I had this working perfectly on two hosted databases on a server-side scheduled script.  I had issues with that Host provider and just moved to a new provider and this is where the problem popped up and things do not work as it looks like Goggle is blocking the login attempts.  

Any ideas what I can do to make this work?  

Thanks

Chris K. 

[domiller]

I have had this plugin working beautifully for my personal account (IMAP to Gmail) for a couple of years now.  I had set gmail to allow less secure apps.

Now I have a new, company-based email account from Google, which has 2-step verification turned on.  I followed the instructions to generate an app-specific password, plugged everything in, and get the aforementioned " [ALERT] Please log in via your web browser: https://support.google.com/mail/accounts/answer/78754 (Failure)"  error.

Has anyone recently gotten IMAP from Google working with the email plugin and two-step verification?

This really shouldn't be so hard.

[Josh Ormond]

I have it working using FM's native Send Mail [ ] step.  You made sure you have the spaces in the from the app password included, correct? When you copy/paste, it doesn't pick up the spaces.

[domiller]

1 hour ago, Josh Ormond said:

I have it working using FM's native Send Mail [ ] step.  You made sure you have the spaces in the from the app password included, correct? When you copy/paste, it doesn't pick up the spaces.

I haven't tried sending mail, although it's worth a go.  I'm trying to get an IMAP connection.  I have tried the password with and without spaces (Google describes it as a 16-character password, so I assume the spaces are for humans rather than part of the password).  I still receive the same (unhelpful) error.

[Josh Ormond]

What settings are you using?

Should be:

• Gmail IMAP server address: imap.gmail.com
• Gmail IMAP user name: Your full Gmail address (e.g. "me@gmail.com")

 

• Gmail IMAP password: Your Gmail password ( app passwords require the spaces )
  
  Note: Use an application-specific Gmail password if you have enabled 2-step authentication for Gmail.
• Gmail IMAP port: 993
• Gmail IMAP TLS/SSL required: yes

Important: For the Gmail IMAP settings to work in your email program, IMAP access must be enabled in Gmail on the web.

For outgoing ( SMTP ):

• Gmail SMTP server address: smtp.gmail.com
• Gmail SMTP username: Your Gmail address (e.g. example@gmail.com)
• Gmail SMTP password: Your Gmail password ( app passwords require the spaces )
• Gmail SMTP port (TLS): 587
• Gmail SMTP port (SSL): 465 ( this is the one I used )
• Gmail SMTP TLS/SSL required: yes

[domiller]

That is what I am using.  Just for grins I tried a bad password and get the "Authentication Failed" message, So I *am* putting in valid credentials.  I was using this with a personal account in the past and it worked beautifully.  That's what frustrates me now.

[Josh Ormond]

Try using Send Mail [ ]  and just see if it works. This setup does work. So that can at least narrow down if the problem is the IMAP setup, the company account, or something else.