logoalt Hacker News

raframyesterday at 3:49 AM5 repliesview on HN

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.


Replies

pipesyesterday at 6:29 AM

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.

show 1 reply
motorestyesterday at 4:19 AM

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

macNchzyesterday at 12:13 PM

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.

echelonyesterday at 4:00 AM

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

show 3 replies
nwienertyesterday at 8:27 AM

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.

show 2 replies