One credential across two transports, and the weaker one set the level
- date
- 20260824 (decision), 20260907 (the leak it then prevented from being worse)
- what happened
- Some older management hardware in the power layer offered only cleartext management in practice, its SSH too old for modern clients, and Christoph decided on 20260824 to treat an isolated management network and per-device access control as the boundary. When SNMPv3 went out on 20260907, one credential set was initially used both on devices managed over SSH and on devices managed in clear text, putting a credential built for a protected transport on the wire in clear.
- what it cost
- One credential rotation, done as soon as the exposure was found.
- what changed
- The exposed credential was rotated, and credentials were split by transport, so that one used in clear text is never also used over a protected transport.
- the check now
- A secrets layout that makes each transport class visually distinct, and the standing rule that a credential is never reused across a device whose transport is cleartext.
The decision to accept cleartext management on that hardware was explicit. Its SSH offering was not meaningfully better than cleartext: old ciphers, or a host key type modern clients refuse outright, on firmware that will never be updated again. The boundary was an isolated management network plus per-device access control, not the wire protocol.
What it did not anticipate showed up a fortnight later. Rolling SNMPv3 out across the power hardware, it was convenient to use one credential set for everything that draws power in the rack. Some of those devices were managed over SSH, others in clear text. Using the same SNMPv3 secret on both meant that every time it was configured or verified on a cleartext device, a credential built for a protected transport travelled the wire in clear text.
The insight worth keeping is a property statement: “acceptable to send in clear” belongs to the credential, not to the device you happen to be using it on today. A secret’s protection level has to match its weakest intended transport, and the moment one secret spans two transports, the weaker one sets the level for both.
The fix is cheap if you do it before the rollout rather than after. Define credential classes by transport, give them names that make the class obvious at a glance in your secrets store, and never let a member of one class cross into the other’s territory. Node0 rotated the exposed secret the day the overlap was found, which is the only other part of this that has to happen quickly.
Source: node0 lessons v0.1, lesson 5.8. Sanitized: checklist v0.1, 20260921; secrets paths, addresses; voice pass 20260921; per-device-class detail removed 20260929. Part of oznog.com/node0.