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

"Better Auth’s pitch is simple: Let developers implement everything from simple authentication flows to enterprise-grade systems directly on their databases and embed it all on the back end."

Its absolutely bonkers to me that web development has gotten to a point where this is a novel pitch. Up until not that long ago ALL auth was done directly in your own database and embeded in your own backend. Am I missing something?

Yeah and it was terrible. Your password would be stored as an unsalted MD5 hash if you were lucky.

Enterprise customers did the math on what a security breach lawsuit could cost and started demanding verifiably decent security, which meant some off-the-shelf off-premises solution.

That’s basically where we are now, and it’s the reason that most of Better Auth’s users are early-stage startups — they need to scale quickly, and they don’t have many pesky enterprise/governmental customers who might want to see a certification.

> Yeah and it was terrible. Your password would be stored as an unsalted MD5 hash if you were lucky.

That's so 2001.

Bcrypt was in the default PHP libraries in 2013. It's been available in Python even longer.

This pattern of outsourcing the most basic of application responsibilities is lazy and exposes you to needless fragility and cost burdens.

There are a million and one libraries and frameworks that will handle all of this for you, meeting industry standards, without having to pay to be coupled at the hip to some SaaS vendor that will undoubtedly raise prices on you when they hit growth pains.

You're being rented a partial solution to something that has long been solved. And this - your customer relationship - is such a core function to your business that you shouldn't outsource it.

> Enterprise customers did the math on what a security breach lawsuit could cost and started demanding verifiably decent security, which meant some off-the-shelf off-premises solution.

Not really. What happened is that some service providers started offering managed services, some of them completely for free and snazzy UIs that became de-facto standards. Developers could onboard onto fully functioning auth services in minutes with barely any development work and no service to manage.

Why do you think Google's sign-in flows are ubiquitous?

Yes. You're missing decades of the arms race between hackers and developers that has resulted in a degree of complexity that is too high for someone who isn't specifically trained in infosec.

Web devs use abstractions for lots of things. There's no reason auth should be a hill to die on.

Thanks, I agree.

Yeah, and all the popular web frameworks include authn and authz as a core component.

This is a market created by the supabases and it’s no code cousins. I frankly always considered auth so simple and fundamental, with best practices so well known that I never saw the need to use a SaaS for user auth. I guess if you want to offer all the auth methods that this library is useful and saves a lot of time.

I called my doctors surgery because I couldn't login into their web bookings site. The receptionist said "I'll check your password" then she "oh it's all funny characters" and I realised she was reading my real password that was generated by my password manager. This was only a few years ago.

You mean that for toying, personal use or hobby projects, right? Otherwise people get jaw drops or facepalms.

Absolutely wild take. Auth is most definitely not simple, nor are best practices well known, based on number of auth-related vulnerabilities published.

As someone who has been at a company where for various reasons, we decided to "roll our own auth", I would have to disagree here. Don't reinvent the wheel if you can avoid doing so.

Yeah. Same thing with AI.

What are you talking about?

I was 14 learning PHP in 2003 and every tutorial insisted you salt and use a more secure hashing algorithm.

It’s weird to see people say things so boldly that are so wrong.

The most concerning part about the belief that bootstrappy self-taught hackers are able to tackle any type of problem just as well as experienced engineers with a solid academic background is how the ignore the fact that hacking together an implementation is a very small part of the problem, and actually knowing the problem domain is of critical importance.

This is why we end up with businesses running services where a receptionist has access to customer passwords. Those who designed the system weren't even in a position to understand why that was a critical flaw in the design, let alone a problem that needed fixing.

That is a super refreshing take. When I started needing to add auth to apps (~5 years ago) the only advice I could find on auth was essentially “you are an idiot if you don’t use an auth provider”. Back then I was probably only reading r/webdev or something.

I think it all started when libraries began to be replaced with "services" (I mean this in the broader context, not just auth). Integrations that were once development time or compile time, are now runtime. Two somewhat perverse incentives: developers get to offload some of their thinking (and also maintainence, reliability and scaling worries) to a service, and the service provider gets a perpetual income stream.

That system was probably designed 30 years ago, and small businesses continue to use them. Happened to me as well.

I unironically smell a conspiracy here.

I’ve taken early stage apps through a bunch of security review processes and never encountered questions about the specifics of the auth backend, beyond whether it can support the client’s specific SSO requirements.

These days I tend to favor having auth built-in, via an "old school" web framework that provides an extensible auth system out of the box. Then we’ll extend that system with a managed 3rd party service to handle SAML when that starts to come up in sales conversations, because the setup is annoying and we can lean on the vendor to deal with whatever weird old IdP the client shows up with.

That last sentence is possibly taken from <https://www.joelonsoftware.com/2001/10/14/in-defense-of-not-...>: “If you have customers, never outsource customer service.”

I'm curious about this too. How does this, for example, compare to Django's built-in auth?

That's not how I remember it. There was a lot of

  if (md5($_POST['password'])) == password_col) // success!

floating around in the PHP example code universe.

I guess everyone outside of the JS ecosystem, that has auth baked into the framework for decades, is just doing it wrong and riddled with hackers in their systems?

I need this answered.

Curious as well - based on what I see. This is geared towards the node land vs. python.

I would never suggest "roll your own", but every web framework I have ever used generally has a library that is the go to battle tested auth implementation and just requires adding a few columns and/or tables to your database.

Yeah I spent almost 10 years building Rails apps and we would always just use whatever the most reputable gem was at the time and it always worked out great. Its only after moving into the JS/TS world that this became not the norm.