I've implemented 2-factor authentication in my ASP.NET Core application. Yesterday I implemented the use of recovery codes, to be used in case a user loses his device.
My question is actually pure theoretical.
If a user has used a recovery code, we don't want to disable the 2-factor authentication. But in order to disable 2FA, the user needs to generate a verification code using his mobile phone. So he will not be able to turn off 2FA in any way.
So the only thing to do for someone who has lost his device is to keep using backup codes, keep an eye that they don't run out, and generate new backup codes in time (which he has to write down again). Or ask the administrator to disable 2FA for him. But isn't there a better way to deal with this kind of cases?
I ended up doing the following:
Enable 2-factor authentication: Obviously, here you request a verificationcode
During login: Request verificationcode, but also allow TwoFactorRecoveryCodeSignInAsync
Disable 2-factor authentication: Allow both verificationcode and recoverycode
Bypass 2-factor authentication for external logins + Generate new recoverycodes: Only allow verificationcode
Related
I have implemented an API in Express with passportjs local strategy for authentication, now I would like to enforce security by adding the possibility for the user to log in using two factor authentication, for that it exists passport-totp strategy, I read about it and saw some working example, but I didn't find out yet what I want to implement. I would like on a same route (let's say /login) to check if the authenticating user has the 2fa previously enabled (this would be handled by user settings) or not, if it is enabled then having it authenticated only if the user complete the authentication by following the 2fa additionnal verification, if it is not enabled, having the user authenticated by they simple login/password credentials.
If anyone could explain to me how to do it (the big picture) or if you know any example of look a like implementation, I would be very pleased !
Thank you
I ended by dropping passport-totp, implementing simple authentication flow with local strategy and added a custom layer to handle second factor
I'm using AuthFlow='ADMIN_NO_SRP_AUTH' to set up Cognito MFA authentication.
I wonder if Is there any way that I can ignore the MFA authentication?
Which AdminInitiateAuth request should I use?
For example:
I create a user, then register that user to my UserPool, enable MFA for that user, and now MFA is working fine.
But what if on a bad day, I don't want to use MFA Authentication anymore, but I also don't want to disable MFA for my user because I want to use it on another beautiful day.
May not be the answer you are hoping for but... You can't do it. And it wouldn't even make sense.
The MFA is either enable or disabled. If it's enabled, you need to authenticated with it. Think about it. You set it up to protect user's account. But the user is able to say - oh, I actually don't want to use it just this time.
The thing is - a bad actor could do exactly the same. Just send a request saying not to use MFA. That would defeat the purpose of MFA entirely.
That's why this decision is left to either an administrator of the pool or the user who can disable it, but only as long as he/she is signed it (depending on pool's configuration).
That's why you can only either have it enabled or disabled. And you cannot disable it ad hoc per request.
i am new in PWA and i was wondering if it´s possible to authenticate a user offline. I mean that if you can have a file in the local storage with the information of the users to perform the authentication.
This file would be saved for the first time that any user authenticates with an internet connection, to then allow the authentication of any of the other users offline. Is it possible? Is it safe?
Any advice please? Thanks
You could not actually authenticate them because that would require hitting an identity service like Auth0, Cognito, etc.
Hoever....(modern tech is great)
If you leverage the Authn authentication you could hook into device authentication like Windows Hello. I will be honest this is way more difficult than it should be IMO. But the actual verification is done all on the client (way too deep to cover here).
But....
You wont be able to get an authentication token from your identity service since you are offline, just verify the identity.
Now to deal with the coupon that would not require actual authentication that you could do. As far as applying it to an online purchase you would of course need to be online to complete that process. But you can cache the transaction and sync it up later.
I hope this helps. It is not a short answer sort of question :)
I know this might be a very unusual question but I have been using IdentityServer 4 on .Net Core 2.1 for quite a while, serving all sorts of different APIs/Clients/Mobile Apps with connection to the internet at 'all times'.
Now I have encountered an interesting scenario where a User will have access to the internet and be able to authenticate with IdentityServer once but might not have access to internet after an X amount of time (X could be minutes/hours/days), but I still need to authenticate that user and login to use the 'offline features' of the app (even after closing the app).
I have thought about caching some credentials to then verify that the user is valid or using a system where I send an SMS code to then verify the user has the right phone (But that will only work if the app is on a mobile device, hence, not ideal). I'm still not set on any of the options.
I just wanted to ask if anyone else has encountered a similar problem like this, any suggestions would be appreciated. Please have in mind that the user may be logged out after using the app and still needs to be authenticated even if there is no internet connection. I like IdentityServer4 quite a lot, so I will prefer to keep it that way, and My App is developed using Xamarin Forms (iOS, Android, UWP), and the IdentityServer instance is on the cloud.
Thanks a lot for the help, any suggestion is appreciated.
Since only your service will know how to authenticate someone using their server-side credentials how about using the local secure platform features of the device (Secure Enclave, SafetyNet, whatever Windows does)?
The end result is that the user can use their already-configured PIN / fingerprint / faceprint to access your app, all backed by tamper-proof security hardware.
This also gives you the option to allow users to sign in only using their local credential by unlocking a previously stored refresh token. My banking app works like this for example - modern phones are really quite secure by default.
If you want to get fancy you could also enroll their device as a WebAuthn authenticator in your IdentityServer4 service and they could then use the same method to authenticate with the server when necessary.
Everything I'm reading shows that in order for an application to use onedrive, it has to do the oauth2 thing to get credentials. But what if you're a batch process and don't have a web interface for your users.
Google's API has a special type of account called a service account where once you set it up, you can control access to everything from that one account, no need to interact with users. Does such a thing exist for onedrive?
App-only authentication doesn't require the user be prompted for credentials but it also isn't supported in 100% of scenarios. For example, the APIs need a user principle for creating special folders and resolving a user's personal site. Also, it is only supported for OneDrive for Business, not Consumer. Consumer always requires the user be prompted for initial authentication.
Another option would be to spin up a web service of some sort that handles initial user authentication, ie. a sign up page. With that, you can retrieve a refresh token for offline authentication and store it for the user. Every authentication from then on can be done using the refresh tokens, which doesn't require a user prompt.
I finally found this. It's the same basic idea as google's service account, but I think it's harder to use. But at least the concept is supported.
http://blogs.msdn.com/b/exchangedev/archive/2015/01/21/building-demon-or-service-apps-with-office-365-mail-calendar-and-contacts-apis-oauth2-client-credential-flow.aspx