StreamPass — passwords from the vault at the press of a button

The problem I'm trying to solve - or another project I am working on:

At my company, our DevOps and Product Support engineers log into customer environments every day — often Oracle schema passwords during installations, often deep inside nested RDP sessions. In a growing number of those customer environments, copy/paste is hard-blocked: the clipboard isn't passed through, and is sometimes actively blocked by the RDP client or by endpoint security. The current workaround is grim: you type the password by hand, once, into a Notepad window inside the customer environment, and paste it from there. Not just clumsy — at customers with session recording, the tape simply captures that password as an image. Nobody is happy about it.

What we do have: a central password vault. What it can't do: reliably type into one of these locked-down RDP sessions. KeePassXC's auto-type breaks in restricted customer RDPs; the internal tool can't talk to hardware at all.

StreamPass is my attempt to close that last mile: one press on a physical device = the password is typed as keystrokes into the focused window, with no clipboard, no visible intermediate step, and the central vault as the source of truth.

Two hardware routes

A key discovery during the research phase: not every "macro keypad" behaves the same way through RDP and restrictive customer environments. I distinguish two classes.

Class 1 — a real USB HID keyboard. The device itself identifies to Windows as a keyboard and sends keystrokes via the kernel driver path. To the OS, it's indistinguishable from a regular Logitech. For StreamPass, the chosen class-1 candidate is the Adafruit MacroPad RP2040 — 12 keys, OLED display, rotary encoder, around €60, programmable in CircuitPython or QMK, and interesting because it's open hardware, meaning we can flash our own firmware onto it.

Class 2 — a programmable HID device that requires host software. The device itself isn't a keyboard; a driver or plugin on the PC calls SendInput(). The long-standing assumption was that this route would be useless in restrictive RDP — the same reasons that auto-type fail should also apply here. Empirics disagree. Tested example: the Elgato Stream Deck Mini. Inside a customer RDP session where

Ctrl+V is hard-blocked on a password field, the Stream Deck "Text" action types the password just fine. The per-character SendInput stream on the host is pushed through by the RDP client as individual keypress events, and simply doesn't touch the clipboard block. That matters, because it opens the architecture up to the much richer Stream Deck ecosystem (six backlit screen keys, profiles, full plugin SDK).

The architecture

The Stream Deck plugin I have running now is deliberately passive: six keys, each tied to a "slot". A single external file is watched by the plugin via a file watcher. If the contents change — for instance because the central vault tooling has loaded a new customer profile — the labels on the Stream Deck and the passwords the keys will type update live. The plugin itself holds no customer context, no TTL, no MRU list. Everything about "which password belongs on the Stream Deck right now" lives outside the plugin, in the vault client (envisioned in production as a Vaultwarden wrapper tool running on the workstation).

This gives two things at once: the plugin stays simple and auditable (a dumb renderer), and the heavy, sensitive work lives in the vault layer where it belongs. The MacroPad firmware can implement the

exact same slot model — the slot source stays identical, only the output device changes.

Where it stands today

The Stream Deck plugin prototype is working. The slot-driven architecture is in place.

The MacroPad has it's own personal firmware already with a nice selection mode. It is terribly slow in loading the passwords from Vaultwarden CLI. I have a choice to make which is best to implement.

Why it might be interesting to others

The combination of "central vault + JIT typing via physical hardware" isn't an exotic niche — anyone working in locked-down customer environments knows this pain. The architectural choice to keep the hardware dumb and the vault side smart keeps the solution independent of the specific device: Stream Deck today, MacroPad tomorrow, something else the day after. And the empirical finding that Stream Deck SendInput drives straight through a copy/paste block is, I suspect, useful for more people than just me.

3 comments