I don't think that storing creds is suitable for newbies either. All authentication is complex and just using HTTPOnly and DB backend is not a solution at all.

I'm generally allergic to "let the Big 5 run your services", but I have to admit that "sign in with Google" looks like a major improvement on "hand PII to whoever tried to home-roll auth".

With a password manager and careful shepherding of your PII, maybe there's not much risk; if someone takes over the site your account is compromised either way, and nothing else is lost. But most people don't actually use password managers, and lots of sites that accept Google sign-in require lots more data to actually create an account on the site. (Plus, losing password stores is not necessarily the same as losing all control.) Newbies storing creds is a perennial source of leaked credentials that get used to attack more important sites.

Depends on what the project is and also doesn't change the fact that this doesn't happen.

Most solo bootstrapped projects are not popular enough initially for someone to spend money / effort to hack them. When they do become somewhat popular though (very small minority of course), I suspect most founders bring experts on board, as they absolutely should.

> just using HTTPOnly and DB backend is not a solution at all

My comment was not meant to be exhaustive and does not list all vulnerabilities. Just in context of some of the suggestions in the article. Using a mature framework like Django can protect you from other vulnerabilities CSRF, XSS, SQL Injection to some extent.

>most founders bring experts on-board

You have way too much faith my friend. How does bringing an authentication and security expert into your organization make you more money? It doesn't. What people like this tell you change is all cost and only hypothetical benifit. I suspect this doesnt happen anywhere near as much as it should.

You don’t bring “experts” on board. Most of them really aren’t. At most, you find a third party trusted managed service.

I work in mostly the B2B space where we integrate with their Identity Providers (active directory, Okta, etc) and strongly discourage them from using our internal authentication system so they have to take responsibility for their own security.

If I were working in the consumer space, I would personally use AWS’s Cognito since that’s what I’m familiar with and it integrates with everything - Google, Facebook, Twitter, Apple, Amazon etc.

I’m sure there are other services that serve similar functions.

Hey, I meant to reply on your other comment asking for third party trusted services.

Thanks for listing some, will look into them!

Auth0 is another.

>Most solo bootstrapped projects are not popular enough initially for someone to spend money / effort to hack them.

Strong contender for Most Horrifying Thing I've Read This Morning.

It's good practice to consider the likelihood of attack in your threat model if you care about the expected payoff associated with your security efforts.

When that threat model necessarily includes bored script kiddies and automated APTs?

Exactly. Like if user privacy does not matter but just cold cash. Thanks to statements like this there is GDPR.

A relatively simple solution is temporary sign in tokens via email. Encrypt and timestamp in the database and pick a TTL (the shorter the more secure, the longer the more convenient). Then just email a login link with the email and token as params. Perform auth lookup on email, then secure compare the tokens (in constant time to avoid timing attacks).

You now have an auth system that avoids horrible passwords (no passwords).

The downsides are: 1) Cost to send emails for login, 2) People complaining about it being weird.

Worth it in many cases.

I think even when integrating a social login, a developer still needs to create a secure cookie and has "user" table in his/her database. Using social login is rather a convenient option for users as they don't have to create a new account.

Sure, but the stored credential is not reusable in another context. Which is not true for the majority of passwords. As a bonus, the authorization is probably also revocable via the external identity provider, although that's more about service-to-service permissions than account compromise.

This is a bad piece of advice. Two things I don’t ever want to take responsibility for when starting a project are user authentication and payment processing. I think I know best practices for each, but so does everyone who has gotten hacked.

I don't disagree with you, but the state of affairs is basically a protection racket. If you sell out your users to Facebook, they'll keep you safe from all the other attackers.

Most frameworks come with their own authentication module. I still wouldn’t write my own.

I get the motivation of what you're saying - but I'm going more towards splitting the back end from knowing too much. Do authentication in a proxy layer (can deploy as a sidecar if suitably containerized) and then have a bearer token between the proxy and the app server. Yes it's a lot of "architecture" for a newby but it generalizes well to the byzantine Oauth cases without requiring too mach app rewrtiting and this kind of service split is pretty do-able given a Paas.

Do you think that registration can include solutions like Github? I am not sure how to handle after. Login with the 3rd party would trigger a http only secure cookie creation and insertion into the db? I want to avoid JWT and co. especially after watching so many videos about the downsides and the potential security implications.

Yes, I'm in favour of using Secure Cookies for authentication.

But, the TDD (Trend Driven Development) people won't agree with them. They want to work with those shiny trends for a shiny resume. JWT is horrible for the web, it need JavaScript, some needs Local Storage, which is worse than Cookies itself, and the revocation is complex.