7 ms·
> 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
by void_mint 5y ago
> 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.
- troygoode 5y ago100%. I'm old enough that when I started my career we were still storing credit card numbers on our servers (and many companies were unfortunately doing so in the raw...). PCI compliance luckily knocked some sense into the industry. Crazy to me that some people don't realize that PII and secrets like passwords are basically in the same category now.
- Raed667 5y agoIt 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.
- void_mint 5y ago> Its really not difficult Good luck to you!
- city41 5y agoIt's true the happy path and common error cases are easy to account for. But it just takes one overlooked bug or vulnerability either in your code or a library's code to send it all crashing down.
- bhaney 5y ago> 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.
- arcbyte 5y agoThank 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.
- deleted 5y ago[deleted]
- capableweb 5y ago> 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.
- dvdkon 5y agoIn what scenario do you need to have personal info associated with accounts and don't need to have full access to it? I see no user privacy benefits to outsourcing auth, unless all you need is to do is to verify someone's a real person.
- guiomie 5y agoBut he's arguments are pretty sound to me. Do you have any counter-arguments than a generic statement?
- jayd16 5y agoI guess the question is what's more likely, Facebook, Google or Apple leaving the oauth game or a bug in an internal solution.
- bryanrasmussen 5y agowhat's more likely - you being able to talk to Facebook, Google, or Apple to let your app/site use their authorization solution once their algorithm has decided to ban you, or you fixing your bug.
- capableweb 5y agoYou're missing the original point. rgbrenner is talking about auth solutions like Auth0 where users can use username + password to sign up/login, and when you eventually are gonna have to leave (which, if your business is successful, you eventually will), you'll need to reset passwords one way or another. Of course, if you only use third-party authentication for your service, it doesn't really matter what's in-between there, you can work around it.
- habibur 5y agoThat they will ban you for one reason or other has a very high possibility of occurring before you go out of business.
- jayd16 5y agoYou and I have different definitions of very high possibility.
- withinboredom 5y agoI had an app get banned for copyrighted content by Google because there was a movie poster in one of the backgrounds of the screenshots (camera type app in 2013). It will happen, probably for something ridiculous. In every job I’ve worked at, it had happened or they’d been threatened to be banned, at least once.
- remram 5y agoI don't think the main problem with Equifax was the Auth info they lost. It was their own business data, e.g. social security numbers etc, which wouldn't have been outsourced to their Auth provider anyway.
- debaserab2 5y agoThis 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.
- deergomoo 5y agoNot 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.
- beardbandit 5y agoI think that's where the confusion lies. Are people suggesting someone to write their own auth from the ground up, or write auth in coordination with their stack's auth library of choice?
- joshmanders 5y agoIt appears to me the assumption these people / articles make is that nobody is using existing hardened production ready libraries, but hand writing everything from the ground up for their todo app. Because otherwise their message falls flat on its face.
- justinclift 5y agoWell, we implemented Auth using Auth0. The experience wasn't terrible, but not fantastic either. Probably best described as "ok". However, now they've been bought by Okta, which has a pretty bad reputation. So, I guess we'll get to find out eh?