282
Let me try to paint a picture to explain why your comment below is a huge oversight.
Tbh I don't really see any use for the "forgot password" button/link, unless the user put in a wrong password before.
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 ...
164
We should not ask for password twice - we should ask for it once and make sure that the 'forgot password' system works seamlessly and flawlessly
157
One reason why this might not be a good idea is that you would have to enforce unique passwords. This does not seem like a big issue to user experience at first, but from a security point of view, this is critical, here is why:
Enforcing unique passwords means that when a user picks a password there is a chance they accidentally (or with malicious intent) ...
119
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 ...
105
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 ...
103
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.
...
95
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 ...
91
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,...
71
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 ...
62
Good observation.
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 ...
52
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.
A ...
51
It's not uncommon for sites to display password strength (weak medium strong verystrong) next to the password field.
What if you did something like this - but instead display "time to crack", an (arbitrary) estimated length of time for the password to be cracked, together with some commentary.
[password ] Cracked in: 1 minute
You'...
51
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 ...
50
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
You:
Your suggested design will create a security flaw and your system is bound to get scraped for valid usernames
Boss:
Do what I say and tell the magic ...
47
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 ...
46
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 ...
44
Like Roger says, ideally you can reset your password easily and securely, but there are certain times that's not an option.
If you're not validating email addresses it's more important that their login credentials are correct; if they lose their password it might be game over if they entered fake email information.
Assuming you have to have a password and ...
44
No.
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 ...
42
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.
42
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 ...
41
I would say that it is due to two reasons.
The first one you mention yourself, it's an automated process. It's easier to perform an automated process from the beginning to the end rather than breaking in somewhere in the middle and trying to complete it. In other words, it may take a user less time to write the entire password than the last third of it, ...
41
If you choose to have a password only log in, you will run into many problems.
Security
If you only require a password, you have no way of knowing who it is that you are logging in unless you enforce unique passwords. In that case, if I were to sign up and tried to use a common password (say "Password") and your system told me that it was not allowed, ...
41
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 ...
38
There's nothing MORE ANNOYING than dictating me (a user) what password I should choose. I good example of such annoyance is this site's log-in system.
Although there are benefits of automatically preventing passwords such as "123456" and "password", here's my reasons against forcing super strong passwords:
Unless your system is something that a user has no ...
38
This article by NNGroup actually covers this exact topic.
http://www.nngroup.com/articles/form-design-placeholders/
To summarize:
WORST:
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 ...
37
A system should not store the user's password in retrievable mode. This could be done adding salt (a meaningless string of letters and numbers, which doesn't change) and then hashing the whole string before saving to a persistent storage.
When the user signs into the system, the same route is taken to make sure that the password is correct. (password + salt)...
35
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 ...
35
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 (masked/unmasked) and ...
35
NO.
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 ...
34
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?
Only top voted, non community-wiki answers of a minimum length are eligible
