This post will be a bit different than some of my other ones, much
less technical with a focus on what it takes to create a quality user
interface for a web application. The impetus for this is recent
experiences I have had with several web applications. Let's start
with the disclaimer that what I look for and what is important for me
in a web application is different than what matters for other folks,
suffice it to say I want security, convenience and an intuitive
interface. For the security professionals reading this we know that
security has an inverse relationship to convenience, the more secure
something is, the less convenient it is... 99 times out of 100. And
it really is challenging to make that 1% cut. This post will cover
some of the epic failures and provide some ideas on how to approach
the 1%.
A little background for the layman... The web
application/interface this blog will discuss is something seemingly
simple like the login page for webmail or the account setting page
for your online banking website. However the topics presented will
lend themselves to any website that asks you to create an account;
which usually includes the requirement to setup some type of
username, password, Q/A and provide an email address as well as other
personal information.
For me the account creation process is
sacred
important and is like the handshake of the company presenting the
website. A simple process that works the first time and accepts my
19-103 character password without client-side scripts being required
equates to a firm two pump executive handshake that I can be happy
with. The converse would be a website that complains about the
special characters I have chosen, neglects to tell me specifically
which characters is can't handle, then errors out once I remove all
of them because the password is too long. Thanks for the sweaty dead
fish of a handshake.
Lets mention the client-side script conundrum. Flash and
javascript are often employed to try and make the interface look
nicer (simply put) as well as provide convenience and to a lesser
extent attempt to provide a security control. Here is a typical form
used for account creation:
Without javascript
enabled the form will simply not work:
There is no
captcha image
The form is
missing the email confirmation box
The form is
missing the password confirmation box
The “Create
account” button requires javascript
Enabling javascipt
and going through the motions we end up with this:
With javascript enabled we can see that the form in question is
doing several things right. The requirements are clearly being
communicated for the most part (we can only guess what “Nonstandard
symbols and characters" are), the minimum length is a bit short, but
it also does not allow some easy to guess passwords or portions
thereof and last but not least there is everyone's favorite...
CAPTCHA. However the epic fail comes in the form of an inability to
paste in my password and this is why.
Best practice dictates that every website you login to should be
done so using a different password. Let that sink in if you are not
nodding your head. To put this in perspective I will share the fact
that I have over 100 different accounts spread all over the internet
and each one has a different password. In today's world it should be
an expectation that you will need to use a password vault of some
sort to not only store your passwords for you, but aid in the process
of complex password creation. This is where the copy and paste
concept comes into play; yes I have over 100 different passwords but
I don't actually “know” what any of them are. When registering
for yet another account I simply use a tool to create a complex
password for me, then I copy the newly created unique and complex
password, and paste it into the input field on the website. To get
back on topic lets look at the source code to see what is stopping us
from pasting in a password (and email):
In case you missed
it:
Javascript is what is preventing the copying or pasting into or
out of the email and password fields. But if you recall javascript is
required to be enabled for the interface to even show the “Re-enter”
sections of each input. So turn off javascript and the form does not
work, (probably only 1% of the humans visiting the site have
javascript disabled so no big deal right) allow javascript to execute
and you are prevented from copying and pasting in your password. Of
course a proxy like ZAP or plugin like tamper data will let us get
around the restriction and still submit the form while copying in the
password, just mentioning this for thoroughness - there is always a
way around client-side controls.
Lets take a quick
look at another interface.
Above there is a form as it looks without javascript enabled.
Enabling javascript does not change the look and the user is able to
simply sign up with only three fields required. A password of less
than six characters will cause an error. Two-step verification (not
show on this page) is an option but not required. Best of all no
CAPTCHA, this is a winner from a user perspective. From the
development/administration side I can see this form getting spammed
by bots trying to create thousands of account a day. But without
looking at the server-side source code I can't say for sure as there
are plenty of other ways to thwart bots, CAPTCHAS are not the only
solution, they are just one of the more straight-forward methods.
Using flash or javascript to display a password strength meter is
a nice touch in most cases and using transparent methods to determine
if a user is a human versus a robot/script is always preferable to a
CAPTCHA. Determining the best solution comes down to knowing the
target audience and in some cases regulatory requirements or direct
user feedback will dictate the features and functionality of the web
application. Another driving element in determining what
functionality to introduce to the application is the sensitivity of
the information the application houses. It's interesting that Gmail
provides two factor authentication as an option and then parses
(reads) email to provide more targets ads while the majority of
banking websites don't even support two factor authentication. Keep
in mind that an application that requires a password and security
question to authenticate a user is an example of the same factor
twice: Something the user knows. Presenting the same factor twice is
not two factor authentication.
Creating a convenient and secure interface can be a balancing act,
as a developer you don't want to alienate users or limit security
functionality. As a user I don't want to be inundated with questions
and restrictions. It's important to understand what equates to
security functionality too, for instance asking for an email address
so that password resets can be sent to it is bad practice. Providing
the ability to support out-of-band authentication (like SMS, a phone
call, a token, biometric solutions, etc) in addition to a password is
better security, enforcing/requiring the user to use the second
factor however is less convenient. Ideally the web application would
employ true multi-factor authentication that is transparent to the
end user... not an easy task.
To sum it up we need to take a step back and realize that we are
responsible for securing our own accounts, the web application is our
partner in this effort. For all of us users out there we need to use
the options the application affords us to increase our own security,
for the application developers out there we need you to implement
quality controls in a convenient way, and make sure you let folks
copy and paste into the password field.
