We are currently working on a mobile application which is currently in beta version and plan to get it released to App Store very soon and this primarily supports only iOS mobile devices
Recently one of the external users had frantically typed a wrong password repeatedly in login screen which further exceeded the limit, resulting in an internal server error and finally locked the user out of the app
The default error messages come from AWS Cognito and the user is required to fill in the phone number and password to log in to the app
How many times will AWS Cognito allow the user to punch in incorrect passwords. Is there a limit to it
Is there any documentation which clearly explains my problem
Is there a way to let the user know at the first instance say., that there are only 5 attempts to try
Any help is much appreciated
According to AWS Cognito docs,there are no limits on login attempts, however they do secure login endpoint with request rate limiting and exponential timeouts:
We allow five failed sign-in attempts. After that we start temporary lockouts with exponentially increasing times starting at 1 second and doubling after each failed attempt up to about 15 minutes. Attempts during a temporary lockout period are ignored. After the temporary lockout period, if the next attempt fails, a new temporary lockout starts with twice the duration as the last. Waiting about 15 minutes without any attempts will also reset the temporary lockout. Please note that this behavior is subject to change.
https://docs.aws.amazon.com/cognito/latest/developerguide/amazon-cognito-user-pools-authentication-flow.html
Related
Error Domain=FIRAuthErrorDomain Code=17010 "Access to this account has
been temporarily disabled due to many failed login attempts. You can
immediately restore it by resetting your password or you can try again
later." UserInfo={NSLocalizedDescription=Access to this account has
been temporarily disabled due to many failed login attempts. You can
immediately restore it by resetting your password or you can try again
later., FIRAuthErrorUserInfoNameKey=ERROR_TOO_MANY_REQUESTS}
I received this Firebase Auth iOS SDK error, as expected, after repeatedly trying to sign into an account with invalid credentials (for testing) but was unexpectedly able to sign into that account immediately thereafter using valid credentials. Why wasn't the warning in this error enforced? Or was the penalty just a few seconds? There is no documentation on this.
Based on this issue found here https://github.com/firebase/quickstart-js/issues/54 it seems that Firebase is a little vulnerable to brute force attacks only blocking successive attempts for a few seconds at a time. Firebase also does not have this currently publicly documented.
I've had this error, but as I have observed firebase allow up to 6 attempts before giving you the error "too many requests" that would disable the account temporarily which I am pretty sure cannot last over a minute (or a minute and a half) before being able to sign in again. I think further invalid login attempts after the previous 6 attempts adds few seconds to the penalty. Best thing to do is after 6 attempts wait for about 1 1/2 minute and try to sign in again.
Account linking problem for only some of our users, most users link account normally. For users linking account failed, they just see the login page refreshed to empty account name and password.
From our server log, we found for users that fail to link, the user accesses our server successfully and got OAUTH code, but after about 15 seconds, google server accessed our server to exchange the code for a token. However, the code has expired by this time.
For successfully linked users, the time between issuing the code and exchanging it for a token is about 2 seconds.
Does anybody know how to resolve the problem? Thanks.
It sounds like the expiration time for the authorization code has been set to about 10-15 seconds. While the auth code should have a short lifetime, 10 seconds is way too short. The recommended lifetime should be no more than 10 minutes, not 10 seconds.
Consider that this code needs to be sent back from your server to the user, from the user to Google, and then from Google to your server. On some networks, each step might take more than a couple of seconds, particularly since it must be done over HTTPS this adds both network and processing overhead. Each step adds just a few fractions of a second - but they can add up on some devices!
There could also be a slight clock skew between the issuing server and the processing server - likely not much, but when you have a lifetime of a just a few seconds, even a 1 second skew could be too much. If the two are very out of skew, then this could be the cause of your problem as well. Make sure the clocks on your servers are at least reasonably in sync.
The best solution would be to increase this timeout on your server when you generate or accept the code. You may have thought you were specifying 10 minutes for a configuration field that actually accepts seconds.
For some reason an account which I've registered using my app and tested before is now giving me an error when trying to log in using its details: "Logins don't match. Please include at least one valid login for this identity or identity pool."
I know the values I am using for it are definitely correct and other accounts are still able to login. What could be the cause of this error?
Any help would be greatly appreciated.
What the SDK is trying to tell you is that the identityId in your Federated Identity Pool (and which may be stored in a keychain in your device, and which may be re-established on restart from an existing session) does not match the login in your authentication provider which was returned by the "logins" method.
This can happen in a number of different ways, but this usually occurs because you attempt to log in as another user on the same authentication provider without first logging out.
The SDK recovers by retrying.
(This recovery does not really work because I think it takes 2 or 3 attempts to time out, and the recovery then leaves you in a state where subsequent logins fail with the same error. Restarting the app clears this. I have not fully investigated the defect in the retry/recovery process)
The solution is to prevent the app from logging in on a different ID with the same authentication provider (IdP) without first logging out of that authentication provider.
A significant number of users are getting the error message of 'GetAccessToken - Unauthorized error: Your network is not allowed to request an OAuth token for this Application' whilst trying to log in to our application.
I have checked and tested, and they are accessing the correct network with the right credentials. This is happening to almost every person, so I don't believe this to be a coincidence.
This has only begun to happen in the past 24-36 hours. Are there any suggestions as to why this error is occurring, has something changed that I may have missed?
Thanks!
Couple of possible scenarios:
It is likely that the new simplified SSO is rolling out for these
users, which means they will use their O365 credentials to login to
Yammer from now on. Every user will need to reauth external apps (I
had to for our own apps also when this change occurred for us last
week).
Tokens also can expire when user's passwords expire, so if
they have a mandatory time interval to reset this could trigger an en masse need to reauth
Make sure your JS Origins are specified in your app details if you are using the Login with Yammer button and/or the JS SDK. http://naomimoneypenny.com/2015/02/11/yammer-apps-javascript-origins-update/
There isn't clear and definitive guidance regrettably from Yammer as to why and when tokens expire. Just that they do e.g. from https://developer.yammer.com/v1.0/docs/oauth-2
Once the token expires, you will need to re-run the steps above to generate a new code and access_token.
We are getting internal_failure error message while exchanging code to get refresh token. This error doesn't occur all the time for all the accounts. This happens only while authenticating with a few Google accounts and that too like 5 to 6 failures for every 10 authentication requests no matter what the client_id is. We have a test account and is reproducible too frequently in this account as well.
{
"error" : "internal_failure"
}
How often are you making these requests? You are probably running into the per account quota limits.
In real life, any account would not be doing a lot of code to refresh token conversion. The expectation is that you do that just once per application.
So, if you have test/monitoring accounts, they will run into these issues. The best is for you to monitor and test only your site/code.
internal_failure is an authentication server outage. which can be tracked on
Cloud Status or apparently also APP Status although I am not seeing it there it may only be GSuite issues are there.
There is nothing that you can do but wait for the server to return.