Gmail - Configuration could not be verified706
Pages:
1
|
LiquidLayer private msg quote post Address this user | |
| Are you attempting to use IMAP access with your favorite email client such as Thunderbird, MailBird, Outlook and other email clients and you receive.. "Configuration could not be verified - Is the username or password wrong?" Along with you confirming that you have the correct password such as logging in under your webmail account? Here is the solution / you need to enable your gmail account to use "less secure apps" Once logged into your gmail account go here: https://www.google.com/settings/security/lesssecureapps Due to recent changes with gmail, also confirm you have select to use less secure apps. see info here: https://support.google.com/accounts/answer/6010255?hl=en  ___________________________________________________________ Liquid Layer Networks | Performance Cloud Web Hosting http://www.LiquidLayer.net ParagonHost Networks | Web Hosting since 2000 http://www.ParagonHost.net |
||
| Post 1 • IP flag post | ||
|
|
LiquidLayer private msg quote post Address this user | |
| Allowing less secure apps to access your account Google may block sign in attempts from some apps or devices that do not use modern security standards. Since these apps and devices are easier to break into, blocking them helps keep your account safer. Some examples of apps that do not support the latest security standards include: The Mail app on your iPhone or iPad with iOS 6 or below The Mail app on your Windows phone preceding the 8.1 release Some Desktop mail clients like Microsoft Outlook and Mozilla Thunderbird Access your account To help keep your account secure, we may block these less secure apps from accessing your account, and you’ll see a “Password incorrect” error when trying to sign in. If this is the case, you have two options: Upgrade to a more secure app that uses the most up to date security measures. All Google products, like Gmail, use the latest security measures. Go to Allow less secure apps and choose “Allow” to let less secure apps access your Google account. We don't recommend this option because it may make it easier for someone to gain access to your account. https://support.google.com/accounts/answer/6010255?hl=en |
||
| Post 2 • IP flag post | ||
|
|
LiquidLayer private msg quote post Address this user | |
| https://developers.google.com/gmail/oauth_overview Protocol IMAP and SMTP use the standard Simple Authentication and Security Layer (SASL), via the native IMAP AUTHENTICATE and SMTP AUTH commands, to authenticate users. The SASL XOAUTH2 mechanism enables clients to provide OAuth 2.0 credentials for authentication. The SASL XOAUTH2 protocol documentation describes the SASL XOAUTH2 mechanism in great detail, and libraries and samples which have implemented the protocol are available. Incoming connections to the IMAP server at imap.gmail.com:993 require SSL. The outgoing SMTP server, smtp.gmail.com, requires TLS. Use port 465, or port 587 if your client begins with plain text before issuing the STARTTLS command. _________________________________________________________ Liquid Layer Networks | Performance Cloud Web Hosting http://www.LiquidLayer.net ParagonHost Networks | Web Hosting since 2000 http://www.ParagonHost.net |
||
| Post 3 • IP flag post | ||
|
|
LiquidLayer private msg quote post Address this user | |
| http://security.stackexchange.com/questions/66025/what-are-the-dangers-of-allowing-less-secure-apps-to-access-my-google-account What are the dangers of allowing “less secure apps” to access my Google account? One reply to the above states: In my understanding, "less secure apps" refers to applications that send your credentials directly to Gmail. Lots of things can go wrong when you give your credentials to third party to give to the authentication authority: the third party might keep the credentials in storage without telling you, they might use your credentials for purposes outside the stated scope of the application, they might send your credentials over a network without encryption, etc. "Less secure" isn't meant to say that apps that use your credentials are necessarily full of security holes or run by criminals. Rather, it is the category of behavior -- giving your credentials to a third party -- that is fundamentally less secure than using an authorization mechanism like OAuth. With authorization, you never allow the third party to see your credentials, so an entire category of problems are instantly eliminated. In OAuth, you authenticate directly to Gmail with your credentials and authorize an app to do certain things. The third-party app only sees an authorization token provided by Google as proof that you authenticated correctly and agreed to authorize that app. As for why it would be dangerous to enable less secure apps (versus using a particular app that may be untrustworthy), I'm not totally sure. Google's refusal to authenticate happens after you've already given away your credentials to the application. It seems to me that any time you provide your credentials to a third party, it doesn't matter whether or not you've allowed authentication by "less secure apps" -- someone can just load up a log-in screen and directly log in as you. The only possible cases I can think of are: Possibly "app-based" login attempts are treated differently from "human-based" login attempts, in particular how they treat sudden changes in location. Maybe the "less secure" app you're trying to use has severs on another continent, so it's not suspicious to Gmail when an app tries to log in as you somewhere else, while an attempt to use the log in screen from another continent by a human would be suspicious. Possibly "less secure" auth methods include some other login method that doesn't directly reveal your credentials to the third-party but are less secure than OAuth 2.0 in some other way (i.e., they're vulnerable to eavesdropping by an attacker, or they make it somehow easier for an attacker to access to your account without knowing your password). Those two points are pure conjecture and very well may not be true in actual fact. ____________________________________________________________ Liquid Layer Networks | Performance Cloud Web Hosting http://www.LiquidLayer.net ParagonHost Networks | Web Hosting since 2000 http://www.ParagonHost.net |
||
| Post 4 • IP flag post | ||
Pages:
1
