It's better to send the reset link for 3 reasons:
Users don't need to remember a temporary password and they don't
experience copy/paste issues.
Most users don't remember their password because they haven't logged-in for a while, so usually don't remember how to change their password.
It requires less activity.
We have spent the last months battling with what to do with email confirmation/verification - prior the user had to give all their details at sign up (way too many actually!) but couldn't actually login until they had confirmed their email address by clicking a link.
We stood back and looked at why we did this - three reasons really, one being we wanted ...
Many might think that the complementary email might be useless, but this is actually a security message. What if someone left their account logged in, and someone changed the password for them? The ACTUAL owner of the profile should be notified that it was changed.
It has become a standard to make sure that users are aware of what information has been ...
A link is much more accessible. I can get to a link via click, tap, or with the keyboard easily; and in a confined device like a smart phone the process of opening the site in question is much smoother and easy. If I have to select, copy and paste a password from an email I need to be a little more dextrous, especially on fiddly ...
Sending a password at any time for any reason is bad UX.
This applies equally to email and sms text messages. Even if the password is temporary it can lower the credibility of your brand. Building a relationship of trust is one of the most important things we do and emailing passwords always feels wrong.
When sending a reset link it is also important to ...
If you're fine with not having a verified communication channel with your user. Then sure.
But I can't really think of an application where I wouldn't want that. Because not having that verified email means that a forgotten password is the end of the account.
Further there's few things I'd allow that type of unverified user to do that I couldn't just do ...
Switch to two-factor authentication and reduce the frequency of forced password changes.
BTW, your system storing their last 12 passwords, even encrypted, is a major security problem. A hacker who steals and figures out how to decrypt them will have 12 guesses for all of their other accounts online.
The NIST has a policy for passwords that can be helpful to answer your question. First you should talk again to your security team. The NIST has deleted their policy to force users change their password periodically. The NIST Digital Identity Guidelines FAQ states:
Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., ...
As the search results are only tied to the search term it would be natural to place a clear link/button as near to the search-box as possible, preferably inside the search-box(as done in Safari).
Also I would recommend you to keep more distance between the search-box and the action buttons(preferably by putting action buttons below the table) as the action ...
Well, this is some kind of old approach imo. A while ago username was usually used for two purposes: as identity (to log-on) and as something to display (when you post comments for instance). I believe it came from standalone apps and operation systems, where email is something secondary and username is something primary. Meanwhile it doesn't work in a web, ...
Keep track of active reset links for a given email address. If a link is still active, and the 'forgot password'-button is clicked again, resend the active reset link. You can even warn the user that an email was already sent and that she should maybe check her spam folder.
You still run into the problem that no reset link should be active for longer than ...
What I've seen so far,
Restore Default Settings
Reset App Settings
Reset All Settings
Followed by a confirmation dialogue informing the user that all his/her saved settings will be lost and the application will be rolled back to its original state.
I dont think that confirming the email address is just about having a communication channel to the user.
I think that confirming emails is an absolute must, if not you have to cleanup in order to ensure that no one spoofs existing emails of other users. E.g. someone can register all emails of another user to troll him.
Or if he merely mistyped his email, ...
Sending a link is a way more better because:
Sending a password in an email reduces trust.
It is hard for the user to remember it (mostly it will be a combination of some letters/numbers/special-characters, producing a word that makes nosense)
Fewer steps by far (which is a lot better on mobile):
1- click link --> write new password
.. VS ..
Some options to consider:
Two-factor authentication. I'm not a fan, but it might be better than what you have if it would reduce the frequency of password changes. It doesn't make much sense to require two-factor every 30-minutes from the same location, so consider limiting its use to once daily or upon IP/location changes. Also, beware of SIM swap scams.
Verifying an email address is less trouble than all the troubles that could happen if not having one for an account.
Nobody is going to join your site simply because they don't have to verify their email address.
So you should have them verify it but make it as fast and as easy as possible.
For a cleaner look, avoid having a reset button. Hovering (although complicated) is visually more appealing.
For a "null" vote, you can have a 'o' (preceding the stars) which can turn red when selected -- meaning the user has dropped his vote.
o * * * * *
(Many current systems do not have the provision to remove a vote; if a user doesn't like the product,...
It depends on what the risks are.
As you've pointed restricting the user to only use new passwords means they have to memorise more passwords, etc. This adds a burden to the person using the system.
The advantage is that it puts a limit on the period of time a broken password can be active.
It also means that if an attacker succeeds in changing a ...
I think the main thing to worry about here is the familiarity of forms blanking the password field on a form validation error.
Since most users aren't savvy enough to distinguish between an AJAX request and a standard one, they may think their password field not being blanked after clicking "save" and receiving an error is unusual/insecure behaviour.
If you're designing for both desktop and mobile (ha! Who isn't now?) then it's a reset link is better than a temporary password. Why?
It's difficult to copy and paste a password on a mobile device
It's difficult to remember the nuances of a strong temporary password in between switching browser tabs on a mobile
People are unlikely to change their temporary ...
During creation of a password: (new user or password change)
People would generally tend to be surprised if they didn't get a confirmation email of changing password.
Not only does it serve as the early security alert option for those who may have had their account altered by others, but it also serves as a confidence booster for those who did genuinely change their password. Note that the email has to be immediate ...
The company db was hacked and user information was stolen. The company is asking everyone to reset their passwords asap to limit any further theft using personnel ids.
In such a scenario, it is utmost important that the users DO NOT use the same password.
Same situation is also faced when someone has 'hacked' into your account. If you reset ...
It does not matter which token is being used and all remaining links
This is the behavior I would like, and the email could explicitly state "this link will remain valid until [some date-time] or until your password is reset, whichever occurs first" (if the password were reset someway outside the email resets, e.g via tech support, all ...
I find what happens when you send a temporary password, the user never goes back to change it and it's usually too difficult to remember. So what ends up happening is that the "forget password" link is pretty much used every time the user logs in. The goal really is to get them to reset their password to something that they will remember so best to be ...
If you need to do email verification check, don't let that be the show-stoppable for the users to continue interacting with your site, that might just increase the drop-off rate.
Other reasons such as delay in the email sending, email going into user's spam folder, will just add more reasons for them to stop interacting with your site.
As what others have ...
I'm gonna answer this with some information that @Peter provided in the comments:
Like he said, there is a lot of information widely available about why you should not use Password Masking and how it has a negative spin on UX. Here are some resources from people who really know their stuff in terms of UX.
Jakob Nielsen has an article on why you should ...
Here are a few methods that have been used in the past by other systems that I have worked on.
User has to input their date of hire along with a unique password on first entry and for all future password resets.
All employees have a default patterned password that leverages bits of information from date of hire, employee id, and initials. This will expire ...
Depending on which application or company asked you for a password reset it is usually a matter of convenience. When it comes to designing these kinds of flows, usually little priority is given, as it would be seen as an edge case. A case like this is not a primary feature of a website or app and is therefore treated with less urgency.
From a UX standpoint ...
Now that I know it isn't for any security reason, I'll fall back on the reason being tradition, ignorance, and laziness.
Okay, maybe someone thought if you make the user enter the password again (possibly the third time after entering it twice to reset it), the user is more likely to remember it. I don't know if that is really a net gain for the user or not....