The password is in your password manager, exactly where it should be. The login prompt is on a different device.
Perhaps you are preparing an Android device for a maintenance task. It needs one service password. You do not want to sign it into your email account or give it access to the rest of your password vault just to fill in that field.
Typing the password manually is an option. Sending it to yourself is another. Neither is particularly appealing when the value is long, the task is temporary, and you are trying to avoid creating unnecessary copies.
We build WithinCells at schukai for this kind of handoff. The question behind it is deliberately narrow: how do you get one secret onto the device that needs it, without setting up more access than the task requires?
Transfer is a different job from storage
I do not see a handoff tool as a replacement for a password manager. Your vault should remain the place where you organise and retrieve credentials. A transfer tool has a smaller job: help you deliver a selected value to a selected destination.
Where your existing password manager already handles that well, use it. There is no benefit in adding another application just to repeat a working process.
The interesting case is the exception: a temporary device, a one-off setup, or a login where the usual workflow is unavailable.
That is also where I would draw the line. Manually moving a credential for one maintenance task is different from distributing secrets across a fleet. For the latter, use managed provisioning and automated secrets management rather than scaling up manual transfers. OWASP recommends reducing human handling of secrets where possible.¹
The QR code is the package, not a download link
WithinCells uses QR-based device pairing. Transfers are encrypted for the chosen recipient and signed by the sender. In QR mode, the code holds the encrypted transfer itself, rather than a URL for retrieving it. The handoff needs neither a shared network nor a cloud account.²
That distinction is easier to understand by considering what would happen without encryption.
Imagine putting a password directly into a QR code. You would have made it easier to enter, but you would not have made it confidential. Someone who could read the code could read the password. The square pattern is a convenient carrier, not a security mechanism.
Encryption and signatures do different work. Encryption protects the contents. A correctly verified digital signature checks that the signed data came from the expected signing key and has not been altered. A signature does not, by itself, hide the data or prevent someone from presenting the same signed message again.³
There is a practical consequence: choosing and verifying the right recipient matters. Encryption cannot correct a decision to trust the wrong device.
After pairing, the basic QR workflow is to select the destination, prepare the transfer, and scan it on the receiving device. Show transfer codes for a direct scan; do not distribute screenshots or photographs.²
Receiving a password is not the same as entering it
A successful scan is only part of the task. The password still has to reach the intended input field.
On Android, WithinCells provides a keyboard for entering a received value once. Other output options include Auto-Type, Bluetooth keyboard output, and a temporary clipboard, depending on platform support.²
It helps to think of this as two separate operations. First, the receiving application gets the encrypted transfer. Then it supplies usable text to the application that needs it.
Those operations should not be treated as one uninterrupted encryption boundary. A keyboard-output path needs its own assessment. So does the destination application and any connection it uses to send the credential onward.
For clipboard use, Android documents version-dependent exposure risks and protective measures. Clearing copied content after a delay reduces its lifetime; it is not evidence that nothing read it before the delay elapsed.⁴
The same reasoning applies to the destination itself. If a compromised application receives the password, protecting its journey there does not make that application trustworthy. The software that handles the readable secret remains part of the security boundary.¹
A one-time transfer is not a one-time password
WithinCells applies expiry and replay protection to transfers on the receiving device. It does not invalidate the underlying password or token.²
Consider a hypothetical API token that remains valid for a day, delivered through a transfer that expires after a minute. Receiving the token during that minute does not shorten the token's lifetime. The service can still accept it for the remainder of the day.
There are two separate decisions: whether the receiving app accepts a transfer, and whether the service accepts a credential.
This is why deleting a message, expiring a sharing link, or clearing a clipboard should never be confused with revoking access. When a credential must stop working, it needs to expire, change, or be revoked in the system that validates it. OWASP treats revocation and expiration as explicit parts of a secret's lifecycle.¹
For an administrator, that distinction belongs in the procedure, not just in the documentation. “The transfer has been used” and “the account can no longer be accessed” are different outcomes.
Evaluate the whole handoff
For a first test, I would use a deliberately non-secret value such as demo-only-7Q!z@ and a disposable local text field.
Start by checking that the exact characters arrive. Then test the cases that a successful demonstration tends to skip: an expired transfer, an attempt to reuse a transfer, an interruption, and a restart of the receiving application. Check that rejection is clear and that an interruption does not leave you guessing whether the value was entered.
For keyboard-based output, use the same dummy value to test focus and keyboard layout. Getting text onto the correct machine is not enough if it lands in the wrong window or arrives with different characters.
Read the release notes for the platform you are evaluating. Keep any preview build restricted to test credentials, and apply your normal software-approval process before production use.
The useful question is not simply whether the QR scanner works. It is whether the entire task—from choosing the recipient to filling the field—is understandable and dependable in your environment.
A smaller task should need a smaller workflow
WithinCells for Android is available on Google Play. The project repository is at WithinCells releases.
What interests me about this problem is how little the destination actually needs. Being allowed to use one credential should not automatically mean being connected to all the accounts through which you could retrieve it.
That is the role I want a handoff tool to fill: keep using the password manager you trust, choose the value needed for the task, and make its delivery a deliberate step rather than an improvised message to yourself.
Which device-to-device handoff still leaves you typing a long password by hand?
Top comments (2)
Hello Glad to see you, I am Kane Lim from Hong Kong. I have over 10 years of development experience. I am writing this because your post was interesting.
The separation between secret storage and secret transport is exactly the right architectural distinction. I would push this further with capability based transfer semantics. Instead of treating the QR payload as merely encrypted data, model each handoff as a short lived capability containing recipient identity, nonce, expiry, intended operation, and replay counter.
The strongest design would use authenticated encryption with explicit domain separation, forward secrecy for ephemeral sessions, strict nonce management, and cryptographic erasure after successful delivery. On Android, I would isolate the receiving keyboard from persistent storage and aggressively minimize plaintext lifetime in memory.
For enterprise environments, the same protocol could integrate with hardware backed keystores and device attestation, allowing the sender to reject untrusted recipients before releasing the secret.
I particularly like your distinction between transfer expiry and credential revocation. That lifecycle boundary is frequently misunderstood. This is a genuinely useful security problem to solve, and I would enjoy exchanging ideas around the protocol design.
I need your assistance with one specific thing; would you please contact me? I really need your help.t_g_@kanelim1997