[BUG] Improve exporting security

[Mephiles]

Currently exporting uses the user ID as the identifier which is comfortable but not secure.

New method:

• user enters a "password"
• that password is used as salt on user ID
• the user ID + salt is hashed (MD5 should be good enough)
• the hash is stored in Tt database and used in exporting/importing
• when user installs Tt on another machine then entering the same password will generate the same hash

Tt remote server uses whatever key is supplied for storing and retrieving data so no adjustments need to be made in the back-end.

Migration:

• background.js#78 has a specificMigration method (a similar method could be created ONLY if it's a migration not a new install)
  • if (no hash in database) -> check if user has stored data on server with their ID
    • if (user has data stored) -> generate hash-based on their user ID with no salt; save all data with the new hash; delete old data
• on Export page
  • if (hashedUserID == hashInDB) -> prompt user to set a salt -> transfer all data again

ToDo:

• [ ] New setting for the hash in database
• [ ] migration method in background.js
• [ ] data transferring method from one key to another
• [ ] Export page input box and warning message

[Sashank999]

Upon some inspection, this can't be purely done without any changes at the server. When the user accidentally inputs a wrong password(wrong salt), the server creates a new save data for the same user. If this happens many times, this would exploit the server's resources. Hence, I made a new plan.

Server maintains a file that has list of IDs of players who saved data on the server.
- To optimise it, I suggest to have the first two digits of User IDs as folder names and then a file in each folder which has the ID - hash mappings.
- (Please note that this idea is the same that **git** uses to optimise objects tracking)
- When searching, we could open the file in the folder that has first two digits as its name and then searching for ID in that folder's list file might make it faster.

When user ID in the request matches any one of the registered IDs,
- If the hash of the request **matches** the hash in the mappings, then **send the data** of the mapping.
- If the hash of the request **does not** match the hash in the mappings, then **send password doesn't match error**.

When user ID is not there in the server,
- Create a new mapping in the server in the file and store the data.

[Mephiles]

Instead of folders and files, I'd rather just use the json db I do already. But it's a great point and I'll figure smth out for the server-side.