Why the app makes one
Section titled “Why the app makes one”A Nextcloud administrator cannot write into another user's own files over WebDAV. So when a job with Destination Type Nextcloud User runs as a Migration or Test Migration, the files are written as that user, with an app password the app makes for the run.
- Only for that kind of job. A Discovery writes nothing into the user's files and gets none, and neither does a job into a Team Folder or a file share.
- One per run. Each password is made for one run and is named
SMART Migration runand the run's number. - Only for an administrator. The account that claims the job must be a Nextcloud administrator. A member of a group chosen under Who can use the app may use the app's API, but a claim by such an account gets no password.
- Only for a user who exists. A job whose
Destination Useris not a Nextcloud user gets no password, and its run cannot write.
The life of one password
Section titled “The life of one password”The password lives exactly as long as the run it was made for.
The server claims the job
The SMART Migration server asks the app for the next Ready job and sends its RSA public key with the request.
The app makes the password
Once the job is surely handed out, the app makes a new app password for the destination user: 72 random letters and digits from Nextcloud's secure random generator. The app records that it issued one for the run, never the password itself.
It is encrypted and sent
The password is encrypted with the server's public key and goes back in the claim's answer, Base64-encoded. It is never sent in clear text.
The server writes the files
The server decrypts the password with its private key and signs in to WebDAV as the destination user to write the files.
The app revokes it
When the server reports the run Finished or Canceled, or the job is cancelled, the app revokes the password at once. A run deleted, cancelled in bulk or left behind by a server that stopped is caught by a background job that revokes every password whose run is over, every five minutes.
The sweep needs Nextcloud's background jobs
The five-minute sweep runs as one of Nextcloud's background jobs. Set them to Cron under Administration settings → Basic settings, so they run whether or not anyone has a page open. A run that stays Running keeps its password until it ends.
How it is protected on the way
Section titled “How it is protected on the way”The password travels only inside the claim's answer, encrypted with a key that only the SMART Migration server can undo. Anyone who reads that answer — in a log, a proxy that inspects HTTPS, or a saved copy of the conversation — sees only ciphertext.
| Part | What is used |
|---|---|
| The server's key | An RSA key pair of at least 2048 bits, made by the SMART Migration server. Only the public key is sent, as publicKey: Base64 of its DER form, or PEM. |
| Encryption | RSA-OAEP with SHA-1, done by PHP's OpenSSL on the Nextcloud server. |
| On the wire | The ciphertext, Base64-encoded, as destinationUserAppPassword, inside the HTTPS connection the server already uses. |
| Decryption | PowerBuilder's CrypterObject on the SMART Migration server, with the private key. |
- Why public-key encryption. The public key is no secret: a request and its answer captured together still do not give the password away. A shared key sent with the request would travel beside the password it protects.
- Why SHA-1 in OAEP. OAEP with SHA-1 is what PowerBuilder's
CrypterObjectdecrypts. OAEP's security does not rest on the hash's collision resistance, so SHA-1's known collision weaknesses do not apply here. - No key, no password. A claim without
publicKeygets no password for such a job, and the Nextcloud log says why. ApublicKeythat is not an RSA public key of at least 2048 bits is refused before any job is taken. - Failure closes. If the password cannot be encrypted, it is revoked at once and the claim's answer carries none.
On the SMART Migration server
The server makes its key pair when a worker starts and keeps the private key in memory only. It decrypts the password just before it signs in to WebDAV, and never writes the password or the private key to its logs.
What is kept, and where
Section titled “What is kept, and where”Neither the app nor Nextcloud keeps the password itself.
- Nextcloud's own list of app passwords keeps it as it keeps every app password: a one-way hash, shown in the user's Settings → Security → Devices & sessions while the run lasts.
- The app keeps one row per issued password, with the run, the user, when it was made and the account that claimed the job, so it knows what to revoke. The row is deleted once the password is revoked.
- The Nextcloud log records each password issued and revoked, with the user and the run, at the Info level, and every refusal as a warning: no
publicKey, a claim by an account that is not an administrator, a user who does not exist.
What it can and cannot reach
Section titled “What it can and cannot reach”An app password signs in as its user, so while the run lasts it can do in Nextcloud what that user can. It is not limited to the job's destination folder.
- It cannot reach external storage the user signs in to with their own credentials, nor files encrypted with the user's own keys: it is made without the user's login password. Server-side encryption with the master key is not a problem.
- It is short-lived. It exists from the claim until the run is over, and only the SMART Migration server can read it.
What it protects against, and what it does not
Section titled “What it protects against, and what it does not”The encryption keeps the password out of everything between the app and the SMART Migration server's memory. It does not defend against someone who already controls either end.
| Protected | Not protected |
|---|---|
| The claim's answer written to a log, a support capture or a saved file | Someone in control of the SMART Migration server while the run is going: it holds the private key, and already holds the Microsoft 365 credentials |
| A proxy or monitoring tool that inspects HTTPS traffic | A Nextcloud administrator, who can make app passwords for any user with occ anyway |
| A request and its answer captured together | A password left by a run that never ends: it lasts until the run is over |
Revoke one by hand
Section titled “Revoke one by hand”The user can revoke the password in their own Settings → Security → Devices & sessions; an administrator can list and delete it with occ user:auth-tokens:list and occ user:auth-tokens:delete. The run can then no longer write into the user's files.
See also