[DocTomoe]

> but there is absolutely a cost to the developer and I'm not talking about the cost of storing a hashed/salted password in the DB itself. There is a cost to build and maintain a password-based system.

Seriously ... if today's developers are unable or unwilling to learn about basic hashing/salting and database storage/value comparison, and consider such concepts 'costly' ... we may have passed the zenith of technological advancement, and are in a 'downfall of the Roman Empire' phase. Have some pride in your work.

> It means implementing and maintaining a number of things like your salt, password complexity requirements, password reset flow, and more like you going to use something like HaveIBeenPwned's hash list to make sure people aren't using known passwords?

Do you reinvent the wheel whenever you need to drive somewhere? these things mostly are already baked into most frameworks, and if they are not, most developers build something like this once, and reuse.

> [Magic Links] they do have a perfectly valid use-case.

Annoying customers and forcing them out of your business into the willing hands of your competition?

[joshstrange]

It's amazing how you, knowing nothing about my stack/use-case can speak with such authority. Going as far as to assume that we must be in a "'downfall of the Roman Empire' phase" because I see value in magic links and because I don't want to implement password support, again, in a product you know nothing about.

I have a very good reason for picking magic links, also the codebase for my project does not ruse a framework (there exist no good ones in the space I'm in) but instead of being curious you decided to be condescending. Cool.