5 ms·

My biggest struggle with projects right now is how to handle auth. Sure hashing a password and pairing it with a n email is easy in theory, but there are bad a

My biggest struggle with projects right now is how to handle auth. Sure hashing a password and pairing it with a n email is easy in theory, but there are bad actors with zero days for any db/backend I’d want to use and they can practice all they want on my app as it sits on a server exposed to the world 24/7. I’m going with trying out firebase auth for the express apps I’m building now, but this makes me even more inclined to check out go when I’m finished with this latest project.

Rodeoclash 4y ago
I've also been in this space recently and settled on trying Ory which is a kind of headless auth solution. I'm using it in Phoenix/Elixir which lacks an SDK for Ory but it all seems fairly straight forward. I'm using the Ory cloud solution but might dive into hosting it myself at least for local development against it.
- 7speter 4y ago
  Ory looks promising. Can you use the free tier for multiple projects as long as they are low volume?
  - eropple 4y ago
    Hosting Ory isn't difficult, FWIW.
danielheath 4y ago
Security is ultimately a question of cost to attackers. Is their goal of “compromising your app” worth risking you noticing their (valuable, hard to create) zero-day and getting it fixed upstream?
ss108 4y ago
I feel like this is ultra vires? It's a common sentiment now that just hashing passwords is terrible, but we did this at every startup I worked at previously and it was fine. Is it really an issue? For an early-stage startup, almost nobody sees the app anyways lol--we'd all be lucky if we were popular enough to hack For my current startup, my cofounder, who is the CTO, insisted we use auth0, so we do, but it's a pain. It's such overhead. Sometimes it's buggy. There is a lot of stuff we have done and (are trying to do) that would have been so much faster to build if we had just done it my way. I wonder if I am very naive or cavalier about the security risks.
- vinjin 4y ago
  I would recommend taking a look at Stytch. It is a startup that aims to have a simple, customizable way of building authentication. Disclaimer: I work at Stytch.
  - ss108 4y ago
    Thanks lol
justusw 4y ago
Proving the absence of a 0 day for whatever your solution you are using is always going to be difficult. But dwelling in thoughts like this is close to crossing the border to FUD territory. And who says there isn't a 0 day for Firebase auth? We can put our faith in systems that have been hardened over the years and are easy and reliable to implement. And email + hashed/salted password belongs to them. And by that, I specifically mean using a library that takes over the hash/salting part for you. For me, not rolling your own crypto not only means not implementing your own hash algorithm, but also staying off-the-shelf with the code that calls said cryptographic functions. I also like to stay conservative with regards to session cookies vs. JWTs. One has been around for more than 2 decades, is well understood, and has some really solid cross-browser security measures behind it (HttpOnly, Secure Cookie, etc.) I personally like using the Django contrib auth library for this purpose.
- Waterluvian 4y ago
  May I ask a related question? Have you found a good way to do session auth in Django with httpOnly _without_ having to hit the server and see if you get a 403 back? Because it’s httpOnly I cannot know client side if I have a session cookie until I try and fail once.
  - colinclerk 4y ago
    Usually people experience this when they're using a React frontend that's served from a CDN, while the backend is served from a separate service. If that's the case, the pattern you're describing is pretty normal and not an inherent cause for concern. If you really want to workaround it, you can do this: First, host your backend and your frontend from the same origin, so the initial window navigation includes the httpOnly cookie (make sure your cookie is set to SameSite=Lax, NOT SameSite=Strict). Then, before the CDN serves your static content, run some middleware to ensure the httpOnly cookie is valid, and add some kind of marker to the page body to indicate they're signed in (or redirect away if they're signed out). The not-so-trivial part is running middleware in front of the CDN, but that's possible with things like Cloudflare Workers, and these days it's built-in to Next.js for most hosts. For this approach you'll also want to make sure you can check cookie validity quickly at the edge, or else you'll be slowing down your CDN a lot.
colinclerk 4y ago
Disclosure: cofounder @ https://clerk.dev https://clerk.dev Auth isn't "hard" per se, but it's still a big struggle because there's just so much to implement. For example, one of the most common attacks today is "credential stuffing," which is simply the practice of taking leaked credentials and trying them on other websites. Protection against this is arguably trivial: implement HaveIBeenPwned and a rate limiter, and create a mechanism to update the password when credentials leak. But that's a lot of work, it can take a lot of tuning to get the rate limiter right, the UX/UI for updating passwords is time consuming, etc, etc. And that's just one piece of authentication security – there are so many described in NIST 800-63B. And then there's also the challenge of keeping up with user preferences - Sign in with Google, SAML, Touch ID, magic links, etc, etc. This seems to be fragmenting rather than consolidating. Obviously biased, but all-in-all, I think you're better off sticking with a service than pulling it in-house, even if you stay with one of our competitors :)
- mooreds 4y ago
  Disclosure, I work for one of Colin's competitors, FusionAuth. :waves: Well said. The other piece is that it's undifferentiated. I always say "no one ever fills out a login form and says 'wow, that was so beautiful'." It's always a door between where users are and where they want to be, inside your application, doing their job or scrolling cat pictures. Perfect candidate for choosing a service, imo.
- encody 4y ago
  Disclosure: I don't work for FusionAuth or Clerk, or any of their direct competitors, but I figured I'd join the disclosure club. I've been using Clerk for the past few weeks and it is an absolute breeze. Docs are easy to read and understand. They've prebuilt enough and the features they included are pretty useful (like organizations!). However, they annoy you with lots of emails. Pros and cons.
mooreds 4y ago
Disclosure: I work for FusionAuth. > Sure hashing a password and pairing it with a n email is easy in theory, That way lies frustration and wheels spinning, as you spend time on undifferentiated functionality that is critical. So, do some evaluations of the options out there (including OSS libs, framework provided solutions and auth providers) and pick one. It's a nice architectural component similar to a message queue or database. Only in very rare circumstances would you write one of those, and auth should be the same. > I’m going with trying out firebase auth for the express apps I’m building now, Good on ya! Anything is better than rolling your own. When you want to migrate off Firebase, you can get at least get your password hashes: https://fusionauth.io/blog/2022/05/25/how-to-migrate-from-firebase https://fusionauth.io/blog/2022/05/25/how-to-migrate-from-fi...
hknmtt 4y ago
nowadays i use only email auth link. no password. simply you provide email address ,receive auth link, click on it and you are in. for additional security you can implement TOTC auth google auth or alternative apps and in case of lost access to email you can provide recovery questions like in the olden days. or phone number verification.
- BerislavLopac 4y ago
  The problem with this approach is when you're not using the same device/environment to read email and log in, for example when you're on someone else's computer (say, in a public library).
  - hknmtt 4y ago
    being ONLINE and consuming an ONLINE service implies you can access your ONLINE email account

Rodeoclash 4y ago

I've also been in this space recently and settled on trying Ory which is a kind of headless auth solution. I'm using it in Phoenix/Elixir which lacks an SDK for Ory but it all seems fairly straight forward. I'm using the Ory cloud solution but might dive into hosting it myself at least for local development against it.

7speter 4y ago
Ory looks promising. Can you use the free tier for multiple projects as long as they are low volume?
- eropple 4y ago
  Hosting Ory isn't difficult, FWIW.

danielheath 4y ago

Security is ultimately a question of cost to attackers. Is their goal of “compromising your app” worth risking you noticing their (valuable, hard to create) zero-day and getting it fixed upstream?

ss108 4y ago

I feel like this is ultra vires? It's a common sentiment now that just hashing passwords is terrible, but we did this at every startup I worked at previously and it was fine. Is it really an issue? For an early-stage startup, almost nobody sees the app anyways lol--we'd all be lucky if we were popular enough to hack For my current startup, my cofounder, who is the CTO, insisted we use auth0, so we do, but it's a pain. It's such overhead. Sometimes it's buggy. There is a lot of stuff we have done and (are trying to do) that would have been so much faster to build if we had just done it my way. I wonder if I am very naive or cavalier about the security risks.

vinjin 4y ago
I would recommend taking a look at Stytch. It is a startup that aims to have a simple, customizable way of building authentication. Disclaimer: I work at Stytch.
- ss108 4y ago
  Thanks lol

justusw 4y ago

Proving the absence of a 0 day for whatever your solution you are using is always going to be difficult. But dwelling in thoughts like this is close to crossing the border to FUD territory. And who says there isn't a 0 day for Firebase auth? We can put our faith in systems that have been hardened over the years and are easy and reliable to implement. And email + hashed/salted password belongs to them. And by that, I specifically mean using a library that takes over the hash/salting part for you. For me, not rolling your own crypto not only means not implementing your own hash algorithm, but also staying off-the-shelf with the code that calls said cryptographic functions. I also like to stay conservative with regards to session cookies vs. JWTs. One has been around for more than 2 decades, is well understood, and has some really solid cross-browser security measures behind it (HttpOnly, Secure Cookie, etc.) I personally like using the Django contrib auth library for this purpose.

Waterluvian 4y ago
May I ask a related question? Have you found a good way to do session auth in Django with httpOnly _without_ having to hit the server and see if you get a 403 back? Because it’s httpOnly I cannot know client side if I have a session cookie until I try and fail once.
- colinclerk 4y ago
  Usually people experience this when they're using a React frontend that's served from a CDN, while the backend is served from a separate service. If that's the case, the pattern you're describing is pretty normal and not an inherent cause for concern. If you really want to workaround it, you can do this: First, host your backend and your frontend from the same origin, so the initial window navigation includes the httpOnly cookie (make sure your cookie is set to SameSite=Lax, NOT SameSite=Strict). Then, before the CDN serves your static content, run some middleware to ensure the httpOnly cookie is valid, and add some kind of marker to the page body to indicate they're signed in (or redirect away if they're signed out). The not-so-trivial part is running middleware in front of the CDN, but that's possible with things like Cloudflare Workers, and these days it's built-in to Next.js for most hosts. For this approach you'll also want to make sure you can check cookie validity quickly at the edge, or else you'll be slowing down your CDN a lot.

colinclerk 4y ago

Disclosure: cofounder @ https://clerk.dev https://clerk.dev Auth isn't "hard" per se, but it's still a big struggle because there's just so much to implement. For example, one of the most common attacks today is "credential stuffing," which is simply the practice of taking leaked credentials and trying them on other websites. Protection against this is arguably trivial: implement HaveIBeenPwned and a rate limiter, and create a mechanism to update the password when credentials leak. But that's a lot of work, it can take a lot of tuning to get the rate limiter right, the UX/UI for updating passwords is time consuming, etc, etc. And that's just one piece of authentication security – there are so many described in NIST 800-63B. And then there's also the challenge of keeping up with user preferences - Sign in with Google, SAML, Touch ID, magic links, etc, etc. This seems to be fragmenting rather than consolidating. Obviously biased, but all-in-all, I think you're better off sticking with a service than pulling it in-house, even if you stay with one of our competitors :)

mooreds 4y ago
Disclosure, I work for one of Colin's competitors, FusionAuth. :waves: Well said. The other piece is that it's undifferentiated. I always say "no one ever fills out a login form and says 'wow, that was so beautiful'." It's always a door between where users are and where they want to be, inside your application, doing their job or scrolling cat pictures. Perfect candidate for choosing a service, imo.
encody 4y ago
Disclosure: I don't work for FusionAuth or Clerk, or any of their direct competitors, but I figured I'd join the disclosure club. I've been using Clerk for the past few weeks and it is an absolute breeze. Docs are easy to read and understand. They've prebuilt enough and the features they included are pretty useful (like organizations!). However, they annoy you with lots of emails. Pros and cons.

mooreds 4y ago

Disclosure: I work for FusionAuth. > Sure hashing a password and pairing it with a n email is easy in theory, That way lies frustration and wheels spinning, as you spend time on undifferentiated functionality that is critical. So, do some evaluations of the options out there (including OSS libs, framework provided solutions and auth providers) and pick one. It's a nice architectural component similar to a message queue or database. Only in very rare circumstances would you write one of those, and auth should be the same. > I’m going with trying out firebase auth for the express apps I’m building now, Good on ya! Anything is better than rolling your own. When you want to migrate off Firebase, you can get at least get your password hashes: https://fusionauth.io/blog/2022/05/25/how-to-migrate-from-firebase https://fusionauth.io/blog/2022/05/25/how-to-migrate-from-fi...

hknmtt 4y ago

nowadays i use only email auth link. no password. simply you provide email address ,receive auth link, click on it and you are in. for additional security you can implement TOTC auth google auth or alternative apps and in case of lost access to email you can provide recovery questions like in the olden days. or phone number verification.

BerislavLopac 4y ago
The problem with this approach is when you're not using the same device/environment to read email and log in, for example when you're on someone else's computer (say, in a public library).
- hknmtt 4y ago
  being ONLINE and consuming an ONLINE service implies you can access your ONLINE email account