Josh Kemmerling talks about how to use JSON web tokens to authenticate API requests of other applications that have previously received permissions.
Rising awareness and willingness to address issues with Enterprise Software, the popularity of UX in the health care industry (HIPAA) and frequent hacks of personal private information online have led to a fear-fueled pattern when it comes to site security. Be not mistaken: fears are valid and loss of sensitive information could lead to much more than bad PR for a company. There are many real instances that could lead to substantial fines even if a company does not ever even “lose” information.
The pattern is that companies are taking their responsibility of being a secure resource for their users and simply passing that burden and liability back onto their users by creating overly-complex layers of access. This in turn limits the users' ability and desire to function with the service at all. These companies are rendering their software so secure that even the intended users are unable to access it.
Below are five ways to frustrate your users via security.
1. Implement extensive password rules
I understand the concern at a high level: "We don’t want people’s passwords to be hacked easily.” The issue with passwords, though, is this: on average, we each have about
that require passwords. Your users are naturally going to use a convention that fits with the
they plan to type in on that same day. If you stray from that convention and force your users to make their passwords more difficult, you are making it harder for your users to get to you when they need you most. Lastly, even without more complex rules,
is the number-one request for services that don’t have single sign-on capabilities.
Complex password rules make the job of creating a password much more difficult, too. Multiple failed attempts at complex password creation will have measurable impacts to your throughput. Likely, it also guarantees the password will be written down or saved in a place that is far more accessible than just being stored in your users’ brains.
Validation of the requirements can assist the users in first creating their passwords. Also, a password strength meter on password creation notifies users when they are at risk with too simplistic a password. Or, try not making users create a new password at all; allow login and account creation via social media.
The best solve altogether for the user may be to implement two-factor authorization as both a rebuttal and solution to the fear of being hacked. In addition, why have a maximum number of characters at all in a password? If your users are concerned about being hacked, they should be able to make their passwords the first 90 characters of π if they want.
2. Force users to reset their passwords
The problem for businesses is still password vulnerability. The fact is, though, that banks don’t even do this. It is not common outside of Enterprise Software. Much of the rationale for the first issue is also applicable for why this is no good for users. It creates the need for users to write down their passwords on little Post-its and paste them right onto their monitors.
Additional things to consider instead of a password are tokens or biometrics (iris scan, fingerprint ID, heartbeat). If it is Enterprise Software, a USB key could potentially be a better experience. Mainly, try really hard not to expire the passwords, because interrupting users' flow can have devastating effects. In e-commerce, 75% of users won’t complete a purchase if they have to first recover/reset their passwords.
3. Put CAPTCHA — everywhere
I understand the concern to an organization: "We need to watch out for malicious bots.” But oh, the problems it introduces for users. It increases form errors, causes poorer conversion, is difficult and is inconsistently branded (which can make it look like a security issue). Most are not tablet/mobile friendly.
If you need a mobile-friendly version, then reCAPTCHA isn’t awful. An even better solution is the Honeypot, a hidden form field that humans cannot see, but robots find irresistible. The biggest issue I see with Honeypot CAPTCHA is that there doesn’t seem to be a great solve for accessibility, but CAPTCHA in general is not super accessible either so we still need to implement a fix for this part of it.
4. Lock out after X number of failed login attempts
So, hypothetically speaking, a company suspects someone may be trying to hack into your account. However, they may have also made your password insanely difficult for you to remember and also included additional steps for you to retrieve access to your account.
Obviously, I am exaggerating, but I suppose I would be OK with this as long as there is at least a simple software solution in place for me to reclaim access to my account. If you plan to force me to call or email someone to get access to my account, plan on not seeing me again.
Best solve for this is also two-factor authorization.
5. Have security questions (lots of complex ones, too)
First, let me say it just simply is not secure. This is one way all the “unnamed” celebrities' phones are getting hacked. People are guessing/finding the answers to these questions to gain access to their private information.
Make the questions more difficult and random, right? No, not right. My answer to “Who is your favorite cousin's neighbor?” may change between now and when I need it. Also, it will take me awhile to find a question in a list of 10 that I feel I could actually answer later. Users have told me they created workarounds in which they answer the security question with its last word to avoid dealing with the complexity of this feature.
Example: Question: What is your mother’s maiden name? Answer: name
The best solution is to verify a forgotten username or password via another form of contact, like phone or email.
A Bonus Bargaining Tip
If you are currently in talks about site security with your client/company, another thing to consider is the implementation of SHOW/HIDE passwords in form fields. It could have a solid impact on the throughput and usability of your software.
Exceeding users' tolerance to security results in them having to work against you and your security parameters to make the software easier to use. They will do things like write down passwords, use predictable shortcuts to remember answers and reset expired passwords with weak flavors of previously used passwords. Overly-complex security parameters may actually result in less secure software. It's best is to come up with options that are still secure, but don’t simply pass complexity on to customers.