Better password encryption

[eddie5]

Would it be possible to add slow hash encryption options (like PBKDF2 or bcrypt) to Wappler?

I ask because I wasn’t sure which of Wappler’s default cryptographic options I should use to encrypt user passwords for my web app. So I did some googling and the recommended options seem to be PBKDF2, bcrypt or scrypt.

From what I can tell, Wappler doesn’t offer any of these. Here is a screenshot of Wappler’s current cryptographic options…

This security article is somewhat dated (from 2013), but it’s general conclusion is…

Passwords should be hashed with either PBKDF2, bcrypt or scrypt. MD-5 and SHA-3 should never be used for password hashing and SHA-1/2(password+salt) are a big no-no as well. Currently the most vetted hashing algorithm providing most security is bcrypt. PBKDF2 isn’t bad either, but if you can use bcrypt you should. Scrypt, while still considered very secure, hasn’t been around for a long time, so it doesn’t get recommended a lot, but it seems it will become the successor of bcrypt, once it has been around a bit longer. Note that while there are some caveats and password bruteforcing strategies for PBKDF2 and bcrypt, they are still considered unfeasable for strong passwords (passwords longer than 8 characters, containing numbers, letters, signs and at least one capital letter).

A somewhat more recent security article (from 2016) says…

… it is not recommended that regular web applications use any member of the SHA family, be it SHA1, SHA256, or even SHA512 for password hashing. The reason is that all of these hashes are fast hashes . When an attacker gets access to your database of password hashes and he also has a copy of your salt, which he presumably will considering that your server was compromised, then your users’ passwords are in danger. With a fast hash, the attacker can compute billions of hashes per second in an offline attack.

I read a handful of other articles too and the general thinking seems to be that fast hashes (like the SHA family) are less secure and not recommended, while slow hashes (like PBKDF2, bcrypt and scrypt) are recommended. The Laravel and Rails frameworks uses bcrypt I believe. There is a PHP implementation of PBKDF2.

This detailed 2019 security article also recommends slow hashes.

I am not a security expert so if I’m misunderstanding the current Wappler cryptographic options, please let me know.

Much appreciated!

[kfawcett]

I have a similar request here

Add password_hash() formatter

Could we add password_hash() and password_verify() for more secure password hashing in PHP environments? https://www.php.net/manual/en/function.password-hash.php https://www.php.net/manual/en/function.password-verify.php

[sbecks]

I agree it would be a great addition to access these options straight from the UI.

Though I think it’s possible to use password_hash() and password_verify() by making custom formatters…

Create a new php file in dmxConnectLib, Formatters called custom.php (if you already have a custom file just add the new formatters to it.

Add the passwordHash and passwordVerify functions shown below (the UUID formatter enables v4 UUIDs on insert), https://stackoverflow.com/questions/2040240/php-function-to-generate-v4-uuid.

To hash a password add {{$_POST.password.passwordHash()}} to the insert/update action on server connect.The database column should be CHAR 60.

To verify a password add {{$_POST.password.passwordVerify($parent.query1.password)}} in a condition on server connect. Where $POST_password is the password you’re checking and $parent.query1.password is the hashed value from the database. This returns true if the password is verified and false if not so doesn’t need any ==.

To use UUIDs add the UUID formatter to your custom.php file. On server connect on database insert add {{$_POST.uuid.uuid()}} where the database column name is uuid. Make sure $_POST.uuid returns empty. Database column needs to be CHAR 36.

[eddie5]

Thanks, @sbecks

What type of hashing algorithm would this work around be equivalent to? Would it be a slow hash like bcrypt or PBKDF2…or would it be a fast hash like the SHA family?

[sbecks]

Hi @eddie5,

It would give you bcrypt. If you change the text from PASSWORD_DEFAULT to the PASSWORD_BCRYPT options below it will encrypt using blowfish.

https://www.php.net/manual/en/function.password-hash.php

There’s no option to use PBKDF2 (though I’m sure there are scripts that would achieve that), but it is definitely slow hash

[eddie5]

@sbecks, would we need to add a static salt phrase somewhere when using PASSWORD_DEFAULT from your above walk through?

I ask because about 11 minutes into webinar 3 about login/logout @Hyperbytes chooses the SHA256 hash and adds a salt of “wapplerrocks!”.

My assumption is that “wapplerrocks!” would be the salt used on every hashed user password in that database. Which doesn’t strike me as all that secure since that static salt phrase is probably sitting on the server somewhere. If someone gets that salt, along with the database, they’d (I assume) be able to decrypt every user password fairly quickly.

My guess is that bcrypt doesn’t require a static salt phrase, but want to be sure.

Thanks!

[kfawcett]

If you use the PHP password_hash function, it automatically generates a unique salt. You do not need to provide one.

And the example that @Hyperbytes provides in his wonderful tutorial should not be used for any serious web application. A salt should be random and the hash should be slow for the best security of passwords.

[eddie5]

Wappler doesn’t seem to currently offer any slow hash options like bcrypt, Argon2 or PBKDF2.

So what do Wapplers currently do when they’re building a serious web app that secures sensitive data? Do they have to manually implement some kind of hash workaround like the one @sbecks suggested above?

[kfawcett]

I built something based on @mebeingken’s helpful tips here. I also created a custom formatter to generate a unique salt, but now that @sbecks provided a way to setup the password_hash and password_verify functions I can simplify everything for future projects.

[George]

and we will definetaly integrate those solutions as built-in formatters in Wappler as well soon.

and also deliver more instructions to make custom formatters like this - but also add UI as well. The UI is a simple JSON file that describes the inputs.

[Hyperbytes]

The salt is stored on the server but in a secure manner, server side, in the same way as your database connections are stored. If an intruder gets that level of access to your server then frankly nothing will stop them getting your data

[patrick]

A nice blogpost how dropbox stores their passwords

https://blogs.dropbox.com/tech/2016/09/how-dropbox-securely-stores-your-passwords/

[eddie5]

@george, when you say “…integrate those solutions as built-in formatters…”, do you mean adding slow hash options (like bcrypt ) to Wappler’s current list of cryptographic options?

@Hyperbytes makes a fair point in regards to an intruder getting access to data once they have access to the server.

I assume encryption of that data at rest would help mitigate against that. Data in a Bubble app, for example, is encrypted at rest as Bubble databases are hosted on AWS RDS (which supports encryption of data at rest).

Other VPS providers like Digital Ocean also offer data encryption at rest (not sure if their standard Droplets offer it, but their managed database offerings do).

Would a web app built with Wappler currently be compatible with encrypting data at rest?

[patrick]

We plan to include the password_hash and password_verify methods from PHP to support bcrypt. We didn’t include it yet because there is no good implementation for ASP. But now we decided that we will release PHP or .NET specific actions and formatters instead of not releasing because one of the Server Models doesn’t support it.

With encrypting data at rest you also need to store the keys somewhere, normally outside of the database. So when there is a database dump they can’t do anything with the data without the encryption keys. Depending of the implementation, you can have hosted solutions that offer that in their plan and handle the encryption for you, or you could simply use the encrypt/decrypt formatters from Server Connect and handle it yourself. Even with having the keys directly in your Server Connect action files it adds an extra layer of protection, they need the database dump and the source code to get access to the data.

[eddie5]

In a scenario where the data encryption is being handled by a hosted solution like Digital Ocean Managed Databases, how is the Wappler built web app able to decrypt that data in order to display it in queries and whatnot? If those keys are stored outside the database then how does a Wappler app know how to decrypt the data in order to display it to the user?

[patrick]

The encryption of the data is managed on the server, you just use it like you normally would do, no need to decrypt the data yourself. It is often coupled to the user accounts, so depending on the user they can see the decrypted data. This doesn’t protect to sql injection. Also it is preferred to us a secure database connection using ssl.

How to Secure MySQL Managed Database Clusters | DigitalOcean Product...

[sbecks]

@George @patrick

That’s great news and a really helpful addition! Any chance you can add UUIDs too? They’re quite a common helper in other frameworks/packages and it would make transferring projects from elsewhere into Wappler much simpler.

[eddie5]

Thanks for the DO post on securing managed databases, @patrick . Very helpful!

In the post they talk about adding trusted sources…

You can enter Droplets, Kubernetes clusters, tags, or specific IP addresses. Entering a tag provides access to the database for any Droplets or Kubernetes nodes containing that tag. At this time, DigitalOcean Cloud Firewalls are not supported.

So basically I would add my DO Droplet as a trusted source. That’s the DO Droplet that was originally created by the Docker Machines Manager in Wappler.

But what about the database that Wappler’s Docker target tool originally created for that project? Is that the database that DO will “manage” for me. Or is the DO managed database a different database that I now have to get my Wappler project to speak to / work with?

[JonL]

Bcrypt and scrypt are no longer recommended password encryption methods.

Argon2 and specifically Argon2ID is now one of the recommended. Bindings available for php, classic asp, asp .net and nodejs