Comment 6 for bug 1337268

Here's my strong opinion about this ticket and some ideas of how we could address it.

* Any solutions based on guessing (any kinds of patterns etc.) what is secure information and what's not won't work out. Just because it's security and this is not a secure approach by definition.

Below are my ideas of how we could address it.

Client-side

An example of input data that we provide to Mistral in JSON format:
{
    "secure_key^&": {
 "key1": { "_secured": 1 },
 "key2": 2,
 "key3: 3
    }
}

So whenever we need to make something secure we just wrap a corresponding value with {"_secure": value} (we can use a different marker if needed). So the client knows that it needs to be passed to the server as a secure piece of information.

Server-side:

* We create a special data type (class SecuredData or Password) that has a string representation "*****"
* JSON SQLAlchemy type must account for this class and encode/decode info behind this class instances so that we don't keep passwords and other secure things in their original form in DB
* Every time we request a info via API we give only its string representation which is "*****"
* Every time in the server when we need to get a real value (to pass it to executor etc.) we extract a real value (i.e. using get_value() method)