How do I go about the following scenario: The first time user logs in from a device MFA is prompted. During MFA if user checks "trust this device" box further logins on the device will need only password.
I am using custom policies.
We do something similar with the IP address, although that may not help if you have a shared IP, you might be able to store a cookie as part of login and then retrieve it using javascript and then enter it into a claim on the login page .
Related
Scenario:
I am working on a corporate site, on which you may log in, but it is not a forced requirement.
We have enabled the KeepMeSignedIn / Remember me functionality on the aadb2c login page, but i cannot seem to figure out how to notify my website, if a user has selected to KMSI.
My Question:
How can I signal back to my website, if the user has chosen to use the KMSI / Remember Me functionality on AADB2C.
I can't seem to find any information solving this challenge and I would very much appreciate your help and input.
Kr Ole
You can use the KMSI Claim Resolver to detect if the user selected KMSI check box and issue the claim into the token.
https://learn.microsoft.com/en-us/azure/active-directory-b2c/claim-resolver-overview#context
I am running the open source parse-server and have well secured my database. However, my application requires administrator users which need to have the power to read and write nearly all the data. This is a security concern which I would like to address with two-factor authentication, though I am open to other ideas (IP whitelisting, cookies, or whatnot).
Setting this up on my client apps is straightforward enough and I have done that, but I would like to be even more secure so that if malicious agents have my Application ID (which is basically public) and somehow obtain an admin's credentials, they still cannot gain access.
I am puzzled as to how to accomplish this with the parse server as it is today. There are no Cloud Code triggers for User sign-in, so I can't enforce any MFA on the Parse server itself, as far as I can tell.
One possibility I see is to use check some MFA token in various Cloud Code routines, such as beforeSave, beforeDelete, and beforeFind, denying access to an admin user lacking proper MFA. Would that completely prevent a false admin from reading or writing all data?
The above option does not prevent the attacker from trying to brute force the MFA (assuming it's a 6-digit code). I also don't see any way of rate-limiting the login attempts of an attacker with the App ID and admin password. Any ideas here?
Thanks for any tips!
I really like the idea of adding 2FA and a small script to manage user accounts on the dashboard.
Can you open a feature request on https://github.com/parse-community/parse-dashboard ?
Also, for use authentication, you could probably use a custom auth adapter which would validate the username, email and 2FA token
Here's my question. To access our app, the users must be invited.
This means, we use an admin web app to create the user account in Firebase and we send him an invite to download the app and use it.
Now the next phase, how can we send to the newly created user his credentials?
Our first idea was to use a temporary password. We could send the password by email to the user and ask him to redefine his password at his first logging.
His this a good idea? I guess it's not
Is there a better way?
Thanks for the help.
T
There is no way to prevent users from authenticating with Firebase Authentication. So instead of depending on pre-creating of the accounts, you should ensure that only authorized users have access to the data.
For example, when using the Firebase Database, you could keep a list of authorized users in the database:
/authorizedEmails
t4ncr3d3#hisdomain,com: true
puf#hisdomain,com: true
And then you'd check the auth.email variable against this list in the database's security rules.
Instead of pre-creating the account, you could then simply email the user an invite to the app. E.g. an email with a link like http://myapp.mydomain.com/signup.html?email=t4ncr3d3#hisdomain.com
Then when they click the link, pre-populate the sign-up form with the email address you sent the message to and call createUserWithEmailAndPassword().
You could use the new (as of Nov 2016) firebase-admin library (java or node) to programmatically create users from your server side - see this link for details.
After that, you could send the email and password to the user via email, and allow only email based password logins. Unfortunately, you can't force uninvited people to stop authenticating with your app, as they could manually invoke the APIs used to create a new account on their own, as you see on the same page. However, you are under no obligation to provide a login mechanism via your UI. They would have to use their browser to type and invoke the JS needed to create the account.
If you are OK with people forcibly creating accounts, but you would like to lock down their access, you could do something similar to what Frank mentions in another answer by using admin control of the database to restrict access to those users you have created and invited with a special flag in the database (that only you can modify using the admin SDK) that acts as a gateway into your app. If you perform the security properly, that should prevent those whom you didn't invite from using the app, even if they can effectively authenticate with it.
When a user forgets his password, you shouldn't send it by email. In his Pluralsight course "Hack Yourself First: How to go on the Cyber-Offense", Troy Hunt states that "there is no implicit transport-layer security on SMTP". This answer on Information Security Stack Exchange confirms that it's a bad idea to send or store passwords in the clear (including by email).
The proper way to reset a password, it seems, is to not reset it immediately. Instead, send the user a time-limited activation link via email. This requires manual intervention of the user and also does not communicate the password via email at any stage.
The aforementioned Information Security answer describes how one might implement a password-reset mechanism:
Don't RESET user's passwords no matter what - 'reset' passwords are harder for the user to remember, which means he/she MUST either change it OR write it down - say, on a bright yellow Post-It on the edge of his monitor. Instead, just let users pick a new one right away - which is what they want to do anyway.
If a user forgets their password, send them a secure one-time reset link, using a randomly generated reset token stored in the database. The token must be unique and secret, so hash the token in the database and compare it when the link is used.
The definitive guide to form based website authentication describes the implementation similarly:
Always hash the lost password code/token in the database. AGAIN, this code is another example of a Password Equivalent, so it MUST be hashed in case an attacker got his hands on your database. When a lost password code is requested, send the plaintext code to the user's email address, then hash it, save the hash in your database -- and throw away the original. Just like a password or a persistent login token.
But how will the user actually know the new password. Is it reset to some default? Is it changed to a randomly-generated password that needs to be communicated with the user somehow?
In "Hack Yourself First: How to go on the Cyber-Offense", the activation link takes you to a form where you can enter your new password.
That might be okay if you're dealing with a website, where you can go in and interact with the web application and choose your own new password. But with something like the .NET Web API, you're interacting with actions on controllers that are normally supposed to give you data, not a user interface. You can't just give them a link and expect them to do something with it.
Thus, if you're dealing with authentication over Web API, what is an effective and secure way to allow users to reset their passwords and also communicate the new password to them?
The thing to remember in this scenario is that Web API is just that: an API. Even though there might not be a website, there is still a user interface somewhere (an actual website, or a WPF application, or a mobile application - doesn't matter). So the usual secure "forgotten password" functionality can still be implemented.
There is one difference, however. Instead of sending a link, send the token itself. The UI then provides the place to enter the token. The steps to follow are below:
The user wanting to reset his password goes to the appropriate "Forgotten Password" screen in the UI.
The user is prompted for his username.
A token is sent to his associated email address in plaintext. The hashed version is stored in the database together with an expiry of, e.g., one hour from now.
The user enters the token in the next screen.
If the token is valid, the user is taken to a screen in which he can enter a new password (without having to enter the old one - the token already authenticated him).
Sending a plaintext token via email might sound a bit like sending a password via email. However the fact that it expires after a short period of time gives an attacker a very small window of opportunity to use it. Also, the token is one-time, and is discarded upon use.
There are two concepts you're addressing in this question: password reset and the mechanics involved, and the proper way to authenticate a user to a web API. I think it's important to draw a distinction between them and to understand the latter first.
Imagine you have a web application and a protected resource (web API). The web API requires that all callers must be authenticated by some mechanism. One way to allow a user to authenticate to the web API is to present credentials directly to the web API, but this presents many other issues such as the web API needing to store/maintain/access user account info, the security weakness in sending passwords along the wire in this fashion, the broad scope the web API has to act on the user's behalf when it obtains their raw credentials, etc.
You've probably heard of OAuth 2.0, which addresses these problems. A better way of accessing a protected resource (web API) is to add an authorization layer. For example, a web app presents a dialog for entering a user's credentials, which are then sent to an authorization server and validated, which produces an access token. The access token can then be used to authenticate calls to the web API on behalf of the user (or on behalf of an application using client credentials grant). Using this flow, the web API doesn't need to authenticate users directly, it can be much more lightweight, and many other security issues with the other flow are addressed. See the OAuth 2.0 specification for more detail.
Getting back to your example, a better answer is that you manage password reset at a different level. Your web API shouldn't have to know about the user and password at all, let a lone resetting it -- it should just receive a token and validate it. This allows you to play around with your desired password reset method and it won't affect access to any of your downstream resources.
I want to integrate Multi-Factor Authentication into my custom built, Azure Hosted website.
I want the user to get an OTP (One Time Password) over SMS and then enter that OTP on the Sign-in page.
How am I supposed to verify the OTP entered by the user on Sign-in page? I was unable to find anything related to that in the SDK and online documentation.
SDK documentation on MSDN http://msdn.microsoft.com/en-us/library/dn422962.aspx tells us that:
"Text messages. Windows Azure Multi-Factor Authentication can send an SMS text message with a one-time passcode to any mobile phone. To complete the sign-in process, the user is prompted to reply with the passcode or passcode and PIN, or to enter the passcode on an application sign-in screen."
but unfortunately it doesn't tell how the sent passcode is verified, either via the SDK itself or some other way.
It's really confusing coz one would think the received token needs to be entered on the comp, but apparently the SMS needs to be replied to the SMS sender. All the docs on the net shows differently, they all show some second login screen for the token to be entered:
http://www2.warwick.ac.uk/services/its/servicessupport/networkservices/vpn/itsvpn/
But no, it's not quite how it works with Azure.
For whatever reason SMS didn't work for me. I did receive the SMSes but even after I replied to the sender number, it still wouldn't authenticate me. Also, it'd have increased the costs even further so I just sticked with the automated phone call.
Now I use it to authenticate VPN users on our Cisco ASA firewall. The authentication process goes like this:
user clicks on connect in the VPN client
user enters user + password, then clicks login, now the client is waiting for a response
credentials are sent to ASA, which asks the Multi-Factor Authentication Server if they're ok
the MFAS verifies that they're ok so it tells Azure to call the user's phone number
user receives call, presses the # key (that's the "standard" method, there's also a PIN method), then Azure hangs up the call and tells the MFAS that it can proceed
MFAS tells the ASA that the user's authenticated
client exits the waiting state and logs in