Tag Info

Hot answers tagged

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) ...


116

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


104

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 ...


97

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 ...


91

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 ...


85

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 ...


73

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 ...


61

I'm no UI expert but I think in many cases it is unnecessary. Certainly in my own experience it is rare for me to enter a password incorrectly. A better solution is to not have a password at all. Use one of the growing number of authentication providers (e.g., OpenId, Google, Facebook, Twitter, etc). Why does the user need another password for your app ...


57

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 ...


51

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 ...


48

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 ...


46

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 ...


45

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 ...


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

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.


41

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 ...


38

Don't trim spaces, since some users do include spaces in their passwords. Don't email a generated password. Instead send them a URL with an embedded one-time token, that takes them to a password reset screen. If you really must send a password through email, note that Outlook only adds the space if there is a space after the word. For example, if you ...


38

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, ...


36

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 ...


36

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 ...


36

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 ...


35

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 ...


35

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 ...


34

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 + ...


34

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) ...


34

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 ...


33

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?


33

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 ...


32

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. ...


31

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