1. A Correction To Last Tuesday’s Post

In Off the Record: Passwords, I recommended the use of SHA1 rather than MD5 hashes when storing passwords. Since then, I have encountered a persuasive argument in favor of abandoning both of them and using bcrypt instead, as it’s designed to be less time-efficient, thus dramatically reducing the number of potential passwords that a brute-force attack can attempt in a given amount of time.

As this can make your passwords much more secure against attackers while still keeping single-hash generation running at a reasonable pace, I have revised that post to recommend the use of bcrypt over SHA1 where available.

2. I’m Not Disappearing

New posts to this blog have slowed down substantially over the last couple weeks because the stockpile which I prepared prior to launching the blog have all been published and my new writing process, which I expect to work out much better in the long run, is taking longer than the old one to produce completed posts, ready to publish. If all goes as it appears that it will, the rate of new posts should pick up again by the end of next week if not sooner.

Although I didn’t say a word, I just about died on the spot. Although he wasn’t aware of it, he now knew the PIN for my bank account!

Granted, I should have known better than to reuse a PIN (and I do know better now!), but it’s a very common practice nonetheless, especially as the number of PINs and passwords that each of us needs to keep track of seems to be increasing daily.

Back To The Present

More recently, there has been discussion on the debian-user mailing list of ways to log the passwords entered on unsuccessful login attempts. While this seems innocuous at first glance, and an effective way of seeing what passwords are being tried by brute-force attackers, it will also catch passwords entered incorrectly by legitimate users. These mistyped passwords will generally only be off by a letter or two, thus giving anyone with access to these logs the ability to much more easily guess the correct version.

Despite the potential advantages in being able to revise your password requirements to improve their strength against the latest dictionary attacks, the issue of password reuse remains. These kinds of system logs are generally locked down well enough that they’re only accessible to system administrators whose legitimate powers are broad enough that knowing other users’ passwords will not allow them to do any additional damage locally beyond what they can already do using their own account, but granting them knowledge of others’ passwords also potentially allows them to impersonate the user on other systems.

Trusting them with this information is not necessary for them to perform their legitimate duties. It allows them to do additional harm, but does not expand their powers for good. Therefore, it should be kept from them and any security-conscious sysadmin or developer should recognize this. (Personally, I have, on several occasions, cut off users who were about to tell me their passwords and explained that I would not allow them to do so.)

Avoiding Password Leakage

To maintain secrecy, user-entered passwords should never be recorded in plaintext. I can’t think of any situations in which there would be a legitimate need to be able to recover an actual user password, but, should such a case exist, there are plenty of good, reversible encryption methods which can be used to store it, safe from prying eyes or casual glances.

The proper and generally-accepted method of dealing with passwords is to pass them through a non-reversible cryptographic hashing function, such as SHA1¹ bcrypt², then storing the hash rather than the password itself. Use of reversible encryption would still leave the password vulnerable to anyone with access to the encryption key and the will to use it. A SHA1 bcrypt hash allows you to determine whether the entered password matches the correct password without ever knowing (or being able to know) what the correct password is.

Afterword: Honeypots and Testing

I did mention, above, that there are potential benefits to being able to see what passwords are being attempted by attackers. If this information is needed, it can be obtained without compromising the security of your actual users’ passwords by setting up a honeypot system with no valid user accounts (or at least none which accept password-based logins over the network). Since no legitimate logins will be attempted, you can safely record the passwords without giving away information about legitimate users’ accounts.

The other situation in which I’ve seen it suggested that it is appropriate to record passwords is when testing or debugging software under development to ensure that input (including the password) is being received and processed correctly. Safeguarding actual user credentials is again easily done by means of not having any actual user data (or at least not any actual passwords) in the testing environment.

² Shortly after making this post, I ran across this article, which makes an excellent case for using bcrypt rather than MD5 or SHA1. If a bcrypt library is available in the environment where you’re operating, use it. If it’s not available, see if you can get it added.

Incorrect Validation Is Worse Than No Validation

A recurrent question I’ve seen on a couple different programming sites is “What regular expression can I use to validate an email address?” They’ve gotten a lot of responses explaining ways to examine an email address and reject it if it’s “invalid”. The only problem is that every one of them that tried to be more restrictive than just checking for the presence of an “@” was wrong.

The most common flaw was failing to accept “+” in the local-part of an address, causing many perfectly valid, deliverable email addresses to be rejected. There were also several which failed on top-level domains (TLDs) which were four or more characters long, such as .info or .museum.

On the flip side, there were users accustomed to using disposable email addresses of the form username+foo@domain.com or with addresses automatically generated from their surname of O’Malley - including the apostrophe - complaining about sites refusing to accept their “invalid” (but syntactically correct and perfectly functional) email addresses.

Rejecting these addresses may only shut out a percent or two of the world, but is that really an acceptable cost to pay in an attempt to shut out truly bogus addresses? Particularly given that…

Valid Does Not Imply Correct

Let’s say that you’ve managed to find yourself a perfect validation algorithm which is 100% accurate at determining whether email addresses are syntactically valid, even for the O’Malleys. You’re getting only good email addresses, right?

Wrong.

abcde@fghi.jkl is syntactically valid, but utterly bogus. There isn’t even a .jkl TLD!

“OK,” you say, “I’ll just add a DNS lookup to my perfect validator so that it rejects domains that don’t exist or don’t have a mail exchanger (MX) record defined.”

Still no good. dave.sherohman@whitehouse.gov is syntactically valid. It points to a domain that exists and accepts mail. It’s still no good.

“No problem. I’ll connect to the mail server and validate that the user account exists.”

I can still give you a bad email address. Try president@whitehouse.gov on for size. The account exists, but it’s certainly not mine.

If There’s Any Chance Of An Incorrect Rejection, Don’t Pre-Validate

The only way to authoritatively validate the correctness of an email address is to send email to the address and request that the user respond to it in some manner to confirm receipt.

You may still benefit from doing a preliminary validation to avoid the trouble of sending out mail that could never possibly be received, but this pre-validation cannot reasonably be considered authoritative and should, therefore, only be used to filter out the most blatantly incorrect cases. Attempting to make it more restrictive will only introduce an unnecessary risk of rejecting genuine, correct, deliverable addresses.

The cost of performing the authoritative validation is low and the cost of rejecting an address which is incorrectly flagged as invalid by a flawed pre-validation is high, so don’t pre-validate beyond the point at which you are absolutely, 100% certain that it will not fail anything which might pass the authoritative validation.

Be liberal in what you accept, and conservative in what you send.
- Postel’s Prescription

Previous posts here have discussed reducing the burden of data entry on your application’s users by cutting down on the number of items that they are required to provide and, even if something is required, allowing it to remain incomplete for as long as possible, only enforcing that “required” status when the time comes that it is actually needed.

But what about the values that are entered, whether required or not?

The next step in minimizing the burden placed upon your users is to “be liberal in what you accept”. Do not impose validation rules which must be satisfied unless they are unavoidable. If you really must require them, make sure that the rules themselves are complete and correct.

Don’t Validate Formatting

The biggest, most common, and most annoying case of pointless validation rules are those which impose restrictions on how the user must format his entry. Any programming language worth its salt can effortlessly remove spaces from a string or insert a space after every fourth digit, so there is absolutely no good reason for credit card validations to care whether you enter the card number as “1234 5678 9012 3456″ or as “1234567890123456″, or even “12 3 45678901 234 56″.

Phone numbers can trip you up here, too. Does the program want them entered as (555)555-1212 or 555-555-1212 or +15555551212 or what? The correct answer, again, is that it should accept any of these formats (and more), which is easily implemented by simply removing any non-numeric characters and then adding or removing a leading “1″, depending on whether you want the country code in your database. This will also accommodate international phone numbers, which may have their digits grouped in patterns you don’t expect.

As long as it’s the right set of digits, let the user group them however he wants to.

Remember The Rest Of The World

When I moved from the US to Sweden, I paid my bank a visit to change my address with them. It went reasonably well and their system was smart enough to recognize that, since my new address was outside the US, the “state” could be left blank.

But it still required a ZIP code. Beyond that, it required the ZIP code to be formatted as a string of five digits with no intervening characters. While it does just so happen that my Swedish postal code is 5 digits, they’re grouped “226 47″. Also, the postal code goes before the city here, so we ended up having to enter the city as “226 47 Lund”, with a ZIP code of “00000″. This is obviously incorrect, but it was the only option for satisfying the US-centric validation rules.

Trust the User

Speaking of ZIP codes, ZIP code-to-city databases are pretty nice. They can be great for letting users enter their ZIP code and then automatically filling in a default city for them.

Note the word “default“. The last US city I lived in was Eagan, MN, ZIP code 55122. About half the ZIP code databases out there correctly list 55122 as Eagan. The other half list it as St. Paul, which is a good 10 miles north of Eagan. I knew I lived in Eagan, and the post office knew I lived in Eagan, but several websites insisted I was in St. Paul and provided no way for me to correct their mistake.

Looking up data instead of making the user enter it is good, but your database will be wrong sometimes. Allow the user to correct the lookup results when this happens.

 
I do have a bit more to say on ways that data validation can go wrong, but that’s a topic for another post. Until next time, what issues have you run into where too-strict or too-lax data validation has caused you problems?

If you’ve done much software development, that statement alone should be enough to have you thinking “concurrency issue” or, more specifically, “race condition”. Given that the application involved both a web-based management interface and a once-a-minute scheduled task to handle accounting, the obvious point of conflict was for the problems to result when an operator submitted an update through the web interface while the accounting task was running.

So off I went to ensure that such a conflict wouldn’t cause issues, then sent the revised code off to the client. He reported back the next day that it hadn’t had any effect.

After looking harder at the code, I came up with a way that this conflict could conceivably have still occurred under some contrived circumstance, eliminated that possibility, and sent it off. Still no improvement.

We went through maybe half a dozen rounds of this before I ran out of ways that the web application and accounting task could conflict, no matter how far I stretched the bounds of probability, and finally took a closer look at the application’s logs. Once I started looking at them as a whole, instead of just records of single users, I quickly noticed that these mischarges came in clusters, affecting several users at once, not random individuals. These clusters also tended to hit right on the hour.

Checking in with the client, it turned out that the specific times when the problems occurred matched up with the times when the per-minute rates changed.

To keep the accounting simple, the application deals with rate changes by closing out each active user’s session, charging it at the old rate, and then opening a new session at the new rate. With larger numbers of users logged in, this process was taking more than a minute to complete. The conflict wasn’t between the web interface and the scheduled accounting task, it was between two (or more…) copies of the accounting task! This also explained why I was never able to reproduce the problem in my own development and testing environment, as I had never simulated enough concurrent users in my tests to produce the problem.

Once the correct culprit had been identified, it was a simple enough matter to resolve by adding a check to prevent multiple instances of the accounting task from running concurrently.

The moral of the story:

Even if the cause of an issue seems clearly obvious, don’t forget to fully examine the system to verify that you’re solving the right problem before you spend too much time solving the wrong one.

I’m often surprised at how readily people will forget this.

In late January, I ran across a question on LinkedIn which related to a website the asker had developed which was 100% AJAX-driven. The site itself looked nice enough, but it was a disaster technically. Unless JavaScript was enabled, it didn’t even display its front-page content, just a (non-functional) navigation bar.

With JavaScript on, the content did appear, but it turned out to be nothing more than a standard six-page site which could have been done statically with plain HTML pages and regular links to navigate among them without using JavaScript at all. The only thing lost would have been having the old page’s content fade out, then the new page fade in, when you navigate from one page to another.

Yes, the fade in/out is a nice effect. Yes, it looks cool. And, yes, AJAX is a very buzzwordy “Web 2.0″ technology. But it was used all wrong on this site. It added nothing to the functionality or usability of the site, at the cost of making it inaccessible to a substantial segment of potential users¹. If you’re into SEO, this choice of technology also killed that by making the site essentially invisible to search engines.

I’m sure you’ve also seen sites which use Flash, SilverLight, or another “more interactive” technology in a way which does nothing beyond what traditional HTML can provide and makes no use of interactivity at all. Once again, such designs limit the ability of users to access the site and its content, shut out search engines from indexing the site, and add no actual value.

This is not to say that AJAX or Flash or SilverLight or whatever are intrinsically evil, or even suspect, but rather that you need to know what you’re trying to accomplish with your site or software and then choose appropriate technology - and an appropriate use of that technology - to support that goal. Just using technology for its own sake or because it’s the hottest thing at the moment will, in 99% of cases, do nothing to support the software’s purpose and is likely to detract from it.

What’s the most useless (mis-)use of technology you’ve seen lately?

While that may be a good negative reason (”there’s no reason not to”), there are also positive reasons for allowing this:

It makes your users’ lives easier.

Are you perfectly organized at all times? I know I’m not.

Requiring that saved data must be complete and valid (or at least valid-looking) at all times demands perfect organization from your users. It makes them collect all of the information you want up front and have it all available at the same time when they enter it. Removing that requirement means that they can enter as much as they know right now, then find the rest and come back later to finish.

It provides a record of user actions which were started, but not completed.

Suppose you have an online store for which users go through a series of three pages in the course of placing an order. Do you persistently store the partial data at each stage of the process or do you just keep it in the active session and write it all to the database at once when the final form is complete?

If you’re smart, you’ll make a permanent record of it at each stage. This information about what items a user started the purchase process for, but didn’t actually buy, can provide valuable insight into buying habits. If you’re using a recommendation engine (”people who bought X also liked Y”), then information about what users almost bought is almost as valuable as information about what they actually bought.

More importantly, though, this incomplete transaction data can highlight issues with your site’s effectiveness. If 90% of your users are starting a transaction, but abandoning it after the second step, then perhaps you should take a hard look at the third step (and, while you’re at it, make sure that the server is completing step two in a timely fashion) to determine why they’re not continuing at that point.

Incomplete or invalid data can show what mistakes your users are making.

Users will make mistakes and they will submit invalid data. That’s as inevitable as death and taxes.

Most software ignores invalid submissions, beyond throwing it back at the user along with an error message.

If yours saves it anyhow, though, then these invalid submissions give you a window into your users’ experience that will show you what mistakes they’re making. Once you know what mistakes are being made, you can attempt to determine the cause of the mistakes and make it easier for the users to get it right the first time instead of just scolding them for doing it wrong.

Like the data I’ve been talking about, I’m sure that this post is also incomplete. What other benefits or drawbacks are there to saving partial or incorrect data instead of rejecting it?

This is the wrong approach. As application designers and developers, we should be minimizing the effort we require from our users, not adding to it.

I recently encountered a blog post on Rethinking the Comment Form which, among other things, suggested that there’s no reason for a blog comment form to require - or even request, really - an email address unless the user requests to be notified of additional comments. This is a step in the right direction and provides my first principle for minimizing requirements:

If you will never use the information, don’t request it.

In most cases, that can be expanded slightly to “if you will never use the information for the user’s benefit“. If your only use for the information is to sell it to spammers or “marketing partners”, that doesn’t count.

The second principle expands slightly on the first:

If you won’t use the information immediately, don’t require it.

The first was pretty conventional, at least if you’re not talking to marketers. The second is a bit bigger of a step. It means that, if you’re not going to be sending someone postal mail today, then it’s perfectly OK for them to enter an address with no ZIP code. Or a phone number with no area code.

Yes, yes, I know… “What about data integrity?!?”

Which is a good question. What about data integrity? If you’re not going to use the information yet, then why does it matter? Sure, you definitely do need to get that ZIP code before sending them a letter, but, until you have a letter to send? So what if you don’t have it?

This then leads to:

Even if you do need the information, accept its omission.

Let the user leave it blank. Really. You can remind them each time they log in about important information that needs to be completed, but there is no excuse for refusing to let users enter partial information now and then come back and finish it up later.

The only potential exceptions are a username and either a password or an email address (so you can send them a password). This is sufficient to allow them to return and provide whatever other information may be needed at a later time.

Of course, if you use the email address as their username, then that leaves exactly one piece of required information. You can’t get much more minimal than that.

Do you have any other suggestions for good ways to minimize the load on your users of providing information?