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 ...
A better modification of such a statment which I see being used is:
'A company_name employee will never ask for your password'
This message alerts the user that if the person is asking for a password, there is something fishy and he should alert the concerned authorities immediately. With all the live chat functionalities that most industries are providing,...
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 ...
Most security breaches are from social engineering, and so telling someone that they should never under any circumstances give anyone their password is an attempt to increase security. I would suggest a statement more like:
If anyone asks you for your password, you should assume they are a criminal and report it immediately!
Idea provided by @Kaz
As a ...
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 ...
You shouldn't enforce the characters in passwords. Instead you should encourage passphrases which although longer are more secure and easier to remember.
Instead of trying to explain this, I will let XKCD do it for me:
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 ...
Every constraint you add to a password pattern, the more cognitive load you add to a user. And constrains can be good to make a password secure. But how secure is a password that user constantly forget and as a consequence hit the “forgot password” workflow yet again. Further you minimize the option for users to use there already memorized secure password on ...