Hot answers tagged security
148
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) ...
77
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 ...
72
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 ...
59
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.
43
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
...
40
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, ...
38
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 ...
28
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 ...
28
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
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 ...
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"
...
21
I worked on a very similar project to yours where users could only view the content based upon their access permissions. Though the initial reaction from the stakeholders was to just show content, to which the users had access, there was also feedback that users might have wanted access to specific content. Thus, hiding unauthorized content would have lead ...
21
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 ...
21
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
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 ...
19
Number 1 is one of my pet peeves... especially because I tend to immediately confirm my email, so the flow for me is fill out form > check email/click confirm > return to site as authenticated user. If, after doing that, I have to log in again, it drives me up the wall! At the very least, allow your users who are confirming their email address in the same ...
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 ...
14
I have found that most web literate users are familiar with the concept of a CAPTCHA, but most are not familiar with the term "CAPTCHA". Even my parents (who are not web savvy) understand the idea of "enter these characters to prove you're a human" -- however, they wouldn't understand the headline. I would recommend something more straightforward: "Please ...
13
Interesting idea, let's analyze its parts.
EDIT: I'll state outright that I'm not really a fan of the idea for the reasons kontour stated (enforcing unique passwords exposes existing passwords to new registrants).
n-factor authentication
As others have alluded to, the trend in security has been to increase the factors required for authentication. It's ...
11
While some internet marketeers have stated that the appearance of being more secure can have a measurable effect on sale completions, I doubt that this would matter for sites that aren't directly selling something.
You also have to keep in mind that HTTPS connections are slower than HTTP, and so people will likely find your site slower. Amazon found that ...
11
If I remember correctly the reason is because the share button allows tracking of users since it's served from facebook/twitter/gplus.
So without you clicking on it they already know you are on the site. A two click control gets rid of the tracking while making a inconvenience for the user.
Heres a description of the issue
10
Letting users log in from the front page (or any page) is certainly more user friendly. It's always jarring to be taken away from the content or tool you want access to.
Smashing Magazine recently released an article suggesting this as well.
You really should make sure that the login pages are secure, but why not make your whole site secure? If you only ...
10
Wikipedia says "People are notoriously remiss at achieving sufficient entropy to produce satisfactory passwords." (http://en.wikipedia.org/wiki/Password_strength#Human-generated_passwords)
A password meter isn't very reliable, either. They typically have rules that stop me from using very good passwords (a long, randomly-generated of lower-case letters, ...
10
An interesting article about making usable and secure passwords suggests that password based on sentences with 3 or more words such as "ths is fun" are ten times more secure than cryptic combinations of numbers and letters such as "J4fS<2".
I think the root of the problem is that passwords such as "J4fS<2" are hard to remember for users, so they get ...
10
Good Design
In general, having a well designed site will give a sense of security. If the site looks like has been thrown together in a couple of hours, it is not going to inspire much trust in the user. Compare the 2 sites below, which looks more trustworthy?
Trust Icons
You can also increase the appearance of trust by adding icons related to security. ...
10
There are many valid reasons to limit username format.
Uniqueness. If you allow multiple character sets, you can end up with names that look exactly the same, but are technically different. For example, many Cyrillic script characters look exactly the same as Latin characters but are in fact different. "Нarry" and "Harry" aren't the same word, even ...
10
Here's the goal of a CAPTCHA from Wikipedia:
These tests are designed to be easy for a computer to generate but
difficult for a computer to solve, but again easy for a human.
The CAPTCHA you are referencing is easy for us to understand and far easier than the path that static CAPTCHAs have been going down:
Imagine the difficulty a person with poor ...
9
I'm going to give some advice from a Security standpoint + UX. I wouldn't sacrifice either one for the other. Have both.
There's an important question of secure practices in your question. The Best Practice from a security standpoint is to not identify which entry was invalid, and have a generic answer. Let's ask What Would Google Do and take Google's ...
9
Generally, I would:
show / hide content based on user rights
enable / disable content based on availability dependent on everything else.
If a user has no rights to see something, security dictates that they should not even be made aware of its existence.
Is a user does have rights to see something, (s)he should always see it, but it may be disabled if ...
9
Updated
I've updated my answer (a) because I realized that the OP's suggestion ("disabling" rather than "hiding" links) was quite different from the rule we faced; and (b) to say that the big problem we faced was not because we were told links should be hidden in certain situations, but because of a blind across-the-board rule.
We went through a related ...
Only top voted, non community-wiki answers of a minimum length are eligible
