Egregoros

Signal feed

Timeline

Post

Remote status

Context

5

I did not write the code for NCD. I only have patched/changed the frontend code. I do not know Elixir (I'd like to) but my focus is on React and NodeJS. If I'm going to build something, I'm going to make sure it's as secure as I can make it, and email security/OAuth is out of my hands for the most part.

Replies

11
I like React. It's a fun toy language for people like me who cannot take the time to learn C. I'd like to pick up Python eventually for machine learning/AI tasks eventually but I want to master this first.

Yes, but anyone on this side of the internet dumb enough to use firstnamelastname@gmail.com for their email is more or less asking for it. Besides, the platform isn't going to be for WN/fashy shit. It's just an art repository for their usage. If you cannot be fucked to use one of your fourteen burner Protonmail accounts to sign in then I'm not sure what to tell you.
Frankly I do not understand the flow of salting/hashing/verifying passwords well enough to effectively do it myself and don't want to slip up somewhere because retards use the same password for everything, have passwords leak, and then that causes a cascade of issues.

I consider all edge cases in everything I do and spend hours mulling over stupid "what-ifs" and never get anything done because of it. If Protonmail blocks OTP/verification links now (never had the issue myself but I don't really use Protonmail much anymore), then there are other providers you can use.

I'm using AuthJS for it, and it's an excellent package. I could set up credential logins with it, but they make good points about using magic links/oauth providers. Google, for example, can spend millions of dollars having jeets look over their security posture and patch vulnerabilities. I do not have that kind of time/money and I do not like jeets so I will not hire them. But, if someone gets their Gmail credentials leaked, it's out of my hands. Less complicated that way.

Because I know AuthJS. In the future, I can look into other packages, but prefer to stick with what I know, and works with my database adapter. Pain in the ass... but it's a well established library. No, I'm not using JWT because database sessions offer better reactivity without worrying about stale data. If it becomes a performance issue in the future, sure, I could revisit, but I sincerely doubt we'll get to that point with this project.

@matty @WandererUber say that you're hacked and your users and hashed passwords are leaked. Due to salts, even if every single one of your users is flying with "password1", then the hashes will all look different and couldn't be cracked in 1 millisecond. Due to salts, if your users all have unique and good passwords, then cracking them is a slow pain in the ass and this is the intended result.

But, your user list still has the usernames paired with each hash. So for any particular user, if that user is a retard that reuses passwords, then a motivated attacker can pull all of the user's other leaked passwords and cracked passwords, look for a pattern, and then crack it as easily as if it were unsalted.

So salts are a nice thing that's largely defeated by relentless password reuse and decades of leaked passwords. If you look through the antipublic collection you'll find some "good" passwords per complexity, but the pattern is really once you have 10 separate leaks using the same pattern.