Putting in my own two cents because of one issue that has not yet been mentioned. In particular, I agree with what @NickSloan has said, but with one more caveat.
There is one more important difference between an API key and a password. API Keys are unique to your site. The part that make password security so critical is password sharing. If someone gets a hold of the password that a user saved on your site, it isn't just your site that is compromised: it is every other site that the user used that password (and email/username) for. Many people reuse passwords across critical sites: banks, social media, email, etc, which means that good password security isn't so much about protecting access to your site as it is about protecting your users on other sites. We can't force users to do security better, so we have to assume the worst and take extra steps for them to protect their own privacy.
An API Key is a completely different scenario because it is unique to your site. As a result, if it is stolen, the attacker gains access to your site, but gains nothing that they can leverage against that person's bank/email/etc. This means that the risk level for API keys is actually lower than that for passwords. They aren't quite in the same ball park: API keys are more akin to session identifiers than passwords.
Understanding that these are more akin to session identifiers than passwords gives some practical insights into how to properly protect such keys. Note that the following discussion is applicable to API Keys for things like OAuth credentials, and not encryption credentials (as discussed by @NickSloan in his answer).
The biggest threats to passwords are phishing attacks and hacked databases, which is why we store them hashed in our databases. The biggest threats to API keys are the same as for session keys: weaknesses in front-end applications such as XSS vulnerabilities, MIM, and the like. It's important to note that the front-end application needs the password in unencrypted form, so hashing the API key doesn't really gain you anything when the person who is most likely to have it stolen needs it in plain text.
Instead, you protect a session identifier (or OAuth token, or client-specific API key) primarily by keeping track of the client. If a session identifier get stolen via XSS or other means from the client, a typical result is for that identifier to be used by the attacker on a new device. That means that all of a sudden you will see an old key coming up with a new user agent. Such a change is easy to detect and fix: immediately invalidate all API keys. Especially in the case of OAuth requests, this is very painless for the user: they just log back in and immediately get a new one, while someone who only stole the key (and doesn't have the password) is back to the drawing board.
This is a common enough defense measure that a smarter hacker will also try to record the user agent associated with the stolen key and use it in all future requests, but you can still easily see something fishy going on when the same user has requests coming up from multiple IP Addresses. Like everything else in the world, this can be a bit of a cat-and-mouse game, but there are some important take-aways:
- An API Key/OAuth Token/Session ID is really just a way of remembering a user on a particular device, so they don't have to put their password on every page. As a result, when in doubt, you can just kill all authorized keys and force the user to log back in.
- In all three cases, since losing Key/Token/ID leads to an account being compromised, it is important to have some active security around these things and detect/respond if anything fishy happens. If you've ever gotten notices from facebook/google/etc about someone trying to login to your account from Mexico, it's because a security guy somewhere is doing their job right.
- The primary attack vectors for Keys/Tokens/Ids are different than those of passwords. You may still want to hash them in your database (again, we're not talking about encryption credentials which need to be in plain text), but you can't just hash them in your database and call yourself secure. You need to make sure and secure them against a whole new range of attack vectors. If you think of them as passwords only, you'll miss some important parts of the big picture.