UI/UX x Security — possible?
Oftentimes, we heard/read that security and UX don’t (and can’t) go hand-in-hand because security kills all the fun and creativity. However, is this really true?
How secure an application is depends on the application as a whole and this includes how information is being displayed on screens and/or the screens flow for each feature. But this does not mean that the application has to sacrifice on the sleek and sexy design and/or fun and interactive UX!
What do we mean by that? Read on more to find out! 😎
Disclaimer: Team Merlin is not a UI/UX expert, thus, the examples mentioned in this article may not be the best from a UX perspective. Our focus is more on the security side of things, feel free to rephrase/redesign those areas mentioned.
1. Reduce the message variations within the application
We know it’s very tempting to provide clear and informative messages to users so that they know what exactly happened (because #user-centric yo~). However, this also helps malicious users to understand what went wrong easily.
Take, for example, the error message(s) shown when login failure occurs for:
- Incorrect username/userID and/or password entered
- Non-existing username within the application entered
- Locked account credentials entered
- Inactive/expired account credentials entered
Typically, the error messages in most of the applications will be as follow:
Collapsing these four error messages to just one — “Login failed. Try again, or reset your password.” — reduces the risk of hackers farming for information (e.g. valid user id) from the application response.
Another example is requesting for a password change (which usually asks for userID that is, preferably, not an email address). Upon requesting success, the message to be shown to the user should be “An email with the information has been sent to you.” instead of “The change password information has been sent to m*****@gmail.com”.
2. Notify users before and after logout
Regardless of what kind of application it is, there should always be some ways to inform users why they got logged out from the application. Logging users out could be due to the following reasons:
i. Session timeout due to inactivity/idling
This happens when users are logged in to the application, but don’t perform any transactions such as retrieving data or form submission.
When idling occurs for more than X minutes, show a popup message on the (X-Y)th minute asking if s/he’d like to extend/ end the session. If s/he does not react to it in time, log him/her out with another popup.
“There are too many popup messages to be shown to users and this can be irritating for them!” — this may be a concern for some designers, but hey~ everyone likes to be informed when something happens right? Besides, this has fewer steps for users as compared to having them re-enter their login credentials (and some even require 2FAs), isn’t it? 😉
ii. Login detected from another/unknown browser/device
No matter whether your application allows multiple concurrent sessions to happen or not, it is always good to let your users know where all their logins are happening (other than the one they’re currently in).
Some applications disallow concurrent sessions and typically there will be a message popup showing something like “Due to security reasons, you have been logged out.” when it happens. This is a good idea but it could be better. By showing this popup message alone, the users have no idea why. Our recommendation would be to send users notification emails on top of the popup messages mentioned in (i).
The email has to contain the following details and actionable items:
- Device/browser details (e.g. Google Chrome Version 89.0.4389.114)
- Location (i.e. the country)
- IP address
- Operating System
- Date and time of occurrence
- A link/button for users to either review all the active sessions or terminate that session
With this additional email notification sent to users, we provide warnings to them should there be any unintended access elsewhere, thus reducing the risk of unauthorised access.
3. Enforce changing of password upon initial login
After users have registered with your application successfully, verification emails should be sent to them and the emails should contain either of the following:
- Temporary password and the change password link, or
- Only the change password link (recommended)
When they click on the temporary link in the email or log in to your application with the temporary password, they must be directed to the ‘Change Password’ screen (or whatever your application calls it 😊). By doing so, it helps to reduce the risk of users using the default or system-generated passwords that are weak. Of course, the application should already have the OWASP password requirements check implemented!
The security of an application is not solely about how secure your system architect, code, and third-party libraries are; having flawed UI/UX creates opportunities for security vulnerabilities to creep into the application too.
We hope whatever we’ve shared in this article has provided some insights to how you can further improve on your current UI and/or UX design. If you enjoy UI/UX-related security articles (like this), do let us know so that we will continue to write such content!
- Merlin 💛
