Web Application Interfaces

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.