Description

resolveOperatorSessionConnectAuth now allows the operator gateway session to connect using an explicit bootstrapToken whenever no stored operator device token exists.

This is risky because bootstrap/setup tokens are typically intended only for initial provisioning / seeding a device token, and may be:

• embedded in a setup QR / setup code
• shared more broadly during onboarding
• valid for longer than desired if not rotated

With this change:

• Input: auth.bootstrapToken (coming from setup code / onboarding config)
• Decision: if there is no stored operator token, the function returns a connect auth that includes bootstrapToken
• Sink: the operator GatewaySession will send auth.bootstrapToken in the connect request for role="operator" (see GatewaySession.buildConnectParams which serializes bootstrapToken into the auth object).

If the gateway server accepts bootstrap tokens for role=operator with operator scopes, a leaked bootstrap token could enable operator-level access (approvals/read/write and potentially secret-related scope) without the normal device-token approval/pairing path.

Vulnerable code (new behavior):

val explicitBootstrapToken = auth.bootstrapToken?.trim()?.takeIf { it.isNotEmpty() }
if (explicitBootstrapToken != null) {
  return NodeRuntime.GatewayConnectAuth(
    token = null,
    bootstrapToken = explicitBootstrapToken,
    password = null,
  )
}

Recommendation

Do not allow bootstrap/setup tokens to be used to authenticate an operator session unless they are explicitly designed/scoped for operator access.

Client-side hardening:

• Remove the operator bootstrap fallback and require either:
  • an explicit shared operator token/password, or
  • a stored operator device token (after approval/pairing)

For example:

​// Only allow explicit token/password for operator connect.
val storedToken = storedOperatorToken?.trim()?.takeIf { it.isNotEmpty() }
if (storedToken != null) {
  return NodeRuntime.GatewayConnectAuth(token = null, bootstrapToken = null, password = null)
}

​// Do NOT fall back to bootstrap for operator.
return null

Server-side defense-in-depth (recommended even if client is fixed):

• Reject bootstrap tokens for role="operator" or restrict them to minimal onboarding scopes.
• Ensure bootstrap tokens are short-lived, single-use, and rotated after pairing.

Description

PairingAutoRetryEffect starts an infinite loop that calls refreshGatewayConnection() every 6 seconds while the screen is STARTED and enabled.

The enabled condition is derived from gatewayStatusLooksLikePairing(statusText), which performs broad substring matching ("pair" / "approve") over statusText.

Security impact:

• Untrusted trigger: statusText is ultimately driven by gateway/network connection state/messages. A malicious gateway or on-path attacker that can influence displayed error/status text can keep it containing pair/approve, forcing the app to continuously reconnect.
• Unbounded retries: The loop has no maximum attempts and no backoff, generating persistent foreground network traffic and battery drain.
• Repeated auth/reconnect attempts: refreshGatewayConnection() calls connectWithAuth(..., reconnect = true) which reconnects both sessions using stored auth material, potentially causing account/device rate-limit lockouts on the gateway.

Vulnerable code:

internal fun gatewayStatusLooksLikePairing(statusText: String): Boolean {
  val lower = gatewayStatusForDisplay(statusText).lowercase()
  return lower.contains("pair") || lower.contains("approve")
}

LaunchedEffect(enabled, lifecycleStarted) {
  if (!enabled || !lifecycleStarted) {
    return@​LaunchedEffect
  }
  while (true) {
    delay(PAIRING_AUTO_RETRY_MS)
    onRetry()
  }
}

Recommendation

Avoid driving retry behavior from free-form/untrusted statusText, and bound retries.

Suggested fixes (combine as appropriate):

1. Use a structured error/state from the connection/auth layer (e.g., an enum like GatewayAuthState.PairingRequired) rather than substring matching.

2. Cap retries + exponential backoff + jitter and/or require explicit user action after some attempts.

Example (bounded + backoff):

LaunchedEffect(enabled, lifecycleStarted) {
  if (!enabled || !lifecycleStarted) return@​LaunchedEffect

  var attempt = 0
  while (enabled && lifecycleStarted && attempt < 10) {
    val backoffMs = (6_000L shl attempt.coerceAtMost(4)) // up to 96s
    delay(backoffMs)
    onRetry()
    attempt++
  }
}

3. Consider adding gateway-side rate limiting handling and surfacing a UI message when retries are paused.

No security concerns identified. The auto-retry path reuses the same stored credentials as a manual reconnect; no new credential exposure or auth bypasses are introduced.