Lessen impact of DoS attack on cpu-expensive login?

Even without the threat of DoS, unrestricted authentication attempts is a problem in its own right. A common way of restricting authentication attempts at the protocol level is to force a given IP into waiting exponentially longer after each failed authentication attempt.

A cool feature of SSL/TLS is that it allows clients to resume already established sessions, which reduces resource consumption.

(as AJ Henderson pointed out) Forcing the attacker to know a username before consuming CPU on a PBKDF2 hash is a neat solution, as long as usernames are hard to guess. Based on the timing of requests, or more commonly an error message produced, this implementation could be a username enumeration venerability.

Filtering authentication attempts with mod_dosblock, Sourcefire or another IPS/Application Firewall is cutting off the foot to save the body. This technology isn't magic, it sees that there are a large number of one type of request (a login request) and filters them all. In this context, this approach would filter legitimate authentication attempts. This means that the attacker has won using less of the attacker's resources than it would take to consume all available CPU time.

The general form of this login based DoS is an Algorithmic Complexity Attacks or ACA. The root problem of an ACA is that the attacker is able to force the victim into performing calculations at a higher complexity class than the server. When designing a protocol you can force the potential attacker into submitting a Proof-of-Work with every authentication attempt. A commonly used proof-of-work for authentication systems is a captcha! This type of work is very difficult for a computer to solve, which significantly limits automated attempts. Another proof of work could be forcing the client into solving a PBKDF2 of a nonce for every authentication attempt. The resulting hash is the proof-of-work, and can be submitted along with the username/password.

Related:

Defending against Denial Of Service Using Puzzle Auctions.

Price Via Processing Or Combating Junkmail

Check the username (or session identifier) first. If you don't have one in your handshake that is easily accessible, add one. Looking up an identifier is cheap. As long as you don't give away your identifiers, they won't have a large number of valid identifiers to throw at your login or hash function. If an identifier is being used repeatedly, lock it out (or terminate the session if it is a session identifier).