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


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


80

If a user doesn't have permission to access a particular item of content, I would suggest not displaying it at all. If the user needs to know that content they don't have access to exists - show them the content in a different form and provide them with a way of enquiring about how to gain access if necessary. Eg. as a content list (rather than semi ...


63

Why would this be indecipherable to a computer? Since each word has the correct letters, but they are scrambled, it would seem very easy for me for a computer to crack the correct order of the letters by comparing it to known words. Which defeats the whole point of having this extra barrier. Secondly, how would this affect folks with dyslexia or other ...


62

Ironically, I could not get by myself what bgeigr meant, but almighty Google helped me out: So this captcha is quite easy for computers to guess, yet may be hard for humans. And bear in mind that Google is using an error model for common typos (letters replaced by those adjacent on the keyboard etc.) If you program your computer to only consider ...


61

You're looking at the problem from the wrong angle. A user could also open a different browser, or use a second device, which means you can't rely on the idea of opening tabs(and preventing it), nor on IP address. Your solution needs to be server-side. Signing them out would just annoy them. Either make it so your website show them the same game no matter ...


60

I'd like to take @lazer's suggestion a step further. Why not add a small padlock icon after each of the links the user does not have permission to? Then, if the user would hover the link, I would show them a tooltip explaining that they don't have permission to view the page contents.


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


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


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


45

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


42

On any site is is not ideal to break a user's expectations. As a user expects to be able to navigate the internet with tabs in their browser, you shouldn't break 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, ...


37

You have to go with the first option (stating that the "username or password is invalid"), and this has nothing to do with security. Let's say that I usually use JohnGB as my username, but on your service someone else has that username, so I use JohnGB123 instead. Say I've then forgotten my username and I enter JohnGB as my username, but use my correct ...


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

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

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


35

In general it should improve perception of security, but user perceptions are a funny thing. Consider example 8 on these surprising AB Testing results. In this instance the security seal on the form led to a drop in signups, because the security seal icon was interpreted by some users as a sign they were about to pay for something. The moral of the ...


35

tl;dr A good captcha would need (ideally) to offer the best possible protection (difficult to get for a computer) and ease of use (easy to get for a human). But captchas aren't good at this and "typoCaptchas" doesn't seem to improve them. Questions can be rearrenged quite easily and then if the question is easy enough for people is probably easy enough for ...


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?


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


32

This is not effective for keeping out a targeted attack by someone who uses a word list, such as /usr/share/dict/words, to solve your anagrams. A task like "unscramble the words in standard input, assuming the first and last letters are correct, given a word list file for the language" is probably so straightforward that it'd make a good puzzle for our Code ...


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?


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

From a historical viewpoint, I suspect the reason is simply "because someone thought it would be a good idea". In fact, I did a little bit of digging. The padlock icon for HTTPS links was first introduced to MediaWiki in 2004 as part of the then-new MonoBook skin by Gabriel Wicke. Specifically, it first appears (along with a generic link icon and special ...


26

There are a number of reasons: It prevents someone causing someone elses account to be locked maliciously (if I know your email address and you bank with Barclays I can lock you out of your account by repeatedly attempting wrong passwords). As @AlexFritz indicated it makes it harder to try hacked username and password combinations from other sites on the ...


25

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:


24

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



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