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

101–110 of 193 posts

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

#101

Post by bhaney »

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.

My point is precisely that it wasn't "monumentally stupid," but rather a pretty reasonable decision given what the average person would expect bcrypt to provide functionally. The behavior I described is an unexpected landmine that people using bcrypt need to be aware of. There are likely others, though probably not enough that I would describe it as a minefield.

I would wager that most people reading this, if earnestly asked by a coworker "do you think it's fine for me to hash a password before passing it to bcrypt? I want to be able to support passwords over 72 characters and bcrypt truncates its input." would answer something along the lines of "I don't see how it could hurt" rather than "that's dangerous because a binary hash would result in a large portion of the passwords being hashed as an empty string"

The engineers that originally implemented and reviewed this were not idiots, they just weren't security experts.

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

#102

Post by slavboj »

sam_lowry_ wrote: post #82
remram wrote: post #66

Earlier quoted context omitted.

Making people reset their password is not that big of a deal. I have run into this multiple times, the most recent being amtrak.com. It just told me "you have to reset your password" and I got a link in email like if I had forgotten it. I have also received many "we had a security incident you have to reset your password now" emails in recent years.

There is a whole line of thought that accounts should be passwordless and accessed via an email reset link as part of normal login procedure.

Which is great until you lose access to your email.

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

#103

Post by sarsway »

capableweb wrote: post #93
sarsway wrote: post #91

Earlier quoted context omitted.

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.

Yes, you send a request to Apple's APIs and they will deliver a push notification. It's very simple really. Now there are a lot of wrappers around that (like courier.com) and instead of using Apple's API you know use the wrappers API. That also often requires some kind of 3rd party SDK to be integrated in your app.

These services are supposed to make things easier and have additional features like SMS notifications and so on, but, well not sure, never really used them myself.

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

#104

Post by oblio »

wisemanwillhear wrote: post #34
capableweb wrote: post #18

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

I've always thought this statement from Martin Fowler was right on target. > Boiled down this means that if the business process you are supporting is part of your competitive advantage you should build custom software, if not you should buy a package and adjust your business process to fit the way the package works. Source: https://martinfowler.com/bliki/PackageCustomization.html

https://www.joelonsoftware.com/2001/10/14/in-defense-of-not-...

Predating Fowler by about 10 years.

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

#106

Post by sam_lowry_ »

jpm_sd wrote: post #73

I'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"?

Some people would not login then, and a vocal minority will complain loudly.

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

#107

Post by deergomoo »

debaserab2 wrote: post #74
void_mint wrote: post #39

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

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…

Not to mention there’s a whole lot of middle ground between writing your own auth logic and using a hosted service. Any reasonably popular web-oriented language has plenty of fully featured, high quality libraries you can often just drop in.

Hell, we use Laravel at work, which includes pretty robust auth features out of the box. It feels like such table stakes stuff for a web framework that I find the idea of paying for a third-party cloud service absolutely bananas.

It also includes pretty solid notification and payment solutions too, though these usually plug into services like SNS and Stripe and don’t really fit the “self hosted” bill.

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

#108

Post by throwaway894345 »

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…

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

I would expect that the way to do this sort of migration is to run it until the costs associated with maintaining the migration infrastructure exceed the projected losses due to churn. You don't need to worry much about auth provider pricing because these are typically billed on the basis of monthly-active-users, so even if you have a small number of users who aren't active, they'll hardly show up on your bill. When this pool of unmigrated users is small enough that you can tolerate churning a percentage of them, you can turn off your migration infrastructure and enforce a hard password reset.

That said, I don't know what kind of business has a significant percentage of users who churn because of a one-time password reset. I can't imagine any b2b contracts being canceled because the service provider enforced a password reset. Maybe retail sites are different?

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

#109

Post by noAnswer »

remram wrote: post #88
noAnswer wrote: post #85

Earlier quoted context omitted.

You sure it wasn't phishing. SCNR

Yes

Every phishing mail I've ever got talked about something something security click this link pl0x. OP is right in the sense that not everyone will follow (in a given time frame) and "You will incur damage".

...but the same is true if you would have a leak. So whatever I guess.

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

#110

Post by elric »

In the early 2000s, a significant part of my income came from payment integrations. Everybody and their grandmother was jumping on ecommerce, and payment processors made it a bloody pain. To this day, I will never understand why, but it seems like they deliberately made it hard. And expensive. One of the companies I worked for had contracts with dozens of different payment processors, a lot of thought went into how to direct payments to the cheapest processor for whatever type of transaction (country, amount, card types, risk of chargebacks etc).

I'm glad Stripe mostly killed all that.

Post reply on HN