Le mot de passe d'application de l'utilisateur de destination

Pourquoi l'application en crée un

Un administrateur Nextcloud ne peut pas écrire dans les fichiers personnels d'un autre utilisateur via WebDAV. Ainsi, lorsqu'un job dont le Destination Type est Nextcloud User s'exécute en Migration ou en Migration de test, les fichiers sont écrits au nom de cet utilisateur, avec un mot de passe d'application que l'application crée pour l'exécution.

Uniquement pour ce type de job. Une Analyse n'écrit rien dans les fichiers de l'utilisateur et n'en reçoit aucun, pas plus qu'un job vers un Team Folder ou un partage de fichiers.
Un par exécution. Chaque mot de passe est créé pour une seule exécution et porte le nom SMART Migration run suivi du numéro de l'exécution.
Uniquement pour un administrateur. Le compte qui réclame le job doit être administrateur Nextcloud. Un membre d'un groupe choisi sous Qui peut utiliser l’application peut utiliser l'API de l'application, mais une réclamation faite par un tel compte ne reçoit aucun mot de passe.
Uniquement pour un utilisateur existant. Un job dont le Destination User n'est pas un utilisateur Nextcloud ne reçoit aucun mot de passe, et son exécution ne peut pas écrire.

La vie d'un mot de passe

Le mot de passe vit exactement aussi longtemps que l'exécution pour laquelle il a été créé.

Le serveur réclame le job
Le serveur SMART Migration demande à l'application le prochain job Prêt et envoie sa clé publique RSA avec la requête.
L'application crée le mot de passe
Une fois le job attribué de façon certaine, l'application crée un nouveau mot de passe d'application pour l'utilisateur de destination : 72 lettres et chiffres aléatoires issus du générateur aléatoire sécurisé de Nextcloud. L'application enregistre qu'elle en a délivré un pour l'exécution, jamais le mot de passe lui-même.
Il est chiffré et envoyé
Le mot de passe est chiffré avec la clé publique du serveur et renvoyé dans la réponse à la réclamation, encodé en Base64. Il n'est jamais envoyé en clair.
Le serveur écrit les fichiers
Le serveur déchiffre le mot de passe avec sa clé privée et se connecte à WebDAV en tant qu'utilisateur de destination pour écrire les fichiers.
L'application le révoque
Lorsque le serveur signale l'exécution comme Terminé ou Annulé, ou que le job est annulé, l'application révoque immédiatement le mot de passe. Une exécution supprimée, annulée en masse ou laissée en suspens par un serveur qui s'est arrêté est prise en charge par une tâche d'arrière-plan qui révoque, toutes les cinq minutes, chaque mot de passe dont l'exécution est terminée.

Le balayage nécessite les tâches d'arrière-plan de Nextcloud

Le balayage toutes les cinq minutes s'exécute comme l'une des tâches d'arrière-plan de Nextcloud. Réglez-les sur Cron sous Paramètres d'administration → Paramètres de base, afin qu'elles s'exécutent qu'une page soit ouverte ou non. Une exécution qui reste En cours conserve son mot de passe jusqu'à sa fin.

Comment il est protégé pendant le transfert

Le mot de passe ne circule qu'à l'intérieur de la réponse à la réclamation, chiffré avec une clé que seul le serveur SMART Migration peut déchiffrer. Quiconque lit cette réponse — dans un journal, dans un proxy qui inspecte le HTTPS ou dans une copie enregistrée de l'échange — ne voit qu'un texte chiffré.

Élément	Ce qui est utilisé
La clé du serveur	Une paire de clés RSA d'au moins 2048 bits, créée par le serveur SMART Migration. Seule la clé publique est envoyée, sous la forme `publicKey` : le Base64 de sa forme DER, ou PEM.
Chiffrement	RSA-OAEP avec SHA-1, réalisé par OpenSSL de PHP sur le serveur Nextcloud.
Pendant le transfert	Le texte chiffré, encodé en Base64, sous la forme `destinationUserAppPassword`, à l'intérieur de la connexion HTTPS que le serveur utilise déjà.
Déchiffrement	Le `CrypterObject` de PowerBuilder sur le serveur SMART Migration, avec la clé privée.

Pourquoi un chiffrement à clé publique. La clé publique n'est pas un secret : une requête et sa réponse capturées ensemble ne livrent toujours pas le mot de passe. Une clé partagée envoyée avec la requête voyagerait à côté du mot de passe qu'elle protège.
Pourquoi SHA-1 dans OAEP. OAEP avec SHA-1 est ce que le CrypterObject de PowerBuilder sait déchiffrer. La sécurité d'OAEP ne repose pas sur la résistance aux collisions de la fonction de hachage ; les faiblesses connues de SHA-1 en matière de collisions ne s'appliquent donc pas ici.
Pas de clé, pas de mot de passe. Une réclamation sans publicKey ne reçoit aucun mot de passe pour un tel job, et le journal Nextcloud en indique la raison. Une publicKey qui n'est pas une clé publique RSA d'au moins 2048 bits est refusée avant qu'aucun job ne soit pris.
En cas d'échec, tout se ferme. Si le mot de passe ne peut pas être chiffré, il est immédiatement révoqué et la réponse à la réclamation n'en contient aucun.

Sur le serveur SMART Migration

Le serveur crée sa paire de clés au démarrage d'un worker et ne conserve la clé privée qu'en mémoire. Il déchiffre le mot de passe juste avant de se connecter à WebDAV, et n'écrit jamais le mot de passe ni la clé privée dans ses journaux.

Ce qui est conservé, et où

Ni l'application ni Nextcloud ne conservent le mot de passe lui-même.

La liste des mots de passe d'application de Nextcloud le conserve comme tout mot de passe d'application : sous forme de hachage à sens unique, affiché dans Paramètres → Sécurité → Appareils & sessions de l'utilisateur pendant la durée de l'exécution.
L'application conserve une ligne par mot de passe délivré, avec l'exécution, l'utilisateur, la date de création et le compte qui a réclamé le job, afin de savoir quoi révoquer. La ligne est supprimée dès que le mot de passe est révoqué.
Le journal Nextcloud enregistre chaque mot de passe délivré et révoqué, avec l'utilisateur et l'exécution, au niveau Info, et chaque refus sous forme d'avertissement : absence de publicKey, réclamation par un compte qui n'est pas administrateur, utilisateur inexistant.

Ce à quoi il peut accéder, et ce à quoi il ne peut pas accéder

Un mot de passe d'application se connecte au nom de son utilisateur ; pendant la durée de l'exécution, il peut donc faire dans Nextcloud tout ce que cet utilisateur peut faire. Il n'est pas limité au dossier de destination du job.

Il ne peut pas accéder au stockage externe auquel l'utilisateur se connecte avec ses propres identifiants, ni aux fichiers chiffrés avec les clés personnelles de l'utilisateur : il est créé sans le mot de passe de connexion de l'utilisateur. Le chiffrement côté serveur avec la clé maîtresse ne pose pas de problème.
Sa durée de vie est courte. Il existe de la réclamation jusqu'à la fin de l'exécution, et seul le serveur SMART Migration peut le lire.

Contre quoi il protège, et contre quoi il ne protège pas

Le chiffrement tient le mot de passe à l'écart de tout ce qui se trouve entre l'application et la mémoire du serveur SMART Migration. Il ne protège pas contre une personne qui contrôle déjà l'une ou l'autre extrémité.

Protégé	Non protégé
La réponse à la réclamation écrite dans un journal, une capture destinée au support ou un fichier enregistré	Une personne qui contrôle le serveur SMART Migration pendant l'exécution : celui-ci détient la clé privée, et détient déjà les identifiants Microsoft 365
Un proxy ou un outil de supervision qui inspecte le trafic HTTPS	Un administrateur Nextcloud, qui peut de toute façon créer des mots de passe d'application pour n'importe quel utilisateur avec `occ`
Une requête et sa réponse capturées ensemble	Un mot de passe laissé par une exécution qui ne se termine jamais : il dure jusqu'à la fin de l'exécution

En révoquer un manuellement

L'utilisateur peut révoquer le mot de passe dans ses propres Paramètres → Sécurité → Appareils & sessions ; un administrateur peut le lister et le supprimer avec occ user:auth-tokens:list et occ user:auth-tokens:delete. L'exécution ne peut alors plus écrire dans les fichiers de l'utilisateur.

Voir aussi