Better Auth, by a self-taught Ethiopian dev, raises $5M from Peak XV, YC

Auth is really not difficult to write. It's don't roll your own crypto, not don't roll your own auth. People need to stop spreading this fud.

Yeah it’s not difficult if you know all the specs.

The issue is 99% don’t know them and are not very good at following them. And the cost of error is very high.

I’ve seen a lot of startups that failed to implement even google oauth securely.

So yeah it’s a far cry from fud and you really should not do it unless you are actually good.

What? No!

There are plethora of mistakes one can make in implementing AuthN/AuthZ, and many of them almost immediately will lead to either the direct leak of PII or can form the start of a chain of exploits.

Storing password hashes in an inappropriate manner -> BOOM, all your user's passwords are reversible and can be used on other websites

Not validating a nonce correctly -> BOOM, your user's auth tokens can be re-used/hijacked

Not validating a session timestamps correctly -> BOOM, your outdated tokens can be used to gain the users PII

But given that BetterAuth is an open source project with a large following, and also given that they just got funding so they can hire more help, now we can evaluate BetterAuth's competency in terms of their ability to coordinate help.

None of those things are difficult to do correctly.

Yeah, one would think so. Evidence in the wild shows otherwise.

With 5M you can get white hat audits. Even big boys like Okta have had serious fuckups [1].

[1] https://trust.okta.com/security-advisories/okta-ad-ldap-dele...

Also, as far as I know, they aren't reimplementing the core auth libraries/specs mentioned

OAuth is very complicated and fuzzy though.

I am not surprised anyone makes mistakes trying to integrate it anywhere.

> Storing password hashes in an inappropriate manner

The problem isn't how you store the hash it's how you generate the hash.

So it’s a bad idea, but somehow a guy in Ethiopia writes his own auth and builds a whole company around it and gets $5 million?

Auth is actually really hard, with many really subtle high impact mistakes one can make.

I also ran into this trying to upgrade my company's auth strategy. The hardest part of auth is convincing people that... it's not actually as hard or dangerous as they think it is. It was an uphill and ultimately unsuccessful battle of mine. People can't even divorce JWTs as simple, verifiable json data blobs from the entirety of the OAuth2 spec. You see it on HN, with hundreds of circular comment threads and I've seen it in real life.

Auth, in my experience, isn't actually that hard to write.

OAuth, or any form of SSO, is not something you want to roll yourself.

Crypto is absolutely not something you want to roll yourself.

Plenty of evidence in the wild also shows that programmers in general should never be trusted.

The short answer: Bcrypt with 12 rounds.

Good enough for almost any startup in 2025.

He must be really good at selling lol

Counterexample: Storing the bcrypt hash by appending it to a CSV file containing the usernames and hashes of all users then having a login process where that CSV file is downloaded to the client and the password is verified locally against that CSV file using client-side JavaScript would probably be very bad.

Cryptography part is fine but storage or the auth process isn't.

You would like to think that no-one would write their app that way, but there are plenty of slightly less worse things that happen in practice and vibe coding probably introduces all sorts of new silliness.

Everything in life is hard there.

> Yeah it’s not difficult if you know all the specs.

I don't think this is a valid point. Specs only cover a single responsibility: interoperability. This is not a critical requirement of auth services, unless you have a hard requirement on federated auth.

Yes, people mix up the concepts of authentication and authorization (access control). Authentication can be really simple if you rely on a standard like JWT.

Authorization is what's difficult and dangerous.

I would recommend that people don't do auth not because it's easy to be insecure, it's that auth sometimes needs agility. Auth sometimes needs to grow and adapt just like any other part of your product.

Except that auth might not be a core part of your insurance or tax app, and you'd rather spend your energy on the part of "agility" that has to do with the core parts of your app.

On the flip side I was at a startup using auth0, because as you said, not a core part of the business right? Until the traction hit and they had hundreds of thousands of users. Suddenly the auth bill became untenable - users are great but there wasn’t enough revenue to cover these costs. Auth0 didn’t budge. In fact they were outright nasty to deal with. They were holding our user logins and passwords hostage and they knew it.

You don't have to buy into Okta, you can also lean on auth frameworks like auth.js. Either way you're depending on outside labor to adapt.

I worked for a social media company before and we also rolled our own auth and we didn't regret it. High user accounts are a special case and you should know ahead of time.

But for B2B? Beware. You might get hit with an ask for active directory support.

I'm not criticizing BetterAuth here, but the idea that rolling your own auth is easy.

BetterAuth is likely an improvement against the status quo for many companies if they have already decided to roll their own auth, as it at least already provides pre-made blocks of functionality that are hopefully battle-hardened rather than building completely from scratch.

An improvement if their own approach would be worse than 'get a single self taught guy to roll something out'. If it's roughly the same it shouldn't be any improvement.

Argon2 with defaults. Stronger and easier.

I agree completely, which is why it's enlightening to read implementations of crypto. These are often short, seemingly simple, self contained sections of code that have to be as close as possible to perfect. Even simple things like constant time comparison algorithms are beautiful little crystal palaces of code.

It’s not easy, but it’s not impossible either.

If you’re just a developer who works on CRUD apps all day or never touches a backend then yea you probably don’t have the skills but auth is a solved problem and you can learn to do it right. A team of engineers can definitely put together an auth system.