Passwords shouldn't exist at all. Web services should use OAuth. Oauth providers should use two factor where one factor is a 2048 bit key (Yubikey/Client Cert/etc.). Point to point connections (ssh, VNC, network shares) should use client certificates or centralized auth (Kerberos or active directory).
Scrypt is a bandage which doesn't resolve the core problem - there is insufficient entropy in typical users passwords. If there was enough entropy, the speed of the hash function wouldn't matter.
This is a bit like saying "human-driven cars shouldn't exist: the roads would be much safer".
True, certainly. You're unlikely to get much debate about hardware tokens / certificates / etc being more securable; the reason we still have passwords isn't because they're more securable, it's because their UX for the vast majority of users is much better.
If you're suggesting there's a reasonable path to get from $the_world_today to $the_world_you're_proposing, I suspect that's a more interesting point to make.
I looked into Yubikey but it seems absolutely impractical for day-to-day authentication unless you only use it for a finite amount of sites.
For example, you'd want at least one backup. Maybe buried somewhere or in a safe deposit box. But the workflow for keeping it synced would be hilarious.
Ever since then, I can't take anyone seriously on HN who says "we shouldn't have passwords, just hardware key fobs". Not to mention your authentication security doesn't matter when there's a customer support line an attacker can socially engineer.
Not really. The user only has to wait for the computation once, a few times at most, and it can easily take less time than typing the passwords.
> * Use long secrets (ie. not human-rememberable passwords)
That's very often not the case. Some people like me put truly random passwords on every service. But 99.9% don't.
Also, you can perfectly combine _both_ long keys and expensive hashes.