Warn users about secret uniqueness and update README #39

New issue

Open

opened 2026-03-18 13:19:17 +00:00 by mahmoud · 1 comment

mahmoud commented

2026-03-18 13:19:17 +00:00

Owner

The current secret model uses the secret as both identity and access control. Two users who set the same secret can see and manage each other's VMs.

This is by design for simplicity but must be clearly communicated to users.

UI changes:

Auto-generate a secret on first visit instead of showing empty input — make
Generate the default action
Show warning when user manually types a secret shorter than 16 characters:
"⚠ This secret is too simple. Anyone who guesses it can access your VMs. Use
Generate for a secure secret."
Show warning when user types common words: basic check — if no numbers/symbols and length < 8, show the warning
In Settings page secret section, add a clear explanation:
"Your secret is your identity on this node.
It is used to access and manage your VMs.
Anyone with the same secret can see your VMs
— treat it like a private key, not a password
word. Always use the Generate button."

README update:
Add a Security section explaining:

The secret model (capability token)
Why generated secrets are important
That simple/common secrets create collision risk
Recommendation: always use generated secrets

The current secret model uses the secret as both identity and access control. Two users who set the same secret can see and manage each other's VMs. This is by design for simplicity but must be clearly communicated to users. UI changes: 1. Auto-generate a secret on first visit instead of showing empty input — make Generate the default action 2. Show warning when user manually types a secret shorter than 16 characters: "⚠ This secret is too simple. Anyone who guesses it can access your VMs. Use Generate for a secure secret." 3. Show warning when user types common words: basic check — if no numbers/symbols and length < 8, show the warning 4. In Settings page secret section, add a clear explanation: "Your secret is your identity on this node. It is used to access and manage your VMs. Anyone with the same secret can see your VMs — treat it like a private key, not a password word. Always use the Generate button." README update: Add a Security section explaining: - The secret model (capability token) - Why generated secrets are important - That simple/common secrets create collision risk - Recommendation: always use generated secrets

mahmoud commented

2026-03-23 01:30:27 +00:00

Author

Owner

Gap: No cross-explorer identity — secrets are local to each dashboard

Currently the secret is stored in the browser's localStorage and scoped to each dashboard independently. This breaks in a multi-node, multi-explorer setup:

User visits Explorer A, sets secret test, deploys VM-1 and VM-2
User visits Explorer B, sets secret test2, deploys VM-3 and VM-4
Now the user has 4 VMs spread across two explorers with two different secrets
There is no single view of all their VMs — each explorer only shows VMs matching its local secret

The secret was designed as a capability token, but in a fleet of explorers it becomes an identity fragmentation problem.

Proposed solution: A central identity layer sitting above all explorers. The user registers once and gets a single secret or token that works across all explorers. This could be:

A shared secret standard (user manually uses the same secret everywhere — simple but not enforced)
A keypair-based identity (public key = identity, private key signs access — aligns with ThreeFold's mnemonic model)
A central auth service (hero_identity) that all explorers validate against — single sign-on

The explorer already acts as the aggregation layer for nodes. Making it the identity boundary as well (Option D) would require the least new infrastructure — users register with one explorer and that explorer proxies access to all nodes using a unified identity.

This needs an architectural decision before implementation.

**Gap: No cross-explorer identity — secrets are local to each dashboard** Currently the secret is stored in the browser's localStorage and scoped to each dashboard independently. This breaks in a multi-node, multi-explorer setup: - User visits Explorer A, sets secret `test`, deploys VM-1 and VM-2 - User visits Explorer B, sets secret `test2`, deploys VM-3 and VM-4 - Now the user has 4 VMs spread across two explorers with two different secrets - There is no single view of all their VMs — each explorer only shows VMs matching its local secret The secret was designed as a capability token, but in a fleet of explorers it becomes an identity fragmentation problem. **Proposed solution:** A central identity layer sitting above all explorers. The user registers once and gets a single secret or token that works across all explorers. This could be: - A shared secret standard (user manually uses the same secret everywhere — simple but not enforced) - A keypair-based identity (public key = identity, private key signs access — aligns with ThreeFold's mnemonic model) - A central auth service (hero_identity) that all explorers validate against — single sign-on The explorer already acts as the aggregation layer for nodes. Making it the identity boundary as well (Option D) would require the least new infrastructure — users register with one explorer and that explorer proxies access to all nodes using a unified identity. This needs an architectural decision before implementation.