Revert "security skill: encode live-audit lessons for no_password verification & remediation"

This reverts commit 1370ce6.

Author: BorisTyshkevich

altinity-expert-clickhouse/skills/altinity-expert-clickhouse-security/references/01-scope-and-safety.md

@@ -8,7 +8,7 @@ Use this section first for any live-system audit.
 - Do not run `CREATE`, `ALTER`, `DROP`, `TRUNCATE`, `INSERT`, `OPTIMIZE`, `SYSTEM`, `KILL`, `BACKUP`, `RESTORE`, or `SET` unless the user explicitly asks for a remediation command and understands it is not an audit probe.
 - Do not run network probes through table functions.
 - Do not use table functions to test whether exfiltration is possible.
-- Do not guess passwords or iterate credentials/usernames online. A *single* connection attempt as one specific, named account — e.g. confirming whether a `no_password` user actually logs in — is allowed **only with explicit owner authorization**; that is verification, not guessing. Never loop over passwords or user lists. See `04`.
+- Do not attempt online password guessing or authentication attempts.
 - Do not print secrets, password hashes, salts, or credential candidates.
 
 ## Initial evidence checklist

altinity-expert-clickhouse/skills/altinity-expert-clickhouse-security/references/04-definer-impersonation-principals.md

@@ -58,20 +58,6 @@ Rate:
 - **High by default — Critical if admin-equivalent (gate on reachability, `05`)** — a no_password account whose host ACL admits reachable sources (`::/0` or broad) and that holds meaningful grants. Anyone who reaches the port connects as it with no credential. Default `::/0` to reachable unless the perimeter is proven closed; the OAuth/proxy layer does not close it.
 - **Info / OK** — only when verified as a non-login principal: a definer/impersonation target with zero `LoginSuccess`, or a host ACL restricted to non-reachable sources. Grants matched to that definer/impersonation purpose are expected.
 
-## Confirm exploitability (authorized only)
-
-The definitive test of a `no_password` hole is a single passwordless connection as that exact account, from the relevant network position — **only with explicit owner authorization** (`01`). It is verification, not guessing: one named account, no password/user iteration. Read the response:
-
-- **Auth rejected** — `AUTHENTICATION_FAILED` / `Code 516 (... password is incorrect, or there is no user with such name)` → not exploitable as no_password (has a credential, or is gated/absent).
-- **Auth passed** — login succeeds, **or** a *post-authentication* error such as `Code 81: Database ... does not exist` (a missing `default_database`) → the credentials were accepted: this is a **live passwordless login**. Do not mistake a post-auth error for a failed login.
-- **No ClickHouse response** — connection dropped, `SSL connection unexpectedly closed`, or timeout → the port is not reachable from that position (perimeter-gated); the `::/0` ACL is not exploitable from there (`05`).
-
-## Remediation for a no_password login hole
-
-- **Definer/impersonation principal:** set a strong password (or restrict `host_ip` off `::/0`). The `SQL SECURITY DEFINER` mechanism uses the principal's grants, not a live login — the views keep working — so prefer this over dropping when objects depend on it.
-- **Before dropping or altering**, confirm the account is not your own session identity or a management/automation login (operator, MCP, BI service). Removing it can lock you or those tools out — verified the hard way.
-- **Operator-managed (Kubernetes/CHI) deployments:** apply the fix in the CHI users config, not just SQL — the operator may revert SQL-only user changes on its next reconciliation.
-
 ## Check: views using definer security
 
 ```sql

altinity-expert-clickhouse/skills/altinity-expert-clickhouse-security/references/05-network-exposure-and-tls.md

@@ -35,8 +35,6 @@ Do not flag broad private ranges automatically for cluster/service users; correl
 
 If a finding cannot state the principal's host restriction, that is a gap to report, not an omission to ignore.
 
-With explicit owner authorization, a single connection attempt resolves the `::/0` reachability question SQL cannot answer: any ClickHouse auth response (even a rejection) proves the port is reachable from that position, whereas a dropped/closed TLS connection (`SSL connection unexpectedly closed`) or timeout means the port is not exposed there (perimeter-gated). Field example: identical `::/0` `no_password` accounts were a live public hole on one cluster (native port answered) and inert on another (native port refused the TLS connection, fronted by an OAuth/nginx perimeter). Interpreting the auth response itself is covered in `04`.
-
 ## Check: ports, listeners, and TLS — config-only
 
 Listener and port configuration is **not** exposed in `system.server_settings`. On current versions (verified on 25.8) that table does **not** contain `listen_host`, `tcp_port`, `tcp_port_secure`, `http_port`, `https_port`, `mysql_port`, `postgresql_port`, `grpc_port`, or `interserver_http(s)_port`. So: