Don’t tell me what to do.
Three things to never build yourself: auth, notifications, payments
121–130 of 193 posts
Re: Three things to never build yourself: auth, notifications, payments
#122Never 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…
Auth is simple. Even a script kiddie can do it. People who think auth is hard are amateurs. People who think auth should be outsourced are stupid.
Re: Three things to never build yourself: auth, notifications, payments
#123As a serial entrePAYneur and the core foundational member of multiple payments companies responsible for all hardware and software architected, assembled and constructed with my very own hands I would sternly disagree with this article. I have done exactly what this article states not to do and have done so multiple times with each better than the last, it only takes an interest and an insatiable desire to learn. The world will come to learn the importance of "owning all the code" and "data control" as the cyber issues continue to cost countless billions and in time more and more bodies. Security will become paramount to everything and outsourcing for "cheap" will have a much greater cost than one realizes in the moment. Those that take greater risks have much greater reward and those risks shape the future for where we are today. My current efforts are the really fun stuff given the world's current temperature on so many fronts.
Always remember that which you read is just someone else's flavor of an experience in which they try to convey their ways on you. I am not bashing what they wrote just recognize how things would be if risks are not taken.
Re: Three things to never build yourself: auth, notifications, payments
#124Methinks "Three things I can carefully build myself and gain a competitive advantage over everyone else who thinks they can't..."
Re: Three things to never build yourself: auth, notifications, payments
#125I'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"?
[deleted]
Re: Three things to never build yourself: auth, notifications, payments
#126Earlier quoted context omitted.
> 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…
Thank you for sharing that experience. It was a very interesting read. However, lest anyone get the wrong opinion, password hashing is a very simple, straightforward, solved problem and has been for years. One person doing something monumentally stupid doesn't make Auth some kind of cryptic minefield.
It's monumentally stupid to think auth is easy. Yes there are standard cookbooks and checklists out there. The hubris to think that auth fails due to a crypto scheme choice is why average programmers consistently fail at it.
The yearly report of leaks in Fortune 500 companies should be proof enough of this.
EDIT: To elaborate. Crypto scheme is only one tiny facet of a successful authentication solution. Where do you store the hash? What language and stack are you using? What is the maturity of libraries available to you? What protocols? And many more seemingly tiny decisions. All it takes is a lazy developer that imports an insecure transient dependency or snoozes on a CVE.
Re: Three things to never build yourself: auth, notifications, payments
#127Earlier quoted context omitted.
I'm curious how people handled payments before Stripe? Did you integrate with banks directly? How different is that in terms of what Stripe offers?
We used CyberCash (I think) and Authorize.net, which were to Stripe as Altavista was to Google search. That is to say that even 20 years ago there were middlemen in the payments space, they just were pretty horrendous to work with.
[deleted]
Re: Three things to never build yourself: auth, notifications, payments
#128Earlier quoted context omitted.
I'd suggest checking out FusionAuth, but I'm a bit biased :) . I have heard good and bad things about Keycloak, but I know one thing for sure: it's far better than rolling your own auth. Good luck with your startup!
I've never checked out your product, but we use Keycloak extensively and I can say it is a great Auth solution and I've used several and even built some (poorly). The only real downside of Keycloak IMO is the documentation. Because it covers so many bases, and is very extensible, the official doc is enormous. There are a lot of lightweight articles about how to use it, I'd use one of those to get started. Some great…
What other FOSS like Keycloak we have available in 2021? Looking to update my knowledge on options
Re: Three things to never build yourself: auth, notifications, payments
#129Earlier quoted context omitted.
Thank you for sharing that experience. It was a very interesting read. However, lest anyone get the wrong opinion, password hashing is a very simple, straightforward, solved problem and has been for years. One person doing something monumentally stupid doesn't make Auth some kind of cryptic minefield.
> Stop trying to make something sound difficult that isn't. Password hashing is a very simple, straightforward, solved problem and has been for years. Try asking the following question on Twitter: "While passing binary data, which example is safer for storing passwords? [ ] $password | sha256 | bcrypt [ ] $password | bcrypt" What do you think the average programmer would say? Most would probably say they are either e…
I think the question isn't particularly relevant because many programmers are just using bcrypt in a simple way that's very well documented. I think it's reasonable to expect people to know that "auth is dangerous, don't just do your own special thing and assume it'll be fine." If you want to do something that diverges from the simple case, then please don't try to roll your own auth.
Re: Three things to never build yourself: auth, notifications, payments
#130Earlier quoted context omitted.
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…
> 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.
What makes you think this foolish developer would not do the exact same thing before sending the data to an externally hosted auth service?