jaeming

Looking forward to the easy & incremental paradigm shift whatever it is.

I'm hoping there could be some improvements to composability and slot edge-case usage possibly?

In any case it was most likely the offline edit that happened on FCP 7, which could have been done on any working editing station from the last 30 years or more as it just exports the metadata when it gets onlined and mastered.

How hard is it? What are the challenges? Could you be more specific? Cause I keep seeing the blog and article headlines telling me how hard Auth is but a lot of them don't go into details. That's the kind of mystification I'm having an issue with.

I'm not against using service providers for CAPTCHA or CDN's like Cloudfront for DDOS/brute-force prevention. Refusing users the ability to register an account with breached credentials sounds like a great idea though I've implemented something like this myself already.

I'd wager that aside from what anyone put in their contracts with OKTA, that they didn't pay out a dime for the 25 minute Breach.

Do I want to just pass the buck for the sake of saying, I'm not personally liable or being able to deflect and say, "look this happened to a lot of other companies too". That's part of the fear that these blog posts and articles try to instill with absolutes of "never ever do this..." or "this is way too hard for you..."

I'd argue I'm less of an attack vector than Okta for most of my use-cases. And I think that's part of the issue here, that a lot of us are talking different scenarios and perspectives. If I was an IT head or sysadmin, yeah, I'd probably use something like Okta or onelogin. For a web app with an admin panel for a restaurant taking reservations, Yeah, I'd roll my own and own the users table with passwords as well. For an enterprise-level web app, I might consider compromising and use something like AWS Cognito. But for all my own personal projects, a few paid contractor jobs, and even a few large-scale apps, I have rolled my own auth and preferred it largely to alternative like firebase, and auth0. I'm starting to get the picture that I'm in the minority there. If you don't care about auth and don't want the liability, sure go with a provider. I did mention in my original comment that maybe I was weird in that I liked going down the rabbit hole on auth concerns.

I'm not quite to the point of never wanting to own another user table with a password column. Maybe I will be someday. Yes, it's a liability but I still think my table (which lives on RDS or Aurora btw) is less of a target than Okta's users tables, which were breached earlier this year. BTW, Auth0 was recently acquired by Okta.

But yeah, if I was spinning up a large-scale, enterprise-level web app, I'd probably tell my stakeholders we were going with AWS Cognito or something, just to offset liability. Never mind, I'm still going to have to have a users table, and if I'm using Cognito for authorization (group-level authorizers) then god help me (check out their limits on those custom fields too). And btw, they use JWT, and their front-end solution Amplify still uses local storage to hold credentials. And it's going to be even more difficult to set up the basic auth flow than if I rolled it myself, but who cares, as soon as the execs hear AWS solution or cloud-native, they nod and feel assured. After all, the liability is now somewhere else as you said. Never mind there's a host of missteps and other ways you could still mess it up on your side of the fence there.

For all of my personal projects, a few smaller paid side-projects, and at least two enterprise-level products, I've rolled my own and owned the DB and it's felt much better to me than the alternatives I've had to face when I forced into some auth as a service solution. I've done auth0 twice (never again). Firebase once. Cognito at least 4 times. I still prefer to roll my own. Maybe I am a masochist. Maybe I've been lucky. Maybe I just go against the grain and do things my own way, providing less of a common attack vector.

The number of devs I've run across who don't even understand the basics of authentication has surprised me. Yes, it's seemingly easy in concept as you say, to "just bcrypt it" but it astounds the number of devs I've come across or worked with who didn't even understand what that was or what it looked like. Then we have the "company-sponsored blogs" and the echo chamber of people throwing down absolutes of "whatever you do, never roll your own", "you don't understand how hard Auth is", etc...

But I'm coming to accept that maybe I'm in the minority on this topic so I'll stop ranting for now. I suspect that a lot of us on this thread are speculating or speaking from different scenarios and experiences, like a sysadmin or IT head, vs legacy enterprise apps, vs mobile, front-end specific SPA's with stateless auth, vs server-rendered stateful, session-based web apps, etc...

In any case I appreciate you taking the time to map out your thoughts and perspective in detail and I think it's probably broadened my own thoughts on the subject.

It's blanket statements like this that really make me rant on this subject. Lets mystify auth and tell devs to stay away from it! By the way, pay me to do it for you...

I mean by your own blanket advice, you should have never made the start-up that you did. There are no absolutes (well only for siths). Just tell people the pros and cons and what features you have. I work on apps in production, running for almost a decade, which we rolled our own auth on, and that have been maintained with a very basic level of tech-debt. I stand beside that work and guarantee it to our stake holders. What I cannot guarantee is X-company for the next ten years and if we will be able to migrate our data off their platform if they don't get funding.

Auth is not that hard. Policies are not that hard. Unix solved permissions 40+ years ago. I would argue, that if you are a small business use-case, you will probably never have to worry about these issues. If you are enterprise, you will have money to spend on it and be able to hire the talent and expertise. If you are somewhere in-between, then sure, go for some easy-use provider that gives you a form you can iframe or react component into your app or whatever. There is a market and use-case for cloud based services for user management, auth, policies, etc... I'd personally go with AWS cognito in this case, which I think is even a good cloud-native approach for enterprise. But please stop telling every dev to never build auth or policies by themselves just because you just recently did it and are now trying to monetize it.

Most of the security nightmares I've heard of result from laziness or lack of care or someone not seeing a job through to the end. All of the encryption alogos we use will be easily brute-forced at some point in the future. Is it worse to store and back up those hashed passwords locally, rather than trusting Okta to do it for you (which incidentally was breached while your old MD5 hashes probably weren't)?

But I'd still argue it's worth knowing what those libs are doing for you and you can only really appreciate it once you've rolled your own. I've done so on many a personal project where the risk was low. But yeah honestly, if I was rolling a large-scale enterprise app today, I'd probably utilize AWS Cognito. But this is also not for the faint of heart IMO.

If auth isn't your job and isn't your core competency

I'd argue, it sort of is a core part of any web dev's job and any who neglect diving into it do so at their own risk. Maybe I come from a different time or place than what's the contemporary norm, though I'm okay with that. The main issue I have is with company-sponsored blogs and comments that will just blanket state you should never roll your own auth (because you can pay us instead, oh and btw, we rolled our own auth so you don't have to).

I suspect most people use products like Auth0, not because they are trying to solve those hard problems, but more likely, because it's easy to set up and comforting to hand off that segment to a company that says they are battle-tested and secure, etc.

I personally like writing my own Auth because I can cater to my personal level of paranoia and learn more. Maybe I'm weird in that way, that I like to consider questions like, how short-lived should my token be? Should I issue a new token on every request? Local Storage vs cookie? Should I use a one-time token? Should I store the JWT in memory only on the client? How would I invalidate a user's token at will?

There's lots of interesting questions beyond the basics for sure and I can see how that might be intimidating. Most projects only need the basics though. And if you need more, it might be easier to extend your own implementation rather than some use-case not catered to by a library or service.

At the very least, I think it's wise for dev's to experience writing their own Auth a few times to get a grasp of some the challenges and better understand what those services might be doing for them.

Also, I have been wanting to try https://system76.com/ for quite a while but I can't get my work to approve one.

I'm not saying this is necessarily always the right approach. It could have back-fired if my manager had judged it wrongly. But what I'm trying to say, is that manager would have never left me alone in a meeting with the PM exposing me to the scenario you describe. Eventually, as I grew more senior it was useful to be exposed to that, but at that point in my career, I really appreciated being shielded from the politics while I just focused on improving my craft.