🚀 Argon2 0.1

In the past before Custom Modules existed I implemented Argon2 for node via a custom formatter.

The only problem with this approach was that formatters are synchronous and Argon2 for node would only run in asynchronous mode.

I worked around this by wrapping the async function in a sync function. Wrong in so many ways and I knew that at the time but there wasn’t any other solution available.

Anyway, I finally found some time to create an asynchronous custom module for Argon2.

You know the drill.

Install the node module.

npm i argon2

Drop these two babies in /extensions/server_connect/modules

And enjoy async argon2 for node.

There is still one caveat. Wappler Security module doesn’t know shit about this module so we need to work around it to use it in a Security Login action.

To login someone you will verify the password entered in the form($_POST.password) against the hash stored in the database for that user using the Argon2 Hash action.

image

If the result is true you will log the user with these parameters:

image

Notice how you are login the user with the password stored in the database(query1.password) instead of $_POST.password. It will always log the user as the passwords will match. Thankfully you added this inside a condition that will only evaluate to true if the password is actually verified first via argon2.

On the other side If the result is false it means the verification failed and you can 401 the hell out of the user.

Disclaimer: I’m not liable of anything. Use this method and files under your own responsability. Audit the code and if you don’t feel comfortable using it DON’T.

Have fun.

12 Likes

Really wishing I could like this 1000 times. Partly in your quest to rise in the rankings but mainly because this is the piece of the puzzle that is preventing me from converting old PHP projects! THANK YOU!!!

It would be good, though to have a native version (if @george sees this)

1 Like

1000 won’t cut it unfortunately. I need 2700.

https://community.wappler.io/u?period=all

Once I overpass Teo I get a Tesla. We have this agreement.

Always glad I can help towards ditching PHP :smiley:

3 Likes

Let me reset your counter :rofl:

Good job!

6 Likes

I have absolutely no comeback for that threat so I will just close the door very quite behind me.

4 Likes

lol, now if you can write some kind of magic to provide affordable Node hosting. :wink:

Looks good though, well done.

1 Like

Amazon AWS FREE Tier @brad!

We’ve just hosted a Docker container running Node 14 on EC2 with AWS RDS for MySQL with a few hours learning here and there, a fair few mistakes, and doing the same thing a dozen times… BUT now it’s all working we are not looking back.

We have gone all in on Amazon after decades of hosting our own dedicated servers and cut infrastructure costs by nearly 60% in a single month!

:smiley:

LOL, I can’t see AWS being free for a node site with MySQL database. I would probably get suprised with a big bill. I don’t like surprises.

Anyways, I don’t want to hijack Jon’s thread with my hosting woes. :wink:

Anyone ever run into this when trying to run things?

Since I’m on a Mac, I’m guessing this means the Docker container I’m using is running a Linux distribution.

Chemicloud.com allows to host node js apps in all their shared hosting. Pretty affordable. Drawback is that you cannot run some resource intensive packages like puppeteer.

You will need to update the dockerfile in project to include installation of said library.
So everytime you deploy, this will get installed and be available for the Argon2 library.

Unforuntately, I don’t think it’s that easy with versions of GLIBC (the C installation on Linux). It looks like the Wappler Docker container is running version 2.24 (rather than the version 2.25 that the argon2 module seems to want):
Screen Shot 2021-07-23 at 9.30.22 AM

This appears to be non-trival to solve: https://askubuntu.com/questions/1021420/glibc-2-25-not-found-on-ubuntu-windows-subsystem-for-linux

From this GLIBC version, I think we can infer that the Wappler Docker container is running Debian 9 “stretch”:
Screen Shot 2021-07-23 at 9.32.02 AM

I think just updating it to the current stable Debian, Debian 10 “buster”, might fix the issue since it’s GLIBC version is newer than 2.25. Unfortunately, the wapplerio/node-12 parrent container that I’m using is private on Dockerhub, so I’m not sure how to just edit its Debian parent container to the current stable version. Any idea how to fix this? Maybe changing to the wapplerio/node-14 or wapplerio/node-15 parents containers on Dockerhub (both of which are also private)?

Am I the only one trying to get this working with Docker hosting, or are other people also using Docker hosting and have got it working?

I am not very good with Docker. So what you have shared does make sense and someone from the team would be the best person to respond here.
@patrick

Hi @bradyneal
I faced the same problem. Everything you wrote is correct. The Wappler image that is responsible for the web application is really built on the basis of Debian 9 (although the Mysql image runs on the basis of Debian 10). Using images with a different version of nodejs does not solve the problem, since all these images are based on Debian 9.

I think it would be great if a full Dockerfile was available, which is used to build the image of the Wappler web application. This would make it much easier to make changes if a deep customization of the environment is required.

Great job Jon - this is exactly how I imagined also the Wappler integration. But we need indeed to change also the security provider to be able to handle it as well. @patrick

1 Like

@George @patrick Does this mean you have plans to add support for the argon2-backed “Password Hash” formatter and the “Use Password Has Verify” checkbox to native NodeJS back-end Wappler? Or does it mean you plan to add better support for Jon’s extension code (see, e.g., Docker container GLIBC issues above)?

Adding solely argon2 to the backend although being a great addition to the product would still mask the fact that we can’t plug into the Security module. So it would be better for everyone that that part is resolved and then we can skip the workaround.

Edit: In case it’s not clear I would also prefer to have the argon2 module maintained by others :joy: Just not before the extensibility for Security Provider is built.

Were you able to find a solution to this issue? I just bumped into this same error while trying to implement this.