Centralise salt string references

Hi all,
A fairly simple request here. Now that we have Git support, I’m cautious about my salt strings being included as part of the repo, or being spread across so many files.

Specifically, it seems that the salt strings are stored within the generated dmxConnect PHP files. Would it be possible to move these out to a single config file? Having some way of reusing the salts would be quite nice as I bet that most people aren’t using different salts all the time. And if I share my project with others (via Github for example), I don’t want them to have to hunt down each PHP file and update it with their own salt (or update each reference within Wappler).

Interested to hear your thoughts on this.

Thanks in advance,

Hi Niall!

I think that the preferred method is to store the salt along side the hash inside the database. This is a pretty good description: https://www.codeproject.com/Articles/704865/Salted-Password-Hashing-Doing-it-Right

You want all the salt values to be different, otherwise it limits its protection value. For example for a user password hash, I generate a random string for each new user and use that as the salt when hashing. When updating the user record, I store the hash in one field, and the salt in other. Upon login, I lookup the users salt, and use that to prepare the comparison hash for a proper login. Salt is not meant to be a secret value, it just ensures that the exact same value (ie. password) does not result in the same hash.

And then of course, it keeps it out of the code, which you are rightly concerned with!


1 Like

Wow - awesome resource @mebeingken, many thanks for sharing. Forgive me, I’m still new - how exactly are you generating your salt string with Wappler? Thanks!

I suppose there are several ways, but this is what I went with:

I populate a database table with a set of random characters–I think I used 20 characters (some lowercase, some upper, special characters, and numbers). I then query that table, randomize the results, and throw in a timestamp for good measure.

{{TIMESTAMP}}{{saltChars.randomize().values().join("", "char")}}


Many thanks for your input on this @mebeingken

Hey @mebeingken, I would love to see a step-by-step for this! I’m having a heck of a time trying to set this up. :slight_smile:

How are you generating the random salt and then also using it for the hash while submitting a new user record?

Sure…see if these snips from our registration helps:


DB connection is a standard connection to db.

saltChars is a simple query to a database that has the following random content:

The salt value code is:

{{TIMESTAMP}}{{saltChars.randomize().values().join("", "char")}}

Validate Data just makes sure the email address is unique:

defaultTZ is just setting up a default time zone, so not really relevant for this…same with the defaultinstance and insertInstance actions.


And then you use a login action to actually log them in:

Login after reg

Again, standard db connector

GetSalt is just a query that retrieves the salt value stored for the user logging in…so lookup salt (I store that in a passsalt field) by email address, or username, or whatever.

instance again not relevant here.

And for Login, here is the code for the password:


I think that’s it…Looking at this now, I suppose you could just use a timestamp and then randomize those characters instead of looking up the salt characters, but this worked for my first salting attempt.



Is all javascript allowed? Could do something like these?

Math.random().toString(36).replace('0.', '')
crypto.getRandomValues(new Uint32Array(16))

I don’t know how you’d run that server-side.

Ugh, there’s so much I don’t know about Wappler. What are these functions? Are they custom from wappler?


For others that may stumble upon this, I’m not entirely sure why I couldn’t get the Query getSalt to work directly in the password field, but I did manage to perform a query, then I assigned that in a value using Set Value. Finally, I used the Set Value in the salt for sha256.


1 Like