Out of band, in plain language
The term comes from telephone engineering, where mixing your control signals in with your data turned out to be an expensive mistake.
"Out of band" is one of those phrases that sounds like jargon invented to make a simple idea sound clever. It is not. It describes a specific structural property, it came from a real and costly engineering failure, and once you see it you start noticing it everywhere.
The phone network learned this the hard way
Early long-distance telephone systems carried their control signals on the same channel as the conversation. The tones that told the network to connect a call, release a trunk or start billing travelled down the same wire as your voice, in the audible range. This was called in-band signalling, and it was elegant: no extra infrastructure required.
It was also a gift to anyone who worked out which tones did what. A 2600 Hz tone told the network that a trunk line was idle. Produce that tone into the handset mid-call and the network believed the call had ended, while the line stayed open - at which point further tones could direct it anywhere, unbilled. People built devices to do this. For a while, a toy whistle from a cereal box produced the tone well enough.
The fix was not better tone detection or a secret frequency. It was structural: move signalling onto a separate channel that carries no user data, so that nothing a caller transmits can be mistaken for an instruction. That is out-of-band signalling, and it is how the phone network has worked ever since.
The same shape, everywhere
The general principle: when control and content share a channel, content can impersonate control. Keeping them separate removes an entire class of problem rather than defending against each instance of it.
SQL injection is the same failure - query structure and user data concatenated into one string, so data can become instruction. Prepared statements are the out-of-band fix: the query goes one way, the parameters go another, and no amount of quoting in the input can change the shape of the query.
What it means for sending a secret
In security practice the phrase has come to mean something narrower and more practical: do not send the credential on the channel that the credential is for.
Concretely, these are all in-band, and all common:
- Emailing someone their email password.
- Pasting a production key into the Slack channel where the incident is being run.
- Putting a database password in the ticket that describes the database.
The problem is not that these channels are insecure in transit - they are usually encrypted. The problem is that they are durable and broad. The message stays in the thread, gets indexed, joins the search results, survives in backups, and remains readable by everyone who later joins that channel. The credential outlives the reason it was shared, in a place chosen for convenience rather than for holding secrets.
What this service does with it
OOBSecret is a second channel that exists only to carry the secret and then stop existing. The conversation keeps the context - what the credential is for, who needs it, what to do with it - and the secret itself travels separately, in something that expires.
The passphrase option extends the same idea one step further. If the link goes over Slack, send the passphrase by text message or say it out loud. Now an attacker needs to compromise two unrelated channels rather than one, and the effort goes up by far more than double.
This is also the reason we do not send the email for you. The moment we deliver the message, we become the channel and the separation collapses. Handing you a template to paste keeps the two paths genuinely independent.