We have a requirement to prevent users from reusing the previous 5 passwords when doing the reset. I read in the documentation that currently, Azure doesn't support the password history feature. Is there any way I can implement it ?
There is a sample for this.
"This policy enables the storing and checking of a user's previous set of passwords in order to prevent them from using a previous password during a Password Reset flow. The number of previous passwords is configurable in this example, and will default to 3 if not set".
Related
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.
Ok, so I've inherited an open-source project with user logins that are a simple username/password combo. Unfortunately, if someone forgets their password, we don't have a password recovery option. I'm hoping to fix that now, but not sure how to do it securely, given that we don't have any other identifying characteristics. User accounts have no recovery email, no "secret questions," etc.
A user account consists only of 1) username, 2) encrypted password, 3) List of document ids which the user has editor access (but this is publicly visible by viewing the user's public page)
Now that I have access to the project, I will be implementing OAuth or similar, but as for old accounts with forgotten passwords that have since been logged out, is there any right way to ID my users so they can do a password reset?
There is no great way of doing this. You just don't have the information; not even enough to contact users. Until a user has supplied their username and password, you can't communicate with them.
You'll need to add a check that runs every time a user authenticates, which checks if they've set recovery data (email or whatever you decide on). From there you have a variety of options, depending on how important you find the recovery data. In order of severity, you could:
Disallow use of the site until they have added and verified
recovery data. Essentially, full authentication fails if recovery
data is not set.
Prompt them to add recovery data, but allow them to skip it.
Notify them that the ability to set recovery data has been added, but take no further action.
If you are dramatically changing login, you'll need to support the legacy method as well until such time as you want to abandon users who haven't made the switch.
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'm working on a new password reset workflow on a website, and i am wondering if there are any best practices on the topic of logging in after a password reset. Once the new password has been entered by the user, should they need to click login and enter their username and new password or be automatically logged in? Personally I prefer them to log in after resetting the password so that their browser has a chance to update its saved passwords. Automatic login just seems insecure to me. Are there any other thoughts on the subject?
Basically I'd recommend having one log-in entry point to your application. Although this additional log-in creates a burden on the user.
I'd say the benefits overcome this:
Easy to track log-in activities
If you want to apply some log-in rules like CAPTCHA, you will apply them in log-in page only.
Browsers password management can identify the password entered only in log-in.
Curious as to how to compare a text box string to the password the user used to authenticate themselves when they started the Microsoft Access database.
Microsoft Access version is 2003. Users authenticate themselves using Microsoft Access Jet security.
UPDATE: Per CesarGon (thank you), this is really a question of comparing hashed values; how might I replicate the hashing Microsoft Access does and compare the hashes?
In your change password form, you can execute an ado sql command:
ALTER USER user PASSWORD newpassword oldpassword
Just make sure the text entered for both passwords are not the same.
http://msdn.microsoft.com/en-us/library/bb177884.aspx
I don't think you can do that. The passwords that users use for Jet security are hashed and stored in the System.mdw database; the passwords themselves are not stored, but only a hash computed from the password. There is no (practical) way to recover the password from that hash.
Edit. You may use the Jet API to have Jet perform the validation for you. This is some sample code:
'set security database.
DBEngine.SystemDB = "C:\Temp\System.mdw"
'create a workspace.
Set wksp = DBEngine.CreateWorkspace("New", "John", "john's-password")
If the workspace is created, then the provided password was correct. If the password was incorrect, the workspace won't be created and an error will be raised.