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?
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
1 Like
@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!
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.
1 Like
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?
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.
1 Like
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.
4 Likes
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
1 Like
A nice blogpost how dropbox stores their passwords
https://blogs.dropbox.com/tech/2016/09/how-dropbox-securely-stores-your-passwords/
4 Likes
@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?
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.
5 Likes
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?
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.
1 Like
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.
4 Likes
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?
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 
2 Likes
Hi, @patrick and @George!
Any news regarding including bcrypt in Wappler?
I’m worried about more and more people using SHA for encrypting passwords with Wappler which may if future cause a security breaches in the SW produced with Wappler, which may ruin Wappler reputation at some day. Seriously)
I think It’s better having this out-of-the box.
Yes, it’s coming to Wappler later today 
8 Likes
Wow!!!