There are a multitude of sophisticated third-party solutions to authentication. Facebook, Twitter, and Google all offer competent solutions. Don't like those? Use BrowserID.
Integrating any of these is actually quite a bit easier than rolling your own solution. It reduces hack risk, provides a better experience for your customers (what was my password again?), and almost certainly will be more reliable than your website.
OpenID and OAuth really did a lot, but there's just nothing called "don't use passwords." Fingerprint readers suck. Anything biometric that doesn't suck costs too much, and 99% of people don't have them. A good KDF is not bad in comparison to a centralized authentication server considering other factors.
Someone, somewhere will be storing user passwords/digests for the foreseeable future. And they will do it incorrectly.
Sure, but the number of those people should become vanishingly small over time.
HN is full of web developers rolling unnecessary username/password solutions. The fact that this is such a hot issue - as opposed to esoterica like TCP frame size - shows that far too many developers are homebrewing solutions rather than outsourcing.
I agree, but "outsourcing" includes using libraries written by people who know what they're doing. (And not using libraries written by people who know what they're doing, but which are the wrong tools for the job.)
This naively assumes that your entire userbase uses those services and would like to attribute their Google (et al) account with your service. This may not always be the case.
Someone has to store the passwords, it would be good if there was a way you could be assured your data at rest was safe.
If you believe your userbase will object to Google/Twitter/FB, use BrowserID.
Personally, I never feel particularly secure when typing passwords into text boxes on random PHP forms. On the other hand, I feel fairly confident that the folks at FB, Google, Twitter, and Mozilla know how to store a password and secure their infrastructure.
On the other other hand, I don't really like the idea of 1) tying all my accounts to Google (what happens when I want to get rid of my Google account? Or my Google account gets locked?) or 2) having Google / FB be aware of other websites I log into,
What's the browser support level of BrowserID at this point? How does BrowserID transfer between the different browsers I use? Can I log in using BrowserID on my phone?
It's good. I use it (dual-auth with FB) in a production system (https://www.voo.st/) and it works great from every browser I've tried so far, including iOS and Android.
The biggest UX issue is currently the up-front email roundtrip for new accounts. In the long run this experience will improve considerably when primary identity providers support the protocol directly. In the short run it's still not bad.
There are a multitude of sophisticated third-party solutions to authentication. Facebook, Twitter, and Google all offer competent solutions. Don't like those? Use BrowserID.
Integrating any of these is actually quite a bit easier than rolling your own solution. It reduces hack risk, provides a better experience for your customers (what was my password again?), and almost certainly will be more reliable than your website.