"Hashing" is an encryption method, which changes a certain "input character string" (i.e. the plain text password) into a "encrypted / hashed fixed length output character string". This is a one way process (important!). You enter a password in plain text and the hash creates an image of it, an unreadable text. The image is what fw stores, not the password itself. The very important bit about the image is, that you can't convert it back into the password.
Before this change, user and system "owned" passwords were stored in plain text.
Example: user "Peter" has password "1".
Now, after "hashing" the same stored password image might look like this (fake info):
3db333eb08f6a48683fa41ff03a1873ce5aca2fba33a6d2393d3366341f4dba0c57d2b10a806d6646475c
The "salting" ensures that the same "input character string" will never result in the exact same "fixed length output character string" by randomly changing and adding data. The "salt" process ensures that 2 users with the same password won't every have the same "hash".
Using the above example, after the "salting" the same stored hashed password could look like this (fake info):
464a0e5b2d9056f8dc1b7cbc7365d8083464a0e5b2d9056f8dc1b7cbc7365d8083464a0e5b2d9056f8dc1b7cbc
464a0e5b2d9056f8dc1b7cbc7365d80837365d8083464a0e5b2d9056f8dc1b7cbc7365d8083
The upgrade process is NOT reversible. Once passwords are hashed&salted, it's not possible to roll this change back to "plain text" again within the DB files at rest on the disk. The hashing&salting process takes place once during the initial upgrade to v6.3. This could take some time, and depends heavily on how much entropy the host machine has and how many "users" exist within the DB.
It looks like this during the upgrade to v6.3 on the fw Server Log window (upgrade example from the DemoDB):
...
11919: 20170601:1358: [ DB_UPGRADE # PW_SEC_CONFIG ] Start Processing Users
11919: 20170601:1358: [ DB_UPGRADE # PW_SEC_CONFIG ] Done Anne In 248 ms
11919: 20170601:1358: [ DB_UPGRADE # PW_SEC_CONFIG ] Done Martin In 241 ms
11919: 20170601:1358: [ DB_UPGRADE # PW_SEC_CONFIG ] Done Lisa In 262 ms
11919: 20170601:1358: [ DB_UPGRADE # PW_SEC_CONFIG ] Done Steven In 254 ms
11919: 20170601:1358: [ DB_UPGRADE # PW_SEC_CONFIG ] Done Emma In 251 ms
11919: 20170601:1358: [ DB_UPGRADE # PW_SEC_CONFIG ] Done Fred In 252 ms
11919: 20170601:1358: [ DB_UPGRADE # PW_SEC_CONFIG ] Done Maria In 247 ms
11919: 20170601:1358: [ DB_UPGRADE # PW_SEC_CONFIG ] Done Dennis In 248 ms
11919: 20170601:1358: [ DB_UPGRADE # PW_SEC_CONFIG ] Done Peter In 254 ms
11919: 20170601:1358: [ DB_UPGRADE # PW_SEC_CONFIG ] Done Jo In 252 ms
11919: 20170601:1358: [ DB_UPGRADE # PW_SEC_CONFIG ] Done Jane In 249 ms
11919: 20170601:1358: [ DB_UPGRADE # PW_SEC_CONFIG ] Done Eric In 257 ms
11919: 20170601:1358: [ DB_UPGRADE # PW_SEC_CONFIG ] Done John In 254 ms
11919: 20170601:1358: [ DB_UPGRADE # PW_SEC_CONFIG ] End In 3 sec
11919: 20170601:1358: [ DB_UPGRADE # PW_SEC_CONFIG ] Start Processing Contacts
...
Deprecation Warning! The previously used "DIGEST" authentication method for the WebCal Event subscriptions is no longer supported! This is because "digest" requires the password to be in plain text to replicate the sum. Instead "BASIC" authentication method is now used.
MySQL data interface Warning. The definition of the "password" field in the "user" tables has changed its length from 32 to 128. And it no longer stores the plain password.
################
Hashed & Salted
We increased security due to user and system passwords being “hashed & salted”. Great… but what is the hash of a password?