j'ai envie d'utiliser une partie d'un espace web pour stocker des
fichiers sensibles.
je protège cet espace avec un .htaccess qui exige un seul utilisateur
et un mot de passe complexe.
que vaut cette protection au bout du compte, quels sont les risques de
se faire hacker cet hébergement (aspirateurs de site, robots, attaques
diverses et variées, etc trucs auquels je ne pense pas car assez
novice)
en bref, quelles sont les faiblesses d'une protection via un htaccess?
merci d'avance pour vos idées et vos remarques éventuelles avant de
mettre en place :-)
--
Aimez-moi, ne m'imposez pas! (Dieu)
tranquille.xav@gmail.com
Le 31/12/2010 11:25, Jean-Francois Ortolo a écrit :
Bonjour
Seule possibilité : Se faire "sniffer" le mot de passe puisque celui-ci circule en clair sur le réseau ainsi que le login.
Oui et non. htaccess définit le comportement. Il suffit d'utiliser htdigest pour que les échanges se fassent de manière chiffrer.
j'ai regardé et pas sûr que je puisse utiliser ce module sur un serveur mutualisé... mais je regarderai de plus près...
C'est beaucoup, beaucoup, beaucoup plus sûr que l'authentification par défaut de Apache, qui est effectivement en clair.
ok je comprends, c'est intéressant à savoir :-) ... ok pour le reste
-- Il faut avant tout travailler ses points forts. (Réflexion)
Olivier Masson
Le 05/01/2011 19:45, a écrit :
*Ecrit* *par* *Olivier Masson*:
Le 31/12/2010 11:25, Jean-Francois Ortolo a écrit :
Bonjour
Seule possibilité : Se faire "sniffer" le mot de passe puisque celui-ci circule en clair sur le réseau ainsi que le login.
Oui et non. htaccess définit le comportement. Il suffit d'utiliser htdigest pour que les échanges se fassent de manière chiffrer.
j'ai regardé et pas sûr que je puisse utiliser ce module sur un serveur mutualisé... mais je regarderai de plus près...
C'est beaucoup, beaucoup, beaucoup plus sûr que l'authentification par défaut de Apache, qui est effectivement en clair.
ok je comprends, c'est intéressant à savoir :-)
Sauf que j'ai oublié le reste de ce que je voulais dire :) Donc je reprends : c'est bcp plus sûr... mais ça reste, selon le contexte, trop faible pour assurer une sécurité digne de ce nom. Cela dit, htdigest utilisé avec un long et complexe mot de passe (>12 caractères avec toutes sortes de signes), c'est déjà très bien.
Le 05/01/2011 19:45, Tr@nquille a écrit :
*Ecrit* *par* *Olivier Masson*:
Le 31/12/2010 11:25, Jean-Francois Ortolo a écrit :
Bonjour
Seule possibilité : Se faire "sniffer" le mot de passe puisque celui-ci
circule en clair sur le réseau ainsi que le login.
Oui et non. htaccess définit le comportement. Il suffit d'utiliser
htdigest pour que les échanges se fassent de manière chiffrer.
j'ai regardé et pas sûr que je puisse utiliser ce module sur un serveur
mutualisé... mais je regarderai de plus près...
C'est beaucoup, beaucoup, beaucoup plus sûr que l'authentification par
défaut de Apache, qui est effectivement en clair.
ok je comprends, c'est intéressant à savoir :-)
Sauf que j'ai oublié le reste de ce que je voulais dire :)
Donc je reprends : c'est bcp plus sûr... mais ça reste, selon le
contexte, trop faible pour assurer une sécurité digne de ce nom.
Cela dit, htdigest utilisé avec un long et complexe mot de passe (>12
caractères avec toutes sortes de signes), c'est déjà très bien.
Le 31/12/2010 11:25, Jean-Francois Ortolo a écrit :
Bonjour
Seule possibilité : Se faire "sniffer" le mot de passe puisque celui-ci circule en clair sur le réseau ainsi que le login.
Oui et non. htaccess définit le comportement. Il suffit d'utiliser htdigest pour que les échanges se fassent de manière chiffrer.
j'ai regardé et pas sûr que je puisse utiliser ce module sur un serveur mutualisé... mais je regarderai de plus près...
C'est beaucoup, beaucoup, beaucoup plus sûr que l'authentification par défaut de Apache, qui est effectivement en clair.
ok je comprends, c'est intéressant à savoir :-)
Sauf que j'ai oublié le reste de ce que je voulais dire :) Donc je reprends : c'est bcp plus sûr... mais ça reste, selon le contexte, trop faible pour assurer une sécurité digne de ce nom. Cela dit, htdigest utilisé avec un long et complexe mot de passe (>12 caractères avec toutes sortes de signes), c'est déjà très bien.
Tr
*Ecrit* *par* *Olivier Masson*:
Le 05/01/2011 19:45, a écrit :
*Ecrit* *par* *Olivier Masson*:
Le 31/12/2010 11:25, Jean-Francois Ortolo a écrit :
Bonjour
Seule possibilité : Se faire "sniffer" le mot de passe puisque celui-ci circule en clair sur le réseau ainsi que le login.
Oui et non. htaccess définit le comportement. Il suffit d'utiliser htdigest pour que les échanges se fassent de manière chiffrer.
j'ai regardé et pas sûr que je puisse utiliser ce module sur un serveur mutualisé... mais je regarderai de plus près...
C'est beaucoup, beaucoup, beaucoup plus sûr que l'authentification par défaut de Apache, qui est effectivement en clair.
ok je comprends, c'est intéressant à savoir :-)
Sauf que j'ai oublié le reste de ce que je voulais dire :) Donc je reprends : c'est bcp plus sûr... mais ça reste, selon le contexte, trop faible pour assurer une sécurité digne de ce nom. Cela dit, htdigest utilisé avec un long et complexe mot de passe (>12 caractères avec toutes sortes de signes), c'est déjà très bien.
si j'ai bien compris, la différence entre htpasswd et htdigest, c'est qu'avec le premier les échanges d'authentification se font en clair alors qu'avec le ssecond elles sont cryptées c'est ça?
ok pour la sécurité assez faible, mais finalement, ce que j'ai à déposer n'est pas non plus si critique, le seul gros risque j'ai l'impression serait la malversation d'un employer de mon hébergeur. il me faudrait un ftp qui crypte à l'envoi pour le stockage sur serveur et décrypte à la réception... uniquement sur certains dossiers en plus.
ou le vol de mon authetification sur un poste corrompu, à moi d'être vigilant sur ce problème. je vais essayer le mod htdigest chez mon hébergeur pour voir...
-- Il faut avant tout travailler ses points forts. (Réflexion)
*Ecrit* *par* *Olivier Masson*:
Le 05/01/2011 19:45, Tr@nquille a écrit :
*Ecrit* *par* *Olivier Masson*:
Le 31/12/2010 11:25, Jean-Francois Ortolo a écrit :
Bonjour
Seule possibilité : Se faire "sniffer" le mot de passe puisque
celui-ci
circule en clair sur le réseau ainsi que le login.
Oui et non. htaccess définit le comportement. Il suffit d'utiliser
htdigest pour que les échanges se fassent de manière chiffrer.
j'ai regardé et pas sûr que je puisse utiliser ce module sur un
serveur
mutualisé... mais je regarderai de plus près...
C'est beaucoup, beaucoup, beaucoup plus sûr que l'authentification
par
défaut de Apache, qui est effectivement en clair.
ok je comprends, c'est intéressant à savoir :-)
Sauf que j'ai oublié le reste de ce que je voulais dire :)
Donc je reprends : c'est bcp plus sûr... mais ça reste, selon le
contexte, trop faible pour assurer une sécurité digne de ce nom.
Cela dit, htdigest utilisé avec un long et complexe mot de passe (>12
caractères avec toutes sortes de signes), c'est déjà très bien.
si j'ai bien compris, la différence entre htpasswd et htdigest, c'est
qu'avec le premier les échanges d'authentification se font en clair
alors qu'avec le ssecond elles sont cryptées c'est ça?
ok pour la sécurité assez faible, mais finalement, ce que j'ai à
déposer n'est pas non plus si critique, le seul gros risque j'ai
l'impression serait la malversation d'un employer de mon hébergeur.
il me faudrait un ftp qui crypte à l'envoi pour le stockage sur serveur
et décrypte à la réception... uniquement sur certains dossiers en plus.
ou le vol de mon authetification sur un poste corrompu, à moi d'être
vigilant sur ce problème.
je vais essayer le mod htdigest chez mon hébergeur pour voir...
--
Il faut avant tout travailler ses points forts. (Réflexion)
tranquille.xav@gmail.com
Le 31/12/2010 11:25, Jean-Francois Ortolo a écrit :
Bonjour
Seule possibilité : Se faire "sniffer" le mot de passe puisque celui-ci circule en clair sur le réseau ainsi que le login.
Oui et non. htaccess définit le comportement. Il suffit d'utiliser htdigest pour que les échanges se fassent de manière chiffrer.
j'ai regardé et pas sûr que je puisse utiliser ce module sur un serveur mutualisé... mais je regarderai de plus près...
C'est beaucoup, beaucoup, beaucoup plus sûr que l'authentification par défaut de Apache, qui est effectivement en clair.
ok je comprends, c'est intéressant à savoir :-)
Sauf que j'ai oublié le reste de ce que je voulais dire :) Donc je reprends : c'est bcp plus sûr... mais ça reste, selon le contexte, trop faible pour assurer une sécurité digne de ce nom. Cela dit, htdigest utilisé avec un long et complexe mot de passe (>12 caractères avec toutes sortes de signes), c'est déjà très bien.
si j'ai bien compris, la différence entre htpasswd et htdigest, c'est qu'avec le premier les échanges d'authentification se font en clair alors qu'avec le ssecond elles sont cryptées c'est ça?
ok pour la sécurité assez faible, mais finalement, ce que j'ai à déposer n'est pas non plus si critique, le seul gros risque j'ai l'impression serait la malversation d'un employer de mon hébergeur. il me faudrait un ftp qui crypte à l'envoi pour le stockage sur serveur et décrypte à la réception... uniquement sur certains dossiers en plus.
ou le vol de mon authetification sur un poste corrompu, à moi d'être vigilant sur ce problème. je vais essayer le mod htdigest chez mon hébergeur pour voir...
-- Il faut avant tout travailler ses points forts. (Réflexion)
Olivier Masson
Le 06/01/2011 09:58, a écrit :
si j'ai bien compris, la différence entre htpasswd et htdigest, c'est qu'avec le premier les échanges d'authentification se font en clair alors qu'avec le ssecond elles sont cryptées c'est ça?
Oui voilà (mais on dit "chiffrées", pas "cryptées"), en MD5 (qui n'est pas en fait un algo de chiffrement mais de hashage d'ailleurs, d'où la faiblesse de processus.) Mais après ton authentification, si tu n'es pas en https, tout continue de circuler en clair.
ok pour la sécurité assez faible, mais finalement, ce que j'ai à déposer n'est pas non plus si critique, le seul gros risque j'ai l'impression serait la malversation d'un employer de mon hébergeur.
En mutualisé, tu auras toujours un (petit) risque.
il me faudrait un ftp qui crypte à l'envoi pour le stockage sur serveur et décrypte à la réception... uniquement sur certains dossiers en plus.
En admettant que ça existe, c'est impossible en mutualisé puisque tu utilises leur serveur ftp. Mais j'imagine qu'il est possible de créer facilement un outil en PHP, Python, Ruby, etc. En PHP, les fonctions mcrypt sont là pour ça. Si tu as accès aux commandes shell et que mcrypt est installé (on peut rêver), ça sera probablement (beaucoup ?) plus rapide.
ou le vol de mon authetification sur un poste corrompu, à moi d'être vigilant sur ce problème.
C'est toujours le maillon faible. Pour les données sensibles et les risques à l'authentification, on utilise un mécanisme OTP (one time password : un mot de passe unique pour chaque authentification, donné par SMS, email, token...)
Le 06/01/2011 09:58, Tr@nquille a écrit :
si j'ai bien compris, la différence entre htpasswd et htdigest, c'est
qu'avec le premier les échanges d'authentification se font en clair
alors qu'avec le ssecond elles sont cryptées c'est ça?
Oui voilà (mais on dit "chiffrées", pas "cryptées"), en MD5 (qui n'est
pas en fait un algo de chiffrement mais de hashage d'ailleurs, d'où la
faiblesse de processus.)
Mais après ton authentification, si tu n'es pas en https, tout continue
de circuler en clair.
ok pour la sécurité assez faible, mais finalement, ce que j'ai à déposer
n'est pas non plus si critique, le seul gros risque j'ai l'impression
serait la malversation d'un employer de mon hébergeur.
En mutualisé, tu auras toujours un (petit) risque.
il me faudrait un ftp qui crypte à l'envoi pour le stockage sur serveur
et décrypte à la réception... uniquement sur certains dossiers en plus.
En admettant que ça existe, c'est impossible en mutualisé puisque tu
utilises leur serveur ftp.
Mais j'imagine qu'il est possible de créer facilement un outil en PHP,
Python, Ruby, etc.
En PHP, les fonctions mcrypt sont là pour ça.
Si tu as accès aux commandes shell et que mcrypt est installé (on peut
rêver), ça sera probablement (beaucoup ?) plus rapide.
ou le vol de mon authetification sur un poste corrompu, à moi d'être
vigilant sur ce problème.
C'est toujours le maillon faible. Pour les données sensibles et les
risques à l'authentification, on utilise un mécanisme OTP (one time
password : un mot de passe unique pour chaque authentification, donné
par SMS, email, token...)
si j'ai bien compris, la différence entre htpasswd et htdigest, c'est qu'avec le premier les échanges d'authentification se font en clair alors qu'avec le ssecond elles sont cryptées c'est ça?
Oui voilà (mais on dit "chiffrées", pas "cryptées"), en MD5 (qui n'est pas en fait un algo de chiffrement mais de hashage d'ailleurs, d'où la faiblesse de processus.) Mais après ton authentification, si tu n'es pas en https, tout continue de circuler en clair.
ok pour la sécurité assez faible, mais finalement, ce que j'ai à déposer n'est pas non plus si critique, le seul gros risque j'ai l'impression serait la malversation d'un employer de mon hébergeur.
En mutualisé, tu auras toujours un (petit) risque.
il me faudrait un ftp qui crypte à l'envoi pour le stockage sur serveur et décrypte à la réception... uniquement sur certains dossiers en plus.
En admettant que ça existe, c'est impossible en mutualisé puisque tu utilises leur serveur ftp. Mais j'imagine qu'il est possible de créer facilement un outil en PHP, Python, Ruby, etc. En PHP, les fonctions mcrypt sont là pour ça. Si tu as accès aux commandes shell et que mcrypt est installé (on peut rêver), ça sera probablement (beaucoup ?) plus rapide.
ou le vol de mon authetification sur un poste corrompu, à moi d'être vigilant sur ce problème.
C'est toujours le maillon faible. Pour les données sensibles et les risques à l'authentification, on utilise un mécanisme OTP (one time password : un mot de passe unique pour chaque authentification, donné par SMS, email, token...)
Tr
*Ecrit* *par* *Olivier Masson*:
Le 06/01/2011 09:58, a écrit :
si j'ai bien compris, la différence entre htpasswd et htdigest, c'est qu'avec le premier les échanges d'authentification se font en clair alors qu'avec le ssecond elles sont cryptées c'est ça?
Oui voilà (mais on dit "chiffrées", pas "cryptées"), en MD5 (qui n'est pas en fait un algo de chiffrement mais de hashage d'ailleurs, d'où la faiblesse de processus.) Mais après ton authentification, si tu n'es pas en https, tout continue de circuler en clair.
ok pour la sécurité assez faible, mais finalement, ce que j'ai à déposer n'est pas non plus si critique, le seul gros risque j'ai l'impression serait la malversation d'un employer de mon hébergeur.
En mutualisé, tu auras toujours un (petit) risque.
il me faudrait un ftp qui crypte à l'envoi pour le stockage sur serveur et décrypte à la réception... uniquement sur certains dossiers en plus.
En admettant que ça existe, c'est impossible en mutualisé puisque tu utilises leur serveur ftp. Mais j'imagine qu'il est possible de créer facilement un outil en PHP, Python, Ruby, etc. En PHP, les fonctions mcrypt sont là pour ça. Si tu as accès aux commandes shell et que mcrypt est installé (on peut rêver), ça sera probablement (beaucoup ?) plus rapide.
ou le vol de mon authetification sur un poste corrompu, à moi d'être vigilant sur ce problème.
C'est toujours le maillon faible. Pour les données sensibles et les risques à l'authentification, on utilise un mécanisme OTP (one time password : un mot de passe unique pour chaque authentification, donné par SMS, email, token...)
ok, merci pour cette réponse très complète, je vais maintenant essayer d'avancer avec tout ça :-)
-- Rien n'est impossible. (Etat d'esprit)
*Ecrit* *par* *Olivier Masson*:
Le 06/01/2011 09:58, Tr@nquille a écrit :
si j'ai bien compris, la différence entre htpasswd et htdigest,
c'est
qu'avec le premier les échanges d'authentification se font en clair
alors qu'avec le ssecond elles sont cryptées c'est ça?
Oui voilà (mais on dit "chiffrées", pas "cryptées"), en MD5 (qui
n'est pas en fait un algo de chiffrement mais de hashage d'ailleurs,
d'où la faiblesse de processus.)
Mais après ton authentification, si tu n'es pas en https, tout
continue de circuler en clair.
ok pour la sécurité assez faible, mais finalement, ce que j'ai à
déposer
n'est pas non plus si critique, le seul gros risque j'ai
l'impression
serait la malversation d'un employer de mon hébergeur.
En mutualisé, tu auras toujours un (petit) risque.
il me faudrait un ftp qui crypte à l'envoi pour le stockage sur
serveur
et décrypte à la réception... uniquement sur certains dossiers en
plus.
En admettant que ça existe, c'est impossible en mutualisé puisque tu
utilises leur serveur ftp.
Mais j'imagine qu'il est possible de créer facilement un outil en
PHP, Python, Ruby, etc.
En PHP, les fonctions mcrypt sont là pour ça.
Si tu as accès aux commandes shell et que mcrypt est installé (on
peut rêver), ça sera probablement (beaucoup ?) plus rapide.
ou le vol de mon authetification sur un poste corrompu, à moi
d'être
vigilant sur ce problème.
C'est toujours le maillon faible. Pour les données sensibles et les
risques à l'authentification, on utilise un mécanisme OTP (one time
password : un mot de passe unique pour chaque authentification, donné
par SMS, email, token...)
ok, merci pour cette réponse très complète, je vais maintenant essayer
d'avancer avec tout ça :-)
--
Rien n'est impossible. (Etat d'esprit)
tranquille.xav@gmail.com
si j'ai bien compris, la différence entre htpasswd et htdigest, c'est qu'avec le premier les échanges d'authentification se font en clair alors qu'avec le ssecond elles sont cryptées c'est ça?
Oui voilà (mais on dit "chiffrées", pas "cryptées"), en MD5 (qui n'est pas en fait un algo de chiffrement mais de hashage d'ailleurs, d'où la faiblesse de processus.) Mais après ton authentification, si tu n'es pas en https, tout continue de circuler en clair.
ok pour la sécurité assez faible, mais finalement, ce que j'ai à déposer n'est pas non plus si critique, le seul gros risque j'ai l'impression serait la malversation d'un employer de mon hébergeur.
En mutualisé, tu auras toujours un (petit) risque.
il me faudrait un ftp qui crypte à l'envoi pour le stockage sur serveur et décrypte à la réception... uniquement sur certains dossiers en plus.
En admettant que ça existe, c'est impossible en mutualisé puisque tu utilises leur serveur ftp. Mais j'imagine qu'il est possible de créer facilement un outil en PHP, Python, Ruby, etc. En PHP, les fonctions mcrypt sont là pour ça. Si tu as accès aux commandes shell et que mcrypt est installé (on peut rêver), ça sera probablement (beaucoup ?) plus rapide.
ou le vol de mon authetification sur un poste corrompu, à moi d'être vigilant sur ce problème.
C'est toujours le maillon faible. Pour les données sensibles et les risques à l'authentification, on utilise un mécanisme OTP (one time password : un mot de passe unique pour chaque authentification, donné par SMS, email, token...)
ok, merci pour cette réponse très complète, je vais maintenant essayer d'avancer avec tout ça :-)
