Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Three things to never build yourself: auth, notifications, payments

courier.com

Post reply on HN
Print view View original

91–100 of 193 posts

Re: Three things to never build yourself: auth, notifications, payments

#91

Post by sarsway »

capableweb wrote: post #23
valachio wrote: post #11

This is a biased article. I would not let another company handle authentication or notifications for my apps. Payments, yes.

> notifications for my apps What kind of notifications are we talking about where you can get away with self-hosting? AFAIK, Push Notifications on smartphones have to go through Google and Apple's servers. Maybe if you're doing email notifications?

I think there are a lot of 3rd party wrapper around Google & Apples Push APIs, which are not really needed. You can send Push Notification yourself just fine.

For email though, not sure, that's a completely different topic. It comes with many headaches, using a service like SendGrid or Mailchimp seems like a good idea, and if you really want to roll our own mail servers down the line you can still do that.

Re: Three things to never build yourself: auth, notifications, payments

#92

Post by capableweb »

arcbyte wrote: post #84
bhaney wrote: post #78

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

> 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 equal, or the first one, without knowing this specific thing, because most people don't implement their own password-hashing, they use library/framework provided ways that has been established as best practice already.

But, can't blame them really, the difference is marginal and innocent on the surface, but once you understand the implementation, you'll see the holes.

Re: Three things to never build yourself: auth, notifications, payments

#93

Post by capableweb »

sarsway wrote: post #91
capableweb wrote: post #23

Earlier quoted context omitted.

> notifications for my apps What kind of notifications are we talking about where you can get away with self-hosting? AFAIK, Push Notifications on smartphones have to go through Google and Apple's servers. Maybe if you're doing email notifications?

I think there are a lot of 3rd party wrapper around Google & Apples Push APIs, which are not really needed. You can send Push Notification yourself just fine. For email though, not sure, that's a completely different topic. It comes with many headaches, using a service like SendGrid or Mailchimp seems like a good idea, and if you really want to roll our own mail servers down the line you can still do that.

I'm no mobile developer, so I don't really know what I'm talking about. Please enlighten me if you can. Doesn't push notifications on iOS require using Apple Push Notification service? That was my last impression I got when I talked with someone about it.

Re: Three things to never build yourself: auth, notifications, payments

#94

Post by habibur »

jayd16 wrote: post #76
guiomie wrote: post #57

Earlier quoted context omitted.

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.

That they will ban you for one reason or other has a very high possibility of occurring before you go out of business.

Re: Three things to never build yourself: auth, notifications, payments

#95

Post by edoceo »

mooreds wrote: post #68
Raed667 wrote: post #36

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

> Authorize.net

Arrreghhjh!!

Brings back horrible memories from the .com bubble for me.

F authorize.net.

Re: Three things to never build yourself: auth, notifications, payments

#97

Post by mooreds »

infamouscow wrote: post #31
spoonjim wrote: post #8

Earlier quoted context omitted.

Why can't you switch vendors?

One aspect that's difficult to navigate is migrating the passwords and MFA secrets.

Don't know why you are getting downvoted. Asking a vendor how you can get this sensitive data out before you commit to them is a great idea.

Re: Three things to never build yourself: auth, notifications, payments

#98

Post by MikeKusold »

rgbrenner wrote: post #27

Never 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 providers cant help you because the passwords are hashed... You need the same algo or you cant authenticate using the data they have.

You absolutely can migrate away from Auth providers. Auth0 (disclaimer: former employer) hashes passwords with Bcrypt, which is most likely the same exact algorithm you would choose. Bcrypt stores salts & rounds as part of the hash making those hashes fairly portable.

Even if you wanted to change algorithms, there are ways to do this so that it is transparent to the user, such as running the plaintext password through a new algorithm after a successful authentication and storing it in a new column.

Re: Three things to never build yourself: auth, notifications, payments

#99

Post by micahzayner »

legulere wrote: post #72
_6pvr wrote: post #49

Earlier quoted context omitted.

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.

I think this was in reference to someone managing compliance of your notifications.

Re: Three things to never build yourself: auth, notifications, payments

#100

Post by jayd16 »

habibur wrote: post #94
jayd16 wrote: post #76

Earlier quoted context omitted.

I guess the question is what's more likely, Facebook, Google or Apple leaving the oauth game or a bug in an internal solution.

That they will ban you for one reason or other has a very high possibility of occurring before you go out of business.

You and I have different definitions of very high possibility.
Post reply on HN