jaeming · HackerTrans

jaeming

no profile record

comments

w zeszłym rokudiscuss

I was one of those that really felt like Runes was going to ruin svelte. But after working with it on a small team for a month now, I can see the benefits. We previously had a lot of devs confused with `$:` and other reactive issues. It had always made perfect sense to me but I have to admit, it was a bit magical which was apparently too much for some. With the runes stuff I've seen it click with people in ways it didn't previously. I did like the elegance of the old syntax but I'll take the explicitness of runes if it gets my team on board and causes fewer issues.

2 lata temudiscuss

The post presents this like it's a novel and noble idea. Yet, nowhere does it mention the term severance(or redundancy pay). I guess I should applaud them for voluntarily following what would just be standard labor laws in some places?

2 lata temudiscuss

One of the biggest issues we have with Rails these days is finding Rails devs (at least where I work). Our next project's backend may very well have to be Node or Python specifically for this reason.

3 lata temudiscuss

Yeah, you know that thing Vue did with the composition API that a bunch of their users didn't like and then subsequently turned to Svelte over? Well, it turns out they were right and we're going to do the same thing.

3 lata temudiscuss

Thanks for the re-assurance. We've been migrating a huge app to svelte over the last 6 months and it's nice to hear it won't be become legacy on arrival ;)

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?

4 lata temudiscuss

As someone who worked for over a decade in post-production, I can tell you this was most likely edited on FCP 7 because it was considered the better tool and not because of cost considerations (FCP 7 was actually much more expensive than the newer version). When Apple released Final Cut Pro X, they re-worked the whole app (I think it was a complete re-write) and based it more on the iMovie interface, which a lot of editors considered less that professional. All the shortcuts and controls were completely changed as well, which made it hard for editors to transition over. A lot of people migrated to Avid or Adobe Premiere. Some just kept using FCP 7 because they considered a superior tool.

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.

4 lata temudiscuss

What I am not overlooking is that they as a company and in this comment have an implicit bias against Dev's rolling their own auth since their business model is based on them not doing that. The most critical point that I raise that is not irrelevant is they are prone to making blanket statements and falling into absolutes with "Never ever do this..." and "This is way too hard for you..." even though there are a wide array of diverse scenarios and use cases in web dev. And even if it is open source, a lot of enterprise won't touch it if there's not a support plan, or at least a lot of companies would not be willing to fork and maintain a large open source lib they had little dev involvement with. So their death as a company would essentially equal EOL for a good number of clients regardless.

4 lata temudiscuss

Mitigating an attack is really, really, really hard.

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.

4 lata temudiscuss

captcha integration is super easy and doesn't require a full auth integration service. Detecting a brute-force maybe less so maybe, though I get a lot of DDOS pretection for free with AWS & cloudfront. But I was more interested in the idea of letting users know they were trying to use a breached email/password on register or login. I've got that on bitwarden (password manager), though now days I just auto-generate any password.

4 lata temudiscuss

There's a lot of food for thought there and I can actually get on board with a lot of what you said. I enjoyed your perspective at the very least. I too have been a part of some tough audits, fedRAMP, etc. I've worked on apps that regularly get pen-tested. XSS is real, though more often I've seen ITOR issues. No need to worry about being hacked when you're giving it away for free. And then there were at least four OWASP courses I've been asked to do for work.

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.

4 lata temudiscuss

What I mean by tightly coupled, is if you can have your Frontend and Backend on the same domain, then yes by all means an httpOnly cookie is ideal. Now days there are a lot of SPA's that don't do that, or that have multiple api services across domains, or you are only writing a front-end and using some backend as a service like AWS amplify or numerous other scenarios that have led us to the concept of stateless authentication. You can still use a cookie in those situations, albeit without the use of httpOnly, which means they are going to be just as vulnerable to XSS as local storage. This is why I mentioned keeping a token in memory (this can be made even more secure with web workers). But since this doesn't persist across reloads, it's not an ideal solution for most leading towards utilizing strategies using refresh tokens/one-time use tokens, etc.

4 lata temudiscuss

Auth is actually a combination of two things: authentication and authorization. Whatever you do, please do not build either by yourself.

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.

4 lata temudiscuss

Existing crypto libs like bcrypt, which I mentioned? Or are you talking about something more? The credential stuffing mention you make makes me think you must mean something more. Does Auth0 by default advise users that they are using breached emails/passwords? If that is default behavior then I agree it does add a shining point to their feature-set.

4 lata temudiscuss

I mean, yeah, sure. Or for a number of other use-cases. I'd argue the best way is for the client to keep the token in memory over local storage. Of course if you have a tightly coupled app, session-based secure cookie is the best.

4 lata temudiscuss

I mean, it's stored in a DB somewhere, even if it's not your own. I would argue your own DB probably has less of an attack vector than major providers.

4 lata temudiscuss

I don't quite follow the moral here. Was the Dev who rolled their own auth back when MD5 was the norm supposed to time travel forward to a time when cloud services like Auth and Cognito existed? Or does the fault lie with whoever replaced his auth with cloud services and forgot to drop the passwords table?

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)?

4 lata temudiscuss

Oh yeah, for sure, there are a really good libs. Someone mentioned passport. I've personally used Devise/warden in Rails. Though we had to monkey patch/extend it so much that 6 years later it was almost a different beast entirely.

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.

4 lata temudiscuss

Too true and worthy of a rant of all it's own...

4 lata temudiscuss

I've never head that adage. I did hear one from Miles Davis that says, "If you have to ask, you'll never know." I ask a lot of questions though so I never paid much attention to old adages I guess.

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

4 lata temudiscuss

Yeah, that's why I prefaced with "the basics of auth are actually pretty easy". Rather than trying to opt-in to those other auth flows before you need them, I'd suggest starting with the basics and extend as needed. Although the MFA I've implemented was actually pretty easy too.