An OTP (TOTP, SMS, email whatever) provides an additional check in order to authenticate.
What MINIMUM SET of operations should be protected by the OTP check to ensure the additional authentication check is not pointless?
My starting list is:
Login
Remove or modify OTP protection
Modify email address
Change password
Is my list overboard or incomplete (as a minimum set)?
After implementing and experimenting with MFA in our application, this is my conclusion. The minimum set of operations that should be protected by MFA once it has been set up are:
Login
This is a big catchall to protect all account operations by having to go through at least one MFA check.
Removal of MFA (additional check after login)
Obvious. We protect removal of MFA during an unattended logged in session.
Changing of email address or any identifier used for logging in (Additional check after login).
This is critical to prevent the account effectively being moved to different ownership.
We found that password reset/update was not actually a desirable operation to be protected with MFA. Reset required access to the account email address and update required knowledge of the existing password.
Related
We have multistep register form where user can set their password in step 2.
(User register should happen in step1 itself) So, we will set random password during step 1 and registering user details in Cognito user pool.
But end user submitting actual password from step 2.
Cognito will not update password (from step 2) without sending old password (random generated from step1). Cognito considers this process will be password update.
So how we need to handle this situation? or Is there any option / tricks which amplify provides to overcome this case?
More context is needed to fully understand why a random password is necessary for the user in this situation.
For example, if you are trying to create a multi-screen signup process and you don't want the user to get to the end of the process only to find out their password doesn't meet standards, e-mail already exists, etc., it may be more conducive to the user experience to check if the user already exists in the user pool first using ListUsers, collect the data as they move through the steps, and finally call the SignUp API call.
While I would highly recommend reconsidering the approach taken, the AdminSetUserPassword is a backend API call that can be used to set a permanent password for the user, although extreme care should be taken with this method to prevent the API call from being used maliciously on another user.
I'm considering building a website user authentication system using only one-time-passwords: users would get one in the email each time a normal password is normally used e.g. for signup, sign-in, risky actions and account deletion.
Some problems that I see with it that don't seem critical:
Can't change password to invalidate all existing sessions - can work around by storing sessions server-side and having a way to invalidate them for the user
Anyone can check if a certain email is registered in the system - doesn't seem like a critical problem for a generic website
Anyone can request an OTP for any email - will be dealt with using API limits per remote connection and a limit of 1 unused OTP per hour
I'm not seeing this method mentioned or used in the wild though. Does it have any major drawbacks? Many thanks!
OTP-by-email only is safer than password-only (it's basically like forcing the user to change their password every X hours).
I want to both address some of your non-critical points, and highlight some drawbacks.
Non-critical
Invalidating sessions
You don't have to store all sessions, only the invalidated ones, and only for the max duration of a session.
Checking that a user (email) is registered
That actually is a problem - it tells you that the email owner uses this website, which is a privacy issue, however minor.
But moreover, it's an attack vector. An attacker can scrape your user list, or just go attack that user on other sites, presuming that this email exists and links to a real human. Moreover, they can issue excessive OTP requests on their behalf, which I'll address in a bit.
All that said, there's no reason which this problem would manifest just because of OTP. A user can request OTP, and you can always reply with "If the email address hello#world.com is registered, a one-time password has been sent to it". This only has a slight usability implication.
Anyone can request OTP for any email
If an attacker can flood your site (from different IP addresses) with requests for OTP for hello#world.com, either you block this user (namely, that user has been DoS'ed), or you the site will flood the user's mailbox, which can get that mail server to flag the site as a spammer.
This could also be done in normal sites with password-reset emails, but that's why you typically want your user list to be secret.
Bigger drawbacks
Usability
OTP-only login assumes that the device from which you're logging in is also logged into the mail account linked to this site. Otherwise, the user has to log into the mail account in order to log into your site.
Single-factor authentication
The security community is pushing towards multi-factor authentication, where password is usually the first factor. A good practice would be to at least allow 2FA to users who choose to.
Account lockout
If a user's email account is no longer accessible for whatever reason (e.g. they used their work or university email), they can't log in, or even change their email address to their new one.
Email activity
If the site is heavily used, then it will be sending a lot of emails, to various public email services, continuously, all the time.
This alone may cause the site to be flagged it as a spammer, or even ratelimited.
If it does get ratelimited, some users will not be able to log in.
I have IdentityServer4 setup for API authentication although I have a use case where I want to verify that a guest (user) is essentially a valid user. A valid user in my case is anyone with a valid email address, so I want to do the following:
send the user an email with a verification token (preferably something which is a mash up of their email address, some salt and an expiry
the user can then enter this token into my app and they are "allowed" to go ahead
I was wondering if IdentityServer4 can/should be used to achieve the above?
Their tools show that you can generate a token although I am very new to this topic so was hoping for some guidance.
No, the tokens Identity Server deals with are access_tokens which are to do with claims-based authentication.
The tokens you need to use for email verification are commonly referred to as User Tokens, or one-time passwords (OTP). You can find a wealth of information on how to generate/consume these using those search terms but if you use the aspnet identity classes such as the UserManager you will find it has some in-built read to use. Or you can register your own UserTokenProvider with the UserManager.
In general you'd do something like this:
Use your UserTokenProvider to get a token (otp) for a specific user. The UserManager will use the security hash of that user and your own 'reason' (e.g. "EmailVerification") to generate the short OTP.
You could then wrap that OTP into an object that includes the email address, a userid maybe, and whatever you like. Safe Base64 encode it (there is a helper function within Identity Server that has this in fact, making sure it doesn't have the superfluous _ at the end which will mess with HTML links), put it in an email to the user
User clicks your link which takes them to your 'verify password' controller, with your mashed up token as payload. You decode it, work out which user it was for, get UserManager to verify the OTP part is still valid.
Job done.
If you want them to enter the OTP into your app directly, while logged in, then you could just skip the whole mash-up part of emailing a link, and email the short OTP directly.
I'm trying to create a website to authenticate users through the use of a throwaway password where the assumption is that the user might not use the website again (basically a one time access).
I have done my research on OTP and various solutions to authentication but these don't seem to fit my requirements, most of them seem to rely on users having login credentials to the website whereas my system would allow them access without the need for registering.
The implementation of passwordless authentication by Auth0 seems to fit what you're describing. Even if you were not considering a third-party provider it may be useful to go through the documentation.
Basically, a user can login to a site without any need for a sign-up process. They can do so just by requesting that a one time code is delivered to them, for example, either by email or SMS.
This way, they can get quick access without having to setup a user and in the event that they do come back your application can recognize this because they will most likely be using the same mechanism, that is, you can use the email or mobile phone as the unique identifier.
Disclosure: I'm an Auth0 engineer.
If you do not require your users to register, why do you need authentication at all?
Why not just set a cookie with an unique identifier on the first visit? You can store data at the server side associated with that identifier. Keep track of when you last saw the user, and if they do not return within a certain period, you can delete any data you stored for that user.
Difference Between Two-Factor and Two-Step Authentication? How it is different from each other with an example?
In two-factor authentication the user will be required to provide information of two different types in order to identity themselves. Generally the types of information that will be required are a subset of the following:
Knowledge: Something the user knows (e.g. a password)
Possession: Something the user has (e.g. a physical key)
Inheritance: Something the user is (e.g. a fingerprint or retina scan)
With two-step authentication, there's more than one thing the user will have to do, but it may be within the same type of information. For example, the user will provide a password and a pin. Both fall within the same type of information, something the user knows, but it still is a two-step procedure.
There's also the fact that sometimes it can be argued that some approaches to two-factor authentication are not indeed two-factor and more like two-step. I would say, the most debated discussions are around implementations based on cell phones, because even though a cell phone is something you have, sometimes you authenticate by reading a piece of information from the phone and in theory that means that it's actually something you know.
Having said that, and not wanting to a be a terminology purist, any means that provide additional protection besides just a password are a huge improvement. You can check Getting started with Multifactor Authentication for a further read.
The difference between two factor authentication and two step authentication is method used to verify the user's identity.
Two Factor requires the user their password then another one time password
This one time password is either a code received on their mobile device, or perhaps a code generated from an app like Google Authenticator.
Two Step Authentication requires the user to enter their password and the next step the user is in possession of the token or cookie on their computer
If the cookie or token doesn't exist - they are then have to enter a One Time Password that they receive via SMS, Email or use an Authenticator application.