Missing the obvious - rolling your own crypto
You probably don't need any crypto code at all if you don't roll out your own auth or payment.
Three things to never build yourself: auth, notifications, payments
71–80 of 193 posts
Re: Three things to never build yourself: auth, notifications, payments
#72This is a biased article. I would not let another company handle authentication or notifications for my apps. Payments, yes.
It's kind of funny that you'd allow someone else to manage money, but you wouldn't let someone else manage something that has the potential to cost you an equal or greater amount of money in GDPR violation fees and lawsuits.
How does using an external service for auth shield you from having to be responsible with your users‘ data?
GDPR compliance is not something you can just buy.
Re: Three things to never build yourself: auth, notifications, payments
#73I'm a hardware designer, apologies if this is a dumb question about "auth".
If you're creating a product that is primarily or exclusively for mobile devices, what's the downside of relying on "log in with Google" and/or "sign in with Apple"?
Re: Three things to never build yourself: auth, notifications, payments
#74Never outsource Auth. Maintain control over user accounts. That's the life blood of your business. If you have to ask everyone to reset their password because your auth provider increases their pricing or goes out of business, the churn will likely kill your company. I would say the same for Stripe, but at least they'll help you migrate off their platform. Auth providers cant help you because the passwords are hashed…
> Never outsource Auth. Maintain control over user accounts. This is some of the worst advice I've ever seen on HN. Don't take on risk you don't understand and cannot afford to mitigate. Don't be the next Equifax.
This is literally the Auth0 first contact sales pitch designed precisely to scare you out of even trying to assess the risk of building it yourself.
The reality is, though, it's never been easier than it is today to build secure auth - yes, it's still hard to do it right - but less hard than it ever has been before. So many security features are now a checkbox on a cloud provider's web interface that would have been a manual implementation of the underlying protocol a decade ago. So many languages have matured battle-tested OS libraries for handling the especially sensitive parts like crypto.
This notion that it is a "no-brainer" decision to happily trade your customer database and a % of revenue to remove the burden of stewardship seems crazy to me.
Re: Three things to never build yourself: auth, notifications, payments
#75No. Auth is not that hard, it's not hard to scale. It's the bloodline of every interaction between you and your customers. Nearly every "web" language has a open source Auth solution with modern jwts or jwts on cookies. Bcrypt and salting solves "storing passwords". Further more once you do it it's highly repeatable across products.
Re: Three things to never build yourself: auth, notifications, payments
#76Earlier quoted context omitted.
> Never outsource Auth. Maintain control over user accounts. This is some of the worst advice I've ever seen on HN. Don't take on risk you don't understand and cannot afford to mitigate. Don't be the next Equifax.
But he's arguments are pretty sound to me. Do you have any counter-arguments than a generic statement?
I guess the question is what's more likely, Facebook, Google or Apple leaving the oauth game or a bug in an internal solution.
Re: Three things to never build yourself: auth, notifications, payments
#77Never outsource Auth. Maintain control over user accounts. That's the life blood of your business. If you have to ask everyone to reset their password because your auth provider increases their pricing or goes out of business, the churn will likely kill your company. I would say the same for Stripe, but at least they'll help you migrate off their platform. Auth providers cant help you because the passwords are hashed…
You can also choose to self host. Keycloak and FusionAuth (disclosure, I am an employee) let you self host. You then have the user database in your systems. > And the only way off without a mass password reset is a silent migration in the background: migrate the user when they login.. but we all know that will take months and you will never get 100% to login during the migration period. Actually, not true. I can't sp…
I'm currently implementing Keycloak for my startup. It's not perfectly documented, but I really like all the things it can do for us and how extensible it is.
Re: Three things to never build yourself: auth, notifications, payments
#78Earlier quoted context omitted.
> Never outsource Auth. Maintain control over user accounts. This is some of the worst advice I've ever seen on HN. Don't take on risk you don't understand and cannot afford to mitigate. Don't be the next Equifax.
It is really not difficult to use BCrypt or Argon2 with your backend of choice. Proper password and session management have been made accessible for many years if you use any "modern" backend.
> It is really not difficult to use BCrypt
Something I once saw in production:
An otherwise normal usage of bcrypt, that "prehashed" the password with sha512 before passing the resulting hash to bcrypt. This is conceptually reasonable (although not very useful) for reasons I don't think are worth going into, but had two critical problems.
1. It technically broke bcrypt's side-channel protection against timing attacks (bcrypt runs in constant time, while sha512 does not).
2. The much worse issue was that the binary hash was being passed to bcrypt. If bcrypt encounters a null byte in the input, it considers that to be the end of the input and ignores everything after, c-string style. Every byte of the binary hash had a 1/256 chance of being a null byte, which means 1/256 passwords result in a hash with the first byte being null, which means bcrypt will accept any of them as equivalent to the others. You could login to 0.4% of accounts by guessing ~256 completely random passwords (and a larger number of passwords were similarly but less extremely weakened)
You can say "well that's their fault for mucking with the input to bcrypt" but I bet most people would believe that kind of operation was safe before it's explained to them why it's not. It's very easy to accidentally destroy the security of a crypto scheme without knowing it, and thinking that what you're doing is perfectly run of the mill and safe.
Re: Three things to never build yourself: auth, notifications, payments
#79More general: Things to never build yourself: Things outside your core business. Are you selling a notification service? Build it yourself, otherwise find either self-hosted or hosted solutions, depending on situation.
> Are you selling a notification service? Except when there are none, you have to build it yourself.
And sometimes you just can't change your processes enough for no package customization.
I'm currently building what's essentially an internal specialized platform that is used for data science/engineering as well as actually providing the models.
The data is strictly private to the level that you might actually end in jail if you have a breach. While we use AWS, said use of AWS is more than half the reason we have to build custom solution around Keycloak, because a) AWS SSO is purposefully limited in a way that prevents us from using it b) AWS really doesn't work well with SSO for getting credentials for AWS SDK applications.
We also need to self-host because we can't outsource auth, including possibly requiring a legal shield against known hostile actors like USA. (shit's complex on that)
Then we have essentially "normal business requirements", meaning that we actually want SSO that results in user logging in exactly once - when they login to their VDI in closed-off VPC. And that turns out to be really complex, especially in case of accessing AWS services later :/
Re: Three things to never build yourself: auth, notifications, payments
#80Regarding auth, I absolutely bought to JWT cool-aid but honestly if you're still on the monolith phase just use the most popular auth framework for your language. JWT adds a lot of complexity and room for misconfiguration, you do get something in return of course - it is stateless (hence scalable), works great with microservices, and improves your security model somewhat by separating issuing from verification. But y…
To make things easy I usually use "alg":"none". It makes using jwts a breeze. https://datatracker.ietf.org/doc/html/rfc7518#section-3.6
I recently discovered the TLS_NULL_WITH_NULL_NULL SSL ciphersuite (https://datatracker.ietf.org/doc/rfc5246/) - it makes analyzing network traffic so much simpler, and you don't even have to deal with certificates any more!