Tbh I don't really see any use for the "forgot password" button/link, unless the user put in a wrong password before.
Let me try to paint a picture to explain why the comment above is a huge oversight.
Imagine a scenario where the users come to your application after a while and they don't remember the password. It means, they already know that an account ...
If the user can type it then it should be allowed in their password.
Telling someone what they can and can't use in their password always feels wrong to the user. Passwords are currently the most universal way to authenticate. Preventing users from entering anything is, in essence, telling them who they can or can't be.
1. Any printable character that a ...
On the second page, either display "user found" and ask for password, or "user not found" and ask for e-mail again.
One compelling argument against the two step approach is that the proposed design would allow for any unauthenticated person to determine if an email account has registered with that site.
This is a problem both for security and for privacy.
A compromise is that when a user returns to the site after 6 months (or whatever period) then you might helpfully recommend that they think about changing their password - along with a link to why this can be a good thing for them.
This also allows you to put in a framework where you might want to bring forward the date at which this happens to a specific ...
No - It is a bad idea:
a. Storing password as plain text instead of hashed with an individual salt. More details here and here.
b. Emailing a password, as:
b.1. emails are transmitted unencrypted over the Internet. More details here and here.
b.2. Users could open up the email and accidently expose their plain text password to someone standing next to ...
Some compact keyboard layouts don't have a numpad, so those keys are mapped to the right-hand side of the letter section:
If NumLock is on, then a user typing the password kill, will actually type 2533. Turning NumLock off will prevent this problem, but of course - it will cause another one for those who do rely on the numpad. Keeping it on or off by ...
In my experience this happens for a number of reasons, some intentional and some unintentional.
Intentional reasons to trim whitespace:
Users often cut and paste passwords (yes, use of Notepad as a password manager really happens) and the paste operation for some clients adds a whitespace.
Phrase (multi word) passwords are ...
Researchers from Carnegie Mellon University recently (2012) looked at password strength meters and its impact on password creation. The paper "How does your password measure up? The effect of strength meters on password creation" has all the details, but the abstract summarises their findings nicely (emphasis is mine):
We present a 2,931-subject study of ...
So basically you want someone who signs up for a new account and enters already existing credentials, to log in as the owner of these credentials?
I wouldn't recommend this:
The chance that the person signing up is not the owner of the existing account may be small, it is still possible.
The difference between signing up and logging in should be clear.
If you want something compelling that your boss can grasp then I suggest you speak to him in the universal language known as money, dinero, ducats, dolla-dolla-bill-y'all
Your current situation
Your suggested design will create a security flaw and your system is bound to get scraped for valid usernames
Do what I say and tell the magic ...
It's a very bad idea to not show the link. You should always give the user the option, even if they are likely to try a few passwords first.
How about an example - what if you have a password manager, and your credentials for this site is somehow lost/missing from your password manager?
You have no idea what the password is, as it will likely be some ...
All you're doing is pushing the security requirement into the domain of the user when really it's your concern if the data you are protecting is serious. In this case it doesn't matter what you do with passwords, you must employ secondary measures, such as two-step verification (GMail, Github), session deletion (GMail, Github, Facebook), unusual account ...
No. While it seems to be annoying, I see four problems with not having to enter the login information again:
I will remember my new password better if I have to type it once more. (I keep forgetting my new e-banking password because I don't have to re-enter it, and I of course don't store it in the browser.)
If I want to store the password, the browser PW ...
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.
Yes, log the user in
There are several ways an existing user might end up on a sign-up page:
User clicks sign up by mistake
User recently signed up for an account and the browser URL autocomplete takes user back to that URL (most recent)
User forgot they signed up previously and is attempting to sign up again (and, like many users, ill-advisedly uses the ...
This article by NNGroup actually covers this exact topic.
Using a placeholder that says "Password" with no additional label is the worst way to go about it, there are many reasons presented in the article as to why but primarily
Disappearing placeholder text strains ...
There are a number of variations of the the "unmasking eye" icon but they mostly have the same issue, below are some examples:
I have done some usability testing on this specific problem and many users I have tested with didn't even notice the "unmasking eye" there is also some issues with how to best convey the state of the password (...
In my opinion: YES.
The authentication has been done when the password is reset, so the user could be logged in. And it annoys the hell out of me when after password reset I'm not logged in.
I can't think of any case I wouldn't want to be logged in after resetting password, why would I even ask for password reset if I don't want to log in?
If a site requires that passwords only contain certain character codes, then a user will be able to enter the password into almost any device which is capable of producing those characters. If the password contains character codes which may be entered on some devices but not on others, then a user who creates a password on a device which could enter the ...
There are chances that user might have no idea about their registration status on the site. And start a fresh registration.
In such a case, best solution would be to OFFER a way to login by inline validation. Before the user reaches the password field, the validation should suggest ways to login as the email is present in database. But, since its not ...
Passwords should not be stored in plain text anywhere including the users email inbox.
What happens if his email is compromised or if he's entered the wrong email address and someone else receives the password?
Password strength indicator does not, per se, guarantee stronger passwords - from a pure UX perspective the more complex your requirements are the more likely people are to click away, to use an existing password or to write it down hence making it harder for a human to remember but, all too often, only marginally more difficult for a computer to crack.
I disagree with the other answers, and say yes, it may make sense (with a couple of caveats).
There is an increasing prevalence of the combined login/sign up form pattern on some sites, where the whole sign up form is simply email address and password, and all more substantive profile questions become an optional step after registration. This pattern ...
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 ...
The quick answer: Amazon, Google and my bank don't make me change my password every six months, or indeed ever. What do you do that requires more security* than they do?
Let's hope for your users' sake that that's a persuasive argument**, and you decide not to do that. The supplementary discussion point is: why do you need to store their password? Could you ...
I would like to add to DaveAlger's point. I, like many people, create algorithms in order to better remember passwords. I've spoken to many people (in an informal manner) about passwords and I have heard a lot of objections
why can't I use a part of my email or my username in my password?
why is there a character limit? (affects my algorithm)
why can't I ...
High password entropy protects against brute forcing passwords. It does not protect against any other attack against passwords. Your first task should be to ensure that the passwords will not get stolen from your servers and that you have proper timeouts. With regard to password policies my stance is as follows:
Do not store passwords in plain text. If you ...
For the most trouble-free experience, you should have the user log in again right there.
Many users have some sort of password manager or use their browser to manage passwords (or scribble it on a sticky note affixed to their monitor… ack!). The only way to assure the user has completed their end of the password change is to log them out and have ...
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 ...