I have a unique requirement for a password reset.
We have users without email(or have invalid email), they just signup using a username.
So, to reset passwords, we want to have a separate UI application for support people that will allow resetting users' passwords without needing to send the password over email or can be sent to the common support email of the organization.
Is there a way we can use Graph API for this purpose? Custom policies need email to send passwords over(don't want the user's phone numbers at this moment).
Appreciate any leads in this matter.
Thanks.
Yes, you can.
But not ideal. The support person knows the password. And how does the user get informed of the password?
The correct way is to use a magic link that contains the username and when the user clicks on the link, they get the reset password flow. That way only the user knows the password.
Related
How is it possible to pre-create users programmatically (via Graph-API) and have a same mail address configured for them to be used along with the password reset user flow?
I figured that the signInNames mail or StrongAuthenticationUserDetails mail attribute are being used with the standard flow. BUT, signInNames are unique and StrongAuthenticationUserDetails (Authentication contact info: Email) is not editable via Graph API as of now.
Any idea how to accomplish the scenario above without developing our own password reset flow?
I assume the scenario is creating user by invitation, where customer changes their password after first login.
Here is the sample for doing that
https://github.com/azure-ad-b2c/samples/tree/master/policies/invite
If you want to use the user flows,
You can create a user account as mentioned below, and then set the password reset user flow link to them. But then you will need to ask your customers to update profile as well, so that you know more about them.
https://learn.microsoft.com/en-us/azure/active-directory-b2c/active-directory-b2c-devquickstarts-graph-dotnet?tabs=applications#create-consumer-user-accounts
How can I detect if a user already singed with a social account on my website and now wants to create a normal account?
How do I detect the changes?
My personal vision on this:
Let the user sign in with social auth then add the email in the database(mongo) but with no password?
Also when the same user wants to register on the website with the same email but without the social auth and a password, i should redirect him to his profile info from the social auth like username?
An example of what I am talking about:
User signs with google+ on stackoverflow
Then after a while comes back to sign for an account with the same email but a different password.
What is the best way to deal with this situation also from the GDPR standpoint can I use passport for this?
Thank you
When a user registers with social auth, you can also prompt for password (if you wish so) or create an account without it. Next time when a user registers using the same password, you should show an error message 'Email is taken'. In that case, user should receive an automated email that there was an attempt to use his email containing information on how this account was created (e.g. with Google+) - as a reminder.
Using social accounts for auth isn't safe and asking for password (requesting long passwords with special characters, upper/lower case letters) adds a little bit to the overall security. And Two-Factor Authentication takes it to the next level. For most websites, it should be secure enough. Temporarily blocking accounts after a number of unsuccessful attempts is easy to implement and protects from brute forcing.
Alternatively, a user should have an option to restore access to his account by means of requesting a password recovery URL to be sent to the email attached to the account. Then a user is prompted to input password that will be saved for the given account. Thus a user can log in to his account using email/password or the social auth that was used to create it.
With regards to GDRP, a user should be able to:
see what social accounts are connected to the profile and be able to detach them
delete his account (the right to be forgotten)
see what data is stored on him and export it (data portability)
modify data (Right to rectification)
opt-out/in for getting promo emails
manage advertising Cookies
There should be clear T&C provided with a full description of what data is stored, why and for how long.
Additionally, security (2FA, https, etc.)
This is in a nutshell ...
On our website, we have existing users who use username(=email address) and password to authenticate. Now we also want to offer "Sign in with LinkedIn" because we know that a huge fraction of our users is also on LinkedIn. Doing this is technically not too challenging with PHP.
For new registered users via "Sign in with LinkedIn", I would store their LinkedIn ID upon registration, so this is nothing they can manipulate. So when they return, it's an easy decision: Check the LinkedIn ID, if it is known than all is good.
Now comes the tricky question: If an existing user decides to use "Sign in with LinkedIn" for the first time, is it enough to check if we have his email address in our database and then assume that it is him/her? Should we check additional data or...?
Thanks for any hints!
Since email address is unique key and it represent the username, i think you don't need any additional data to check if it is him since his/her password is equivalent to the linkedIn email address.
For a web application, where we need to store and manage users (SSO or openauth or what not is off the table), where we manage important business data, how risky is it to use an email address + password as the sign in?
For the last 15 years or so, encryption and protection techniques have improved, but we continue to use a proprietary user id, akin to using your bank card number for online banking; an id that will not be reused elsewhere. Customers and product owners are pushing to use email address because it is easier to remember.
I am concerned that there are a lot of websites that collect email + password pairs in order to use them to try to hack other sites; presumably asking you to sign up for an account for some humble service or other. What is this activity called?
I'm looking for some article or argument why using email+password for a site with sensitive business/financial information would be dangerous; or why it is not so bad. Again, I realize that provisioning our own accounts is not the ideal thing and am not looking for solutions at outsourcing authentication.
The "risk" of using a single authentication method for signing onto your application is difficult to determine without a risk assessment, and clearly defined system boundaries.
NIST 800-61 and NIST 800-63 gives guidelines on authentication methods for different levels of sensitive systems (in your case, a application). It will give you ideas on how to present your argument, and maybe an alternative solution, i.e., multi-factor authentication if the customer wants to authenticate using an e-mail address. This would mitigate the risk associated with malicious websites which collected e-mail addresses and passwords.
Keep in mind, password policy can also be managed to mitigate the risk behind a single authentication method using an e-mail and a compromised password associated with that e-mail.
All in all, it's not the ID that is important, but the authentication method and policies in place to mitigate the risks.
Using email + password as credentials is the widely accepted method of allowing users to log into sites on the web.
The advantage of using email is that everyone remembers their email address, whereas people will have difficulty in remembering which username or user ID they first signed up with if this is not their email address.
Username should not be considered private. This is the job of the password. Encourage your users to use a password manager such as LastPass where it can generate a 20 character completely random password (128 bits - uncrackable) which is different per site. LastPass will remember the username if this is not their email, so that solves this problem, however not using email can bring other problems such as username enumeration. If any signup function asks for a user to specify their username and you say that it is already in use, an attacker can use this to narrow the list of users in order to prepare for a password guessing attack. If you ask for email as step one of password reminder or signup forms, the system can send an email with a password reset link if already registered, or send an email with a link to the next step in the registration process if not.
In the end it all comes down to the value of the data your application is protecting. Adding two factor authentication is always a good step and can protect against password guessing and password reuse.
SSO or openauth or what not is off the table
Why is the case? Can't you use OAuth with claims based authorisation? You can still secure your application and make sure only the correct business users have access - it would just be that another entity is managing access for you.
I am concerned that there are a lot of websites that collect email + password pairs in order to use them to try to hack other sites; presumably asking you to sign up for an account for some humble service or other. What is this activity called?
Credential harvesting?
I have searched all over and can't find any answers on this. It's clear that for a password reset scenario, where the user has forgotten a password, the system in question should send a temporary token/link to the user's registered email that takes the user to a secure page that allows the user to select a new password.
What I'm asking about is the case where a user knows the current password, and wants to change it. I'm proposing either
1) the user could enter the old password and new password, and an email will be sent off asking to click a link to confirm the change (which also serves to notify that a change request has been made), or
2) the user could enter the current password and gets sent an email with a link that takes them to a new password selection screen.
Yet, I don't see this process being used anywhere. Is there a reason this approach doesn't buy you any more security, or is there a security flaw in this approach?
It seems to me that this would add an extra layer of security, as it's a type of two-factor authentication. Consider the case where the user's password has been compromised, but the password is different from the user's email password, and the attacker has no other method of accessing the user's email. The attacker would not be able to lock the owner out, since the attacker would not be able to click the confirm password change link. As an added benefit, this would serve as a notification to the account owner that someone was trying to take the account over.
Is this simply deemed not worth the extra hassle?
I can think of 2 reasons.
1) It will annoy the user. Every extra step tries the users patience.
2) It doesn't add security. If someone has the current password, they already have access to the account. If the attacker doesn't have access to the email account, they can't permanently lock the user out anyway.
What you should require email verification for, is changing the user's email address.