Hacker News new | ask | show | jobs
by rafram 356 days ago
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.

5 comments

> 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.

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.
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.”
Thanks, I agree.
Yeah. Same thing with AI.
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.
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 system was probably designed 30 years ago, and small businesses continue to use them. Happened to me as well.
> 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?

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.

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.

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 unironically smell a conspiracy here.