Chris's Wiki :: blog/web/AntiConfirmationFields

How not to do repeated fields in web forms

January 19, 2012

There's a certain sort of web form which really wants to make sure that you've entered something correctly, so they ask you to enter it twice in two different fields. You've probably seen this in some web form sooner or later; this is the 'please enter your password again in this field too' or 'please re-enter your email address' field. I tend to think that this is bad on its own, but I've now seen an even worse implementation of this basic idea, which I'll call an anti-confirmation field, one that's practically designed to create errors.

What the people behind this did was quite simple: they made it so that their second fields would not accept pasted input (probably using JavaScript, which I had on because I didn't feel like finding out which bits of the registration process required it). I had to retype both my email address and my password by hand, which was especially annoying because I was pasting both of them from elsewhere. I call this an anti-confirmation field because of course retyping things by hand is more error-prone than pasting things in; in fact, I twice made a mistake retyping the password.

(My web password for this site was a strong random password, as usual. Random jumbles are hard to transcribe accurately by hand, especially when they jump back and forth between character case.)

I suspect that the website designers justified this by saying that they were worried about people entering a bad email address by hand in the first field and then 'confirming' it by just cutting & pasting it into the second field. However, even at its best this logic doesn't work for password fields since browsers don't let you copy the plaintext content of a password field once you've entered it. I also suspect that the designers do not have any actual data on how many genuine errors this prevents (versus how many artificial errors are created).

Sidebar: how to measure the numbers

Assuming that you've committed yourself to (anti-)confirmation fields in the first place, you just need to track field values across time when a submission fails because of mismatched fields. In a transcription error the first of the two fields will turn out to be correct (ie, the same as the final submitted value) and the second field will change. In a genuine error the first field will be different between the failed submission and a subsequent valid one.

Doing this with email addresses raises basically no security issues. If you do this with the password field you'll want to one-way hash them somehow in your tracking data.

Comments on this page:

From 72.207.234.233 at 2012-01-20 08:54:49:

I fully agree that javascript hack is stupid. I use a password manager myself and that would be a real pain.

But a confirmation field for a password is a good thing. The field is going to be masked by the browser so it's impossible for people to tell if they've made a typo, making the same typo twice in a row is theoretically unlikely. The rest of the fields are (probably) being displayed in plain text so the submitter can check those over himself.

Also, while doing some tracking to see if this all actually does any good is an excellent idea (and your method for doing so looks right), you might want to take care with the email addresses too--unless your logs have the same access controls as your database (which they well might). You could conceivably scrape a log for email addresses if you had access to it, though I don't know if anyone does that.

From 78.35.25.18 at 2012-02-01 11:41:10:

For email confirmation, the better idea seems to be an interstitial step, after submitting the form, in which the email address is displayed back to the user in large type and they are asked to confirm whether this email address is correct. If not, they get to enter it again. If the email is collected early on in the form and other fields follow, this is a good way to get the user to read their own input with fresh eyes.

For passwords, see Bruce Schneier on The Pros and Cons of Password Masking. On most forms there should simply be a checkbox that unmasks the password when checked. The user can enter their password unmasked or use the checkbox for confirmation.

Either way there is a better solution than making the user type things twice.

—Aristotle Pagaltzis

By cks at 2012-02-01 13:29:43:

I doubt that an interstitial step will do much good. People are very good at just hitting the 'go on' button, and they're going to expect the email address that they just entered to be correct so they're unlikely to read it carefully.

From 78.35.25.22 at 2012-02-01 20:21:26:

Will the result be worse than making them paste it a second time?

—Aristotle Pagaltzis

By cks at 2012-02-02 12:24:15:

I don't think the results will be worse than having them paste it a second time, but I also don't think the results will be more than a tiny bit better than skipping the interstitial entirely.

A better approach is to figure out how to let people recover later from making such mistakes. This is hard (and somewhat application specific), so I don't have any good answers.

By gsauthof at 2012-02-12 03:05:39:

Yes, some web forms use such anti-confirmation fields (where Javascript code tries to get you really type in something the second time).

But what always works for me to avoid double entering information into such form fields (under X11): Open your favourite text-editor side by side, type in the needed value, mark it and middle-click-paste it into each of the two anti-confirmation web-form fields!

The Javascript code does not seem to be able to distinguish such middle-click-paste from typing it in.

Of course, a web form that asks for email/password should be better designed. What should work better (i.e. would be less annoying and more effective) is a registration process, where you have to enter the email address on the first form page, the page sends a confirmation email in the background while it displays the next form page which you can fill out. At the end it just asks for the confirmation link and gives you a possibility to fix your email in case it was mistyped. Once it is confirmed that the email address is correct the site can handle a mis-typed password like any forgotten one.

Written on 19 January 2012.

«	Let's make it official: Solaris 11 is closed source

Another Russ Cox regexp article: How Google Code Search Worked