1/ comme confirmé dans la section 9, c'est optionnel
2/ la section 6 précise bien qu'il faut apporter un soin particulier à ces fichiers exportés en terme de sécurité
3/ c'est à l'implémentation du serveur de décider comment stocker les mots de passe: tout comme Prosody laisse le choix aux administrateurs de stocker le mot de passe sous forme de hash, en clair, dans un fichier texte, en base de données, etc., le protocole laisse à l'implémentation du serveur la liberté de s'adapter à son cas d'usage spécifique
Donc un serveur qui veut respecter la confidentialité de ses utilisateurs, et sait pertinemment que la sécurité absolue n'existe pas, stockera le mot de passe sous forme de hash et ne l’inclura pas dans le fichier d'export.
À l'inverse, un serveur qui cible les entreprises trop number one en sécurité, leader sur leur marché, persuadées d'être à l'abri derrière leur firewall cisco dernier cri à 1M d'€ et qui veut laisser la possibilité à ses administrateurs de fliquer ses utilisateurs stockera tout ça en clair et exportera le mot de passe de la même façon
Le protocole n'a pas à préjuger du type d'utilisation qu'on en fera et doit rester flexible: j'imagine que la XSF, qui décide de ce que contiennent les XEP, inclut des organisations dont la sécurité n'est pas l'objectif premier... Il faut donc forcément faire des compromis.
[^] # Re: Configuration serveur et écosystème de clients
Posté par Anonyme . En réponse à la dépêche Messagerie instantanée : ce n’est pas une question d’applications. Évalué à 3.
1/ comme confirmé dans la section 9, c'est optionnel
2/ la section 6 précise bien qu'il faut apporter un soin particulier à ces fichiers exportés en terme de sécurité
3/ c'est à l'implémentation du serveur de décider comment stocker les mots de passe: tout comme Prosody laisse le choix aux administrateurs de stocker le mot de passe sous forme de hash, en clair, dans un fichier texte, en base de données, etc., le protocole laisse à l'implémentation du serveur la liberté de s'adapter à son cas d'usage spécifique
Donc un serveur qui veut respecter la confidentialité de ses utilisateurs, et sait pertinemment que la sécurité absolue n'existe pas, stockera le mot de passe sous forme de hash et ne l’inclura pas dans le fichier d'export.
À l'inverse, un serveur qui cible les entreprises trop number one en sécurité, leader sur leur marché, persuadées d'être à l'abri derrière leur firewall cisco dernier cri à 1M d'€ et qui veut laisser la possibilité à ses administrateurs de fliquer ses utilisateurs stockera tout ça en clair et exportera le mot de passe de la même façon
Le protocole n'a pas à préjuger du type d'utilisation qu'on en fera et doit rester flexible: j'imagine que la XSF, qui décide de ce que contiennent les XEP, inclut des organisations dont la sécurité n'est pas l'objectif premier... Il faut donc forcément faire des compromis.