Tag Info

Hot answers tagged

151

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


82

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


51

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


46

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


43

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


39

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


37

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

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


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


31

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


31

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


30

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?


30

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


29

Cutting it down to a single step makes the process simpler and better fits existing conventions, so it's probably superior from a UX perspective. Each additional step you introduce is more work for the user. Add in the potential for users waiting between page loads (especially on mobile) and you're really just adding an additional inconvenient step in their ...


27

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


23

Microsoft has a pretty nifty way to solve this: the unmask password checkbox (connect to WiFi in Windows 7, and Vista I think). I really think that's the best of both worlds. I personally don't have people looking over my shoulder 24/7; and neither do most users. Furthermore you can type the password in and simply unmask/mask to briefly check it.


22

A reason that just providing passwords could be problematic is in system administration. By providing only passwords you are making it difficult for the administrator to get a handle on the account. Thus while each account may have an account number, the admin won't be able to easily relate that to a user. e.g. User: "I have a problem with my account" ...


22

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


22

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:


20

It's an anti-pattern that has unfortunately resulted from a legitimate problem: people type in the wrong email address and then after sign up, can't access their account. The problem here is that this solution isn't very user friendly because it's going against conventional interaction (namely, that you can copy and paste from and to form fields). There's ...


20

I like the way Microsoft handles this in Windows 8. There is a single password field, and a button that displays the password while it is held down. That way, the user can check for typos. If the user enters their password with great confidence, then there is no need to enter it twice or look at it, but people who want to see if they typed it correctly can, ...


19

Since you really seem to care for your users and think through your interface, I have one suggestion: Users should never have to manually type arbitrary codes! Instead, just generate a code from a freely available English wordlist: Your activation code is "Large Sinister" Of course, interpunctuation, capitalization and spacing should not matter. Edit: ...


19

Workflow-wise, 1 step is a no-brainer. It's three fields and there's no reason to separate them. You can also nicely inline validate all 3 fields at once; what if my passwords don't match on the second screen in 2 step? Is my old password still valid? If not, that's a pain in the butt. If so, that's a potential security risk! Actually a two step seems ...


19

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


18

The question boils down to "what's the cost of a mistyped password". With some systems that cost is high, and that's why they ask you to retype. For example if you are setting up an account on a (non-free) ISP then being unable to access your account probably involves going through a whole load of identify verification steps with tech support. With a lot of ...


17

The idea behind masking is that someone may be watching your screen (from behind you). (Couldn't find an existing answer with this, even though I am sure I saw it here once, the is the closet I found is Ben Brocka's answer here.) You could let the users elect to unmask or use the same trick used in mobile phones (temporarily unmasking the last character). ...


17

When to display invalid password input? In the case of password fields, research strongly suggests that as-you-type (with short delay) is the way to go. Luke Wroblewski has shared great experiment results answering your very question; Smashing Magazine has also got a good article on this. ...


16

Yes there are examples of how to solve your issue. pwgen has a list of ambiguous characters: "B8G6I1l0OQDS5Z2" (it's in this file if you can read C code). Another code-snippet is here, in php this time. The former approach is using a "blacklist" approach, the latter instead a "whitelist" one.


15

NO. When speaking of either registration forms or comment forms, they are merely common attempts at foiling false registrations, and SPAM. I find Captchas annoying and frustrating. There are many other options: Email verification Multiple choice questions Random addition (comments on WebDesignerDepot) Code Via Text Message (Craigslist) Pictures of ...



Only top voted, non community-wiki answers of a minimum length are eligible