Apply key stretching to your login passwords, e.g., /etc/shadow. Unfortunately, this makes easier denial-of-service attacks with remote ssh logins by spamming a server with password attempts, each which consume considerable CPU to test and reject. How can this be avoided?
Easiest is proof-of-work (e.g., Hashcash) submitted by each client for each password validation attempt. Client requests with more Hashcash can preempt currently running validations. Clients also need a way to query the current queue to know how much Hashcash to submit to aim for the front of the queue to be able to log in when a DoS attack is in progress but not waste time computing Hashcash when there is no attack happening. Even this scheme may be insufficient against a distributed denial of service attack (DDoS).
Harder is for the password validation computation be done by the client. I do not know how this could work. The delegation capability of Makwa might be useful.
Asymmetric key (e.g. RSA public and private keypair) logins do not have to do an expensive hash a password, at least not on the server side.