I am using a python script that login to AWS account with an IAM user and MFA (multi-factor authentication) enabled. The script runs continuously and does some operations (IoT, fetching data from devices etc etc).
As mentioned, the account needs an MFA code while starting the script, and it does perfectly. But the problem is script fails after 36 hours because the token expires.
Can we increase the session token expiration time or automate this task not to ask MFA code again and again?
You can't extend the expiration, but you can circumvent the protections (at your own risk). In principle, you can store the MFA secret used to generate TOTP codes (e.g., what QR setup codes provide) and have your script generate OTP codes to perform MFA challenges automatically. For example, using the PyOTP library. Of course, if your MFA requirements require more than TOTP (like enforced biometrics or physical touch keys) then this won't work.
But it would probably be easier to just setup a solution that avoids the need for MFA to begin with. For example, deploy your script to run on an EC2 instance with an instance role with necessary permissions or create an IAM user that does not have MFA requirements.
Unfortunately not, the value can range from 900 seconds (15 minutes) to 129600 seconds (36 hours). If you are using root user credentials, then the range is from 900 seconds (15 minutes) to 3600 seconds (1 hour).
Related
We have used Azure AD-B2C and implemented MFA using custom policy. We have authenticator app as one of the MFA option to login to our application.
We are using Microsoft Authenticator App and it generates the one-time passcode every 30 seconds. However, we are able to login to the application using the old TOTP that's generated before 30 secs.
I have verified checking the validity of the TOTP, but couldn't find any documentation on this. The code generated is sometimes valid up to 3 mins and sometimes up to 5 mins. Is the code not supposed to expire within 30 seconds?
Can you please clarify this, and refer me to any documentation.
As per all the documentation, TOTP generates the one-time passcode every 30 seconds, but nothing is mentioned about its expiry time.
As per TOTP algorithm, we can't control its expiry time and as name mentioned its one-time code which can be used only one time.
So even if you are entering the expired code, it is really not expired. It is just expired in the time slice when the app generated it, but Azure AD B2C will accept it within time tolerance (as per you up to 5 mins sometimes).
As this OTP can be used once, B2C will give you error if you try to use it next time.
One more factor is the code generation is based on system time, and while system time of Azure AD B2C can be synchronized with internet time servers, system time of mobile device can be out of sync for various reasons. Thus, Azure AD (B2C) has a time tolerance of to accept Time Based One Time Passwords during verification.
I haven't been able to find appropriate documentation related to this. But in my experience, the totp verify page (Not registration) allows codes of +/- 90 seconds.
In registration flow, the totp flow accepts code as old as around 24 hours. A common mistake that could happen is reading and writing the secret key while using the new totp flow. If you provide the secretkey value as an input claim to totp verification page, b2c treats it as a registration flow and goes ahead and accepts old codes.
I believe the reason for this to account for time skew in the user's totp device. The time in user's totp device might not be in sync with server time and totp relies on current time to generate the code.
Once you use a code from 2 hours ago for registration and if you try to verify with a new code (current time), the verification will fail. It will expect you to provide a code from 2 hours ago with a tolerance of +/- 90 seconds.
Azure MFA allows TOTP code in the range of 900 seconds (-450 and +450 seconds).
Not documented anywhere, found by experimenting
I'm using Cloud Firestore for Firebase to store informations about a Rest API Service written in NodeJs.
So, every request to Node will ask to Firebase informations about the service and, for first, it will authorize the request.
I thought that use an user generated JWT will be the best solution because the client have to simply include the JWT in his requests to authorize itself.
A Firebase JWT is related to the uid of the user that generates it.
Obviously, there'll be a control panel where the user can log in with email/pw and generate the JWT, and then the JWT will be included in his client system, for example like simple APIs that requires an API Key to identify the user and to work.
So, the idea appears to work good but i noticed that the Firebase JWTs expire in only 1 hour!
The user have to log-in to the control panel every hour to re-generate the JWT. That's not so friendly.
How can avoid this problem? How can i make the JWT expires in more than only 1 hour?
According to documentation:
The maximum lifetime of a token is 24 hours + skew.
[...]
with a skew of up to 10 minutes.
That means you cannot use these tokens forever, which kind of makes sense.
I looked at custom tokens and found:
The time, in seconds since the UNIX epoch, at which the token expires. It can be a maximum of 3600 seconds later than the iat.
Note: this only controls the time when the custom token itself expires. But once you sign a user in using signInWithCustomToken(), they will remain signed in into the device until their session is invalidated or the user signs out.
Perhaps you can do something with the signInWithCustomToken() as once logged in it expires only when the user is invalidated or signs out, but I believe the best course of action would be to look for another approach.
Is there a way to increase the expiration time of OTP codes delivered via email during MFA and password reset? My users are getting the email later than 8 minutes and by the time they use the code, it is expired. What is the actual default? Is there a way to leverage the OTP technical profile described here Define a OTP technical profile in an Azure AD B2C custom policy ?
I believe the default expiration time is dependent on the method you're using to send them to code.
As far as I can tell from the documentation, the most customizable method for sending the OTP is using the OTP protocol provider you linked in your question.
https://learn.microsoft.com/en-us/azure/active-directory-b2c/one-time-password-technical-profile
This protocol provider has a specific metadata item you can set for the expiration time (CodeExpirationInSeconds). It's min is 60, it's max is 1200 and it's default is 600.
If you need more fine grained control over the expiration time of the code, I would use this protocol provider to do it.
I have a long running application (many days/weeks). Is there anyway to get OAuth access that is not tied to the 14 day refresh token expiry? No matter what I try I lose access in 14 days. It would put a huge burden on our users to have to re-authenticate every N days.
Azure AD Refresh tokens have a sliding expiry of 14 days, up to a maximum of 90 days. That is, as long as you use the refresh token in those 14 days, you will get a new refresh token valid for another 14 days. So your users would only need to re-enter credentials every 90 days.
That being said, for long running applications, the Client Credentials Flow may be more suitable. This uses Application Permissions rather than Delegated Permissions (so you may need to change the permissions in the Azure portal). If you really need to make your calls as a particular user it may not work in your case.
In our web application, when a user logs in, if the session is idle for longer than 15 minutes, the user has to enter the login credentials again to continue.
As I do not use other web applications I would like to ask the following questions concerning this matter:
Is such a reauthentication usual in current web applications?
After how many minutes inactivity does it come?
From a security standpoint, is it common and reasonable to only ask for the password (and not the user name again)?
If you fail to reauthenticate (3 times), is it more common to only end the session or lock the whole account?
Thanks alot in advance
Re-Authentication
Re-authentication is the process of making a secondary confirmation of a person’s identity after checking previously. Usually a user has to perform an additional login by force to ensure that a user who is accessing a protected resource is the same person who initially authenticated at the start of the session. Forced re-authentication provides additional protection for sensitive resources in the secure domain.
Authentication is token based. Rest APIs are designed with this too, and can sometimes perform re-authentication.
Of course, sessions are used.
Is such a reauthentication usual in current web applications?
Yes it is. Most web applications that have access to valuable data implement the reauthentication mechanism to prevent information leak.
After how many minutes inactivity does it come? Depends on the application and the sensitivity of the data you're protecting. The normal timout is 15 to 20 minutes (Its even lesser in Banking web apps)
From a security standpoint, is it common and reasonable to only ask for the password (and not the user name again)? "Login" refers to a correct combination of username and password. Most web apps will ask you for the username again. Unless that is you have the "Remember my username" option enabled. This is because a malicious user can potentially get your username after accessing the web app after your session timed out. If he also manages to get his hands on your email (which is usually linked to your username), he can easily reset your password and do whatever he wishes with your account
If you fail to reauthenticate (3 times), is it more common to only end the session or lock the whole account? This too depends on the application.
Data is very valuable -> Lock the account
Not so much-> End session and force Reauthentication (3 more tries)
Best of both worlds-> Timeout the username for a fixed duration (Ranges from half an hour to a couple of hours) and then force reauthentication.
Session times out usually at 15 to 20 minutes depending what it's set to in IIS. That is a reasonable idle time for a user to be logged off. If you need your application to sit idle and still be usable for longer periods than that you'll want to look into token authentication (stateless) and using refresh tokens.