Dropbox est avec chiffrement (entre moi et eux en HTTPS, puis chez Amazon aussi en AES256), le savez vous? soritr que c'est sans chiffrement fait juste rigoler vôtre interlocuteur, car vous ne dites pas de quel chiffrement plus mieux bien vous imaginez. Désolé je n'ai pas compris comment vôtre solution est plus chiffrée que chez Dropbox : du moment où il y a une interface web et que je rentre mon pass dans du Javascript récupéré sur un serveur, j'ai autant de sécurité qu'avec Dropbox.
Je vais essayer d'être plus clair.
Dropbox chiffre le transfert entre l'utilisateur et ses serveurs web (HTTPS) puis chiffre avant d'envoyer sur les serveurs de stockage (AES). Entre ces deux chiffrement Dropbox a accès à tous les fichiers de ses utilisateurs (et au mot de passe).
Personnellement cela me pose problème et donc je n'utilise pas Dropbox (ni ses concurrents qui procèdent de la même manière).
Ce que nous proposons c'est de chiffrer depuis l'ordinateur de l'utilisateur, et plus précisément, dans la version web, dans son navigateur. Donc oui, le chiffrement sera fait par du javascript qui viendra du serveur. Donc il y a un risque que le fichier javascript soit corrompu par un attaquant qui aurait réussi à accéder au serveur (qui n'est pas un moulin non plus) et à gagner des droits suffisants pour pouvoir modifier le bon fichier javascript. Comme je l'ai précisé dans un précédent message, il y a ce même risque avec les autres clients web (par ex, sauf erreur, SeaFile) et pour les clients lourds qui se mettent à jour automatiquement (rien empêche un attaquant de pousser une mise à jour qui lui permettrait de récupérer tous les identifiants et mot de passe.
Pour résumer nous avons une situation problématique (une entreprise à accès à toutes mes données) et une situation à risque (en cas d'attaque active contre le serveur, un attaquant peut accéder à mes données).
De notre côté, nous allons travailler à réduire un maximum ce risque. Mais même en attendant, personnellement, je préfère la 2e situation à la 1ère.
Et comme on vous l'a déjà fait remarquer, montrer vôtre incapacité à mettre vôtre démo en HTTPS
Pourquoi "incapacité" ?
Il me semble avoir expliqué dans un précédent commentaire que la chiffrement du HTTPS n'apporterait que bien peu de sécurité à des données qui sont déjà chiffrées en AES256.
Le HTTPS a un intérêt cette situation mais plutôt au niveau de l'authentification du serveur : pour éviter qu'un autre serveur se fasse passer pour le nôtre. Mais il s'agit d'un prototype, pas d'un service en production.
[^] # Re: Hmm
Posté par lupolibero . En réponse à la dépêche Un prototype de Lupo Libero. Évalué à 3.
Je vais essayer d'être plus clair.
Dropbox chiffre le transfert entre l'utilisateur et ses serveurs web (HTTPS) puis chiffre avant d'envoyer sur les serveurs de stockage (AES). Entre ces deux chiffrement Dropbox a accès à tous les fichiers de ses utilisateurs (et au mot de passe).
Personnellement cela me pose problème et donc je n'utilise pas Dropbox (ni ses concurrents qui procèdent de la même manière).
Ce que nous proposons c'est de chiffrer depuis l'ordinateur de l'utilisateur, et plus précisément, dans la version web, dans son navigateur. Donc oui, le chiffrement sera fait par du javascript qui viendra du serveur. Donc il y a un risque que le fichier javascript soit corrompu par un attaquant qui aurait réussi à accéder au serveur (qui n'est pas un moulin non plus) et à gagner des droits suffisants pour pouvoir modifier le bon fichier javascript. Comme je l'ai précisé dans un précédent message, il y a ce même risque avec les autres clients web (par ex, sauf erreur, SeaFile) et pour les clients lourds qui se mettent à jour automatiquement (rien empêche un attaquant de pousser une mise à jour qui lui permettrait de récupérer tous les identifiants et mot de passe.
Pour résumer nous avons une situation problématique (une entreprise à accès à toutes mes données) et une situation à risque (en cas d'attaque active contre le serveur, un attaquant peut accéder à mes données).
De notre côté, nous allons travailler à réduire un maximum ce risque. Mais même en attendant, personnellement, je préfère la 2e situation à la 1ère.
Pourquoi "incapacité" ?
Il me semble avoir expliqué dans un précédent commentaire que la chiffrement du HTTPS n'apporterait que bien peu de sécurité à des données qui sont déjà chiffrées en AES256.
Le HTTPS a un intérêt cette situation mais plutôt au niveau de l'authentification du serveur : pour éviter qu'un autre serveur se fasse passer pour le nôtre. Mais il s'agit d'un prototype, pas d'un service en production.