One-Time Share — self-destructing links

A partir da v4.6, o CipherVault entrega secret sharing auto-destrutivo no estilo Bitwarden Send e Keeper One-Time Share.

Caso de uso clássico: enviar uma credencial pra fornecedor externo sem provisionar account no tenant. Link expira por TTL ou por número de views — o que vier primeiro.

Modelo

Token 256-bit URL-safe gerado server-side (crypto.randomBytes)
TTL configurável até 30 dias max
Counter de views (1–N, default 3)
Revoke manual antes de expirar
Decay timer + view counter visíveis no preview público

+-----------------------------------------+
|  https://cv.acme.com.br/share/abc...    |
|                                         |
|  Senha do MySQL prod                    |
|  ---------------------------------------|
|  P@ssw0rd!2026...                       |
|  ---------------------------------------|
|  Expira em 2h 14min — restam 2 views    |
+-----------------------------------------+

Endpoints

Criar

curl -X POST https://cv.acme.com.br/share \
  -H "Authorization: Bearer $CV_TOKEN" \
  -d '{
    "secret_id": 1234,
    "ttl_minutes": 60,
    "max_views": 3
  }'
# → {
#     "id": 42,
#     "token": "abc123...",
#     "share_url": "https://cv.acme.com.br/share/abc123...",
#     "expires_at": "2026-05-22T18:00:00Z"
#   }

Consumir (público, sem auth)

curl https://cv.acme.com.br/share/abc123...
# → exibe valor + decrementa view counter
# Se views == 0 OU expires_at < now → 410 Gone

Listar (admin)

curl https://cv.acme.com.br/share \
  -H "Authorization: Bearer $CV_TOKEN"
# → [{ id, secret_id, expires_at, views_remaining, created_by, ... }]

Revogar

curl -X DELETE https://cv.acme.com.br/share/id/42 \
  -H "Authorization: Bearer $CV_TOKEN"

UI

Página dedicada /Share (v4.7):

Lista de shares ativos com countdown
Modal "Create share" com pickers de TTL + max_views
Botão copy URL (autoclear clipboard 30s)
Revoke inline

Segurança

Token entropy: 256 bits (crypto.randomBytes(32).toString('base64url')) — bruteforce impractical
No-cache headers no GET público pra evitar proxies caching
Audit log registra share.create, share.view, share.revoke mas NÃO loga o token plain (apenas share_id)
Decay e view counter são atomically decremented com lock pra evitar race condition de duplo consume

Limitações

ZK vaults: share precisa do plaintext server-side → recusa com ZkBoundaryViolation. Workaround: gere link assinado fora do CV.
No edit-after-create: TTL/max_views imutáveis depois de criado. Revoque e crie novo.
No password-protect ainda — roadmap. Hoje, security é só posse do token.

Quando usar Send vs Permission grant

Cenário	Use
Compartilhar uma credencial uma vez com pessoa externa	One-Time Share
Acesso recorrente, terceirizado, com audit por user	Provisione AppConnection + RBAC vault grant
Onboarding de novo dev no time	SSO + vault membership

Referências

backend/src/routes/share.js no repo do produto
Blog post v4.6
Comparação: Bitwarden Send, Keeper One-Time Share

Modelo​

Endpoints​

Criar​

Consumir (público, sem auth)​

Listar (admin)​

Revogar​

UI​

Segurança​

Limitações​

Quando usar Send vs Permission grant​

Referências​