Bcrypt at 25

https://github.com/Sc00bz/bscrypt

https://www.gnu.org/philosophy/stallman-kth.en.html

"...But that machine wasn't designed also to support the phenomenon called “tourism.” Now “tourism” is a very old tradition at the AI lab, that went along with our other forms of anarchy, and that was that we'd let outsiders come and use the machine. Now in the days where anybody could walk up to the machine and log in as anything he pleased this was automatic: if you came and visited, you could log in and you could work. Later on we formalized this a little bit, as an accepted tradition specially when the Arpanet began and people started connecting to our machines from all over the country. Now what we'd hope for was that these people would actually learn to program and they would start changing the operating system. If you say this to the system manager anywhere else he'd be horrified. If you'd suggest that any outsider might use the machine, he'll say “But what if he starts changing our system programs?” But for us, when an outsider started to change the system programs, that meant he was showing a real interest in becoming a contributing member of the community. We would always encourage them to do this..."

> tell the framework how to work [...] and just send it data in the way it expects

What is that, if not also "hooks"? I've long thought about this and tried many different solutions, and there's only 2 sane points to implement a library/framework like this in an unopinionated way IMHO (without prescribing the DB schema, etc): you provide a library like passport.js with lower level hooks (data hashing, vendor connections, etc), or you provide a framework integration with higher level hooks (API, DB schemas, etc); the problem with the higher level hooks is that you'll need many more hooks, with the only advantage that the dev might need to write a bit less code overall.

As an example, let's see password recovery. With lower level hooks, the dev writes the recover page fully, the API endpoint and backend for it, and somewhere in this backend has a small integration with the hashing the new password; which then the dev saves in the DB. The dev has to do all of this, but in exchange the hook integration is just "hash the password".

However for a higher-level (let's assume a JSON API) integration as you seem to suggest, now you need to use the hooks from the front-end to the custom API, two endpoints that hopefully work as expected. And then you need to use the hooks to connect from the data generation to the DB, again at least 3-4 hooks to check for the valid user, check for duplicated password (maybe?), save the new password. And error handling here and to the front-end, which is going to be a monster.

(or an opinionated way like Firebase where you bring the whole house, but let's leave that for another post)

> To address this scarcity of talent, I've pursued a very unconventional approach. I've embarked on a new venture as an EDM (Electronic Dance Music) producer under the artist name Activ8te, creating cybersecurity-themed EDM tracks. My goal is to captivate a younger audience and ignite their interest in security topics. Some of my recent tracks, like "Teardrop Falling" and "I Am Tracking You," explore challenging security themes such as denial of service, censorship, and the risks to our privacy posed by sophisticated spyware (Activ8te, 2022). By raising awareness and enthusiasm for the field, I hope to contribute to the expansion of a skilled security professional pipeline.