When retrieving a Password property via rest API, the value is intentionally obscured.

If that value is round-tripped back to the rest API, the obscured value
looks like it is set as the password. This is bad since the obscured
phrase is predictable.

One way to handle this is to block read access to any password field in the schema
permissions.

For example using:

 user = db.security.addPermission(name='View', klass='user', check=own_record,
    properties=('username', 'address', 'realname', 'phone',         
        'organisation', 'alternate_addresses', 'queries', 'timezone'),          
    description="User is allowed to view their own user details")

in schema.py to replace the user View permission should prevent a GET rest request with
query params that include '@verbose=0&@protected=true' from including the password
property in the returned response.

(The 'password' property should be left in the user Edit permission definition so a
password can be changed remotely.)

I was expecting the password.py::Password:__init__ to fail when processing the obscured
phrase. The obscured phrase is passed via the 'encrypted' parameter to __init__.
Then __init__ parses the encrypted property splitting off the encryption algorithm,
params (salt) etc.

However if it fails, it takes the encrypted value and uses it as a plain text value that
it encrypts and returns to the caller. I think this a bug in the Password module. I claim
it should not accept an invalid encrypted value.  Note that "encrypted" can be '{plaintext}my plaintext password' but must include the encryption format label.

This is kind of an edge case as it involves using the password property via rest.
But it does stop round tripping the rest item retrieved by a GET request to the rest API
with '@verbose=0&@protected=true' query params.

See also: issue 2551437 to clean up handling of reserved properties when round-tripping
API responses.

One addition. In the properties example for view properties, you need to include the 'activity' property. Otherwise the collision detection that uses the last activity property is set
to '[hidden]' and you can't submit any web form as hidden is not a valid date.