Protection par mot de passe : services de transfert comparés

La protection par mot de passe dans les services de transfert de fichiers va du cosmétique au cryptographiquement significatif. WeTransfer Pro ajoute une barrière de mot de passe vérifiée côté serveur avant de débloquer le téléchargement, mais le fichier reste déchiffrable par WeTransfer lui-même. Smash, SwissTransfer et Dropbox Transfer suivent un modèle similaire. Des services comme Tresorit Send et HexaTransfer utilisent le mot de passe (ou une clé dérivée) comme entrée du chiffrement réel des fichiers via PBKDF2 ou Argon2id, ce qui signifie que sans le mot de passe, le texte chiffré est mathématiquement illisible — même par le prestataire.

Barrières côté serveur ou clés cryptographiques

La distinction qui compte est l'endroit où le mot de passe est vérifié. Dans un modèle de barrière côté serveur, le prestataire stocke le hachage du mot de passe (espérons-le en bcrypt ou Argon2) et vérifie la valeur saisie avant de servir le fichier. Le fichier lui-même est chiffré avec une clé détenue par le prestataire. Si un attaquant compromet la base de données ou qu'un tribunal contraint le prestataire, les fichiers ressortent en texte clair quel que soit la force du mot de passe.

Dans un modèle à clé cryptographique, le mot de passe est traité par une fonction de dérivation de clé (KDF) — généralement PBKDF2 avec 600 000+ itérations ou Argon2id avec un coût mémoire ajusté — pour produire la clé de chiffrement effective du fichier. Sans mot de passe, pas de clé ; sans clé, pas de texte en clair. Le prestataire ne peut littéralement pas déchiffrer le fichier sans le mot de passe, même sur injonction judiciaire.

WeTransfer Pro : barrière pratique, pas du chiffrement

WeTransfer a introduit la protection par mot de passe sur les plans Pro (environ 10 €/mois). Saisissez un mot de passe lors de l'envoi, communiquez-le hors bande, le destinataire le tape sur la page de téléchargement. En coulisses, WeTransfer hache et compare — le fichier est chiffré AES-256 au repos avec des clés gérées par AWS KMS, non dérivées de votre mot de passe.

Cette conception convient à une protection basique contre le transfert accidentel de lien, mais elle ne satisfait pas les modèles de menace où vous ne faites pas confiance à WeTransfer lui-même ou à l'hébergeur. Elle est également vulnérable à la force brute en ligne, sauf si des limites de débit existent (WeTransfer ne documente pas publiquement ses limites de débit).

Smash : mot de passe plus vérification par e-mail

Smash propose une protection par mot de passe sur tous les plans payants. Ce qui est inhabituel, c'est la combinaison avec une vérification optionnelle de l'e-mail du destinataire. Vous pouvez exiger que le destinataire prouve être propriétaire d'une adresse e-mail spécifique (via un magic link) ET saisisse le mot de passe. Cela contrecarre l'attaque classique du lien transmis + mot de passe intercepté.

Le mot de passe reste une barrière côté serveur, pas une entrée de dérivation. Mais la saveur à deux facteurs (quelque chose que vous savez + quelque chose auquel vous avez accès) élève considérablement la barre. Pour envoyer des contrats à une partie spécifique, c'est un compromis raisonnable entre ergonomie et sécurité.

SwissTransfer : mot de passe optionnel simple

Le champ de mot de passe de SwissTransfer est optionnel et s'applique côté serveur. Le service est gratuit, sans compte requis, hébergé entièrement sur l'infrastructure suisse d'Infomaniak. Le mot de passe protège contre le partage accidentel de lien ; il ne modifie pas l'histoire du chiffrement (les fichiers sont en AES-256 au repos, avec des clés gérées par le service).

L'ergonomie est simple : une case à cocher, un champ de mot de passe, une confirmation. Pas de jauge de robustesse, pas d'application de complexité minimale. Vous pouvez taper « 123 » et ce sera accepté — ce qui signifie que le mot de passe n'est aussi solide que l'expéditeur le décide.

Dropbox Transfer : mots de passe avec politique admin

Dropbox Transfer sur Standard et au-dessus prend en charge les mots de passe avec une complexité minimale configurable par les administrateurs. Les administrateurs d'équipe peuvent exiger au moins 8 caractères, majuscules et minuscules, chiffres et symboles. La vérification du mot de passe se fait côté serveur avant que Dropbox ne serve le fichier depuis sa région américaine ou européenne (selon les paramètres d'équipe). L'intégration SSO SAML pour Dropbox Business remplace entièrement le flux de mot de passe par un accès vérifié par identité.

L'angle entreprise est la journalisation d'audit : chaque tentative de mot de passe est enregistrée, y compris les tentatives échouées qui pourraient indiquer une attaque par bourrage de credentials. Pour les preuves SOC 2 et ISO 27001, cette piste compte.

Tresorit Send : clé de chiffrement dérivée du mot de passe

Tresorit Send adopte l'approche cryptographique. Lorsque vous définissez un mot de passe, Tresorit le fait passer par PBKDF2 pour dériver une couche de chiffrement supplémentaire sur le fichier déjà chiffré. Sans le mot de passe, le fichier ne peut pas être déchiffré, même par Tresorit. L'entreprise est basée en Suisse avec la certification ISO 27001 et publie son livre blanc cryptographique.

Le comportement visible par l'utilisateur est similaire à WeTransfer : saisir un mot de passe, le partager. Mais les mathématiques sont fondamentalement différentes. Une violation de base de données chez Tresorit révèle du texte chiffré et des sels, pas des fichiers récupérables.

HexaTransfer : clé dans le fragment d'URL avec encapsulation optionnelle par mot de passe

Le modèle de base de HexaTransfer utilise une clé aléatoire de 256 bits intégrée dans le fragment d'URL (après #), que les navigateurs ne transmettent jamais au serveur. Cette clé déchiffre le texte chiffré AES-256-GCM côté client après le téléchargement. Lorsque vous ajoutez un mot de passe, PBKDF2 avec 600 000 itérations encapsule la clé aléatoire, nécessitant le mot de passe pour la déverrouiller et l'utiliser.

Cette approche en couches signifie que trois éléments doivent s'aligner pour le déchiffrement : le texte chiffré (du serveur), le fragment d'URL (depuis le lien) et le mot de passe (via un canal hors bande). Intercepter un seul de ces éléments ne donne rien. C'est un modèle exploré à l'origine par Firefox Send et affiné par les services modernes axés sur la confidentialité.

Tableau comparatif

| Service | Type de mot de passe | KDF | Force minimale | Limitation de débit | |---------|---------------------|-----|----------------|---------------------| | WeTransfer Pro | Barrière serveur | S/O | Non appliquée | Non documentée | | Smash | Barrière serveur + e-mail | S/O | Politique optionnelle | Oui | | SwissTransfer | Barrière serveur | S/O | Non appliquée | Oui | | Dropbox Transfer | Barrière serveur + SSO | S/O | Configurable admin | Oui | | Tresorit Send | KDF crypto | PBKDF2 | 8+ caractères | Oui | | HexaTransfer | KDF crypto | PBKDF2 600k | Appliquée | Oui |

Force du mot de passe et la question de l'entropie

Un « mot de passe fort » pour un transfert de fichiers devrait viser au moins 70 bits d'entropie — quatre mots aléatoires tirés d'un grand dictionnaire (style diceware) ou 12+ caractères aléatoires. PBKDF2 à 600 000 itérations ajoute environ 20 bits d'entropie effective contre les attaques hors ligne, portant un mot de passe modérément solide dans un territoire véritablement difficile à craquer.

Le maillon faible est généralement la transmission. Envoyer le mot de passe par SMS au même numéro que le lien annule l'intérêt. Utilisez un canal séparé : Signal pour le lien, un appel téléphonique pour le mot de passe, ou l'inverse. Pour les transferts B2B, coordonnez les mots de passe lors d'un appel vidéo existant plutôt que de créer de nouveaux canaux.

Quand un mot de passe ne suffit pas

Pour les transferts vraiment sensibles — documents de fusion-acquisition, code source, dossiers médicaux — envisagez de combiner la protection par mot de passe avec la vérification d'e-mail du destinataire, une expiration courte (24 heures) et des notifications de téléchargement. Mieux encore, utilisez un service avec authentification native du destinataire via magic link ou SSO.

La protection par mot de passe est une couche supplémentaire utile, pas un système complet de contrôle d'accès. Associez-la aux autres contrôles adaptés à votre modèle de menace, et ne supposez pas que la présence d'un champ de mot de passe signifie que le service lui-même ne peut pas lire vos fichiers — souvent, il le peut encore.

Essayez sur hexatransfer.com — gratuit, sans compte, jusqu'à 10 Go.