Update security note after further research.

CHANGELOG.md

@@ -11,8 +11,8 @@ Observes [Semantic Versioning](https://semver.org/spec/v2.0.0.html) standard and
 - Docker `dev` environment that supports hot reloading. PR #79
 - Documentation on setting up environments within `docker-compose` header. PR #79
 - `cascade` option for `/delete_tuple` route. (#86) PR #88
-- When delete with `cascade=False` fails due to foreign key relations, returns a HTTP error code of `409 Conflict` with a JSON body containing specfics of 1st child. (#86) PR #88
-- Documentation with detail regarding bearer token possible vulnerability (which contains database credentials) if hosted remotely. Recommend local deployment only for now. (#83) PR #88
+- When delete with `cascade=False` fails due to foreign key relations, returns a HTTP error code of `409 Conflict` with a JSON body containing specifics of 1st child. (#86) PR #88
+- Documentation with detail regarding warning on bearer token. (#83) PR #88
 
 ### Changed
 - Replaced `DJConnector.snake_to_camel_case` usage with `datajoint.utils.to_camel_case`. PR #88

pharus/server.py

@@ -68,12 +68,22 @@ def api_version():
 @app.route(f"{environ.get('PHARUS_PREFIX', '')}/login", methods=['POST'])
 def login():
     """
-    *WARNING*: Currently, this implementation exposes user database credentials in the bearer
-        token. This means it is not recommended for production use and should be avoided
-        unless clients are co-located with Pharus server. Secure certificates are highly
-        recommended (i.e. TLS/SSL) along with not exposing publicly the ports pointed to the
-        Pharus server. This issue is currently being tracked in
-        https://github.com/datajoint/pharus/issues/82.
+    *WARNING*: Currently, this implementation exposes user database credentials as plain text
+        in POST body once and stores it within a bearer token as Base64 encoded for subsequent
+        requests. That is how the server is able to submit queries on user's behalf. Due to
+        this, it is required that remote hosts expose the server only under HTTPS to ensure
+        end-to-end encryption. Sending passwords in plain text over HTTPS in POST request body
+        is common and utilized by companies such as GitHub (2021) and Chase Bank (2021). On
+        server side, there is no caching, logging, or storage of received passwords or tokens
+        and thus available only briefly in memory. This means the primary vulnerable point is
+        client side. Users should be responsible with their passwords and bearer tokens
+        treating them as one-in-the-same. Be aware that if your client system happens to be
+        compromised, a bad actor could monitor your outgoing network requests and capture/log
+        your credentials. However, in such a terrible scenario, a bad actor would not only
+        collect credentials for your DataJoint database but also other sites such as
+        github.com, chase.com, etc. Please be responsible and vigilant with credentials and
+        tokens on client side systems. Improvements to the above strategy is currently being
+        tracked in https://github.com/datajoint/pharus/issues/82.
     Login route which uses DataJoint database server login. Expects:
         (html:POST:body): json with keys
             {databaseAddress: string, username: string, password: string}