What part of a RADIUS packet does the shared secret actually hide, compared with a TACACS+ packet?

## What the RADIUS shared secret actually covers A RADIUS deployment configures a **shared secret** per network access server. That secret does two different jobs, and conflating them is the most common error in this answer. - **Confidentiality, for one attribute.** The secret is combined with the **Request Authenticator** to produce a keystream, and that keystream is combined with the **`User-Password`** attribute. That is the whole of the confidentiality story in classic RADIUS. - **Authenticity, for the exchange.** The same secret keys the check that lets a network access server satisfy itself that a reply came from the server it asked, and a separate attribute exists to authenticate a request. These are integrity mechanisms; they make tampering detectable, they do not make anything secret. Everything else in an `Access-Request` is plain: the **`User-Name`** identifying the account, the **`NAS-IP-Address`** identifying the device, and on the way back the authorization attributes such as **`Filter-Id`** or **`Session-Timeout`**. An observer on the path reads who is logging in, from which device, and what they were granted. Only the password itself is hidden. ## What TACACS+ masks, and what it does not TACACS+ takes the opposite approach to scope. The **12-byte header** — carrying the version, the packet type, `seq_no`, the flags byte, `session_id` and the body `length` — is always in the clear, because a receiver must read it to know what follows. Everything after it is combined with a pad derived from the shared secret and the header's own fields, so the account name, any prompt text, and the argument-value pairs describing a command are all masked together. What survives in the clear is still meaningful: - that this is TACACS+ on TCP port 49, and which of the three packet families this is; - the `session_id`, so packets can be grouped into exchanges; - `seq_no`, so an observer can count the round trips a login took; - the body `length`, which leaks the size of what was sent. That is enough for traffic analysis — how many exchanges a login needed, how many commands an operator ran and when — without reading one byte of the body. ## Side by side | | RADIUS (classic) | TACACS+ (classic) | |---|---|---| | Scope of hiding | one attribute, `User-Password` | the whole body after the header | | User name on the wire | readable | masked | | Authorization attributes | readable | masked | | Header | readable | readable | | The specification's own word | hiding a single attribute | **obfuscation**, explicitly not encryption | | Integrity of the hidden part | separate secret-keyed checks exist | none from the body protection itself | ## Why 'wider' is not 'stronger' The trap in this question is answering it as a security ranking. Two things are true at once. 1. **TACACS+ covers far more of the packet.** If your concern is that a capture reveals which accounts administer which devices and what they typed, TACACS+ genuinely addresses it and RADIUS genuinely does not. 2. **Neither classic mechanism is encryption in the sense a modern reader means.** RFC 8907 is unusually blunt about its own protocol here: the body protection is obfuscation. It gives no tamper-evidence of its own, and it offers no forward secrecy, so a shared secret recovered later opens captures taken earlier. A candidate who says 'TACACS+ encrypts the whole packet so it is the secure one' has stated the scope correctly and the strength wrongly, and an interviewer probing this leaf is usually probing exactly that seam. ## What follows operationally - Both classic transports are normally confined to a management path rather than run across general-purpose networks, precisely because so little is protected and nothing is forward secret. - The remedy on each side is the same idea: put the exchange inside a real record-protection layer. TACACS+ has a TLS 1.3 transport defined for it on a separate well-known port, and RADIUS has TLS and DTLS transports defined against its UDP original. Those change the answer to this question completely, which is why saying *which* transport you mean is part of answering it. - Rotating a shared secret matters more than it looks, because without forward secrecy the value protects the past as well as the present. ## The shape of a good answer Name the scope on each side, name one thing that stays readable on each side, and then supply the correction the interviewer is waiting for: the TACACS+ advantage is breadth of coverage, and the specification itself declines to call it encryption.