Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

faiblesses d'une protection via un htaccess

2 views
Skip to first unread message

Tr@nquille

unread,
Dec 31, 2010, 3:15:11 AM12/31/10
to
Bonjour ᅵ tous,

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)
tranqui...@gmail.com


Jean-Francois Ortolo

unread,
Dec 31, 2010, 5:25:50 AM12/31/10
to
Le 31/12/2010 09:15, Tr@nquille a écrit :
> Bonjour à tous,

>
> 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 :-)
>


Bonjour

Seule possibilité : Se faire "sniffer" le mot de passe puisque
celui-ci circule en clair sur le réseau ainsi que le login.

En fait, j'ai un lapsus : Je ne me souviens plus du nom du protocole
web sécurisé ( = crypté sur le réseau ) permettant des authentifications
vraiment sécurisées.

lsh, rsh... Je confond avec un autre terme, qui désigne précisément (
pour rsh ) une ancienne commande Unix ( remote shell ), qui d'ailleurs
n'était pas du tout sécurisée à l'époque révolue où elle était utilisée. ;)

Ce serait pas ssl le protocole sécurisé ? Mmmhhh... A voir...

C'est vrai que je ne connais rien à l'implémentation de ssl, ce qui
explique le lapsus... Quand on sait pas on sait pas. ;)

D'autres que moi pourront vous renseigner.

Bien à vous.

Amicalement.

Jean-François Ortolo

--
Visitez mon site gratuit donnant des Statistiques,
des Pronostics et des Historiques Graphiques
sur les Courses de Chevaux:
http://www.pronostics-courses.fr

Tr@nquille

unread,
Dec 31, 2010, 5:41:56 AM12/31/10
to
*Ecrit* *par* *Jean-Francois Ortolo*:

> Le 31/12/2010 09:15, Tr@nquille a écrit :
>> Bonjour à tous,
>>
>> 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 :-)
>>


> Bonjour

> Seule possibilité : Se faire "sniffer" le mot de passe puisque
> celui-ci circule en clair sur le réseau ainsi que le login.

ok, c'est bien si c'est le seul gros risque.
j'imaginais quelqu'un envoyant via un script quelconque des tentatives
nombreuses pour craquer le pass via bruteforce par exemple, mais ça
semble peu probable si on ne connait pas déjà l'utilisateur par
exemple.
autre chose que j'imaginais, quelqu'un qui arrive à pirater le serveur
hébergeant mes infos (c'est un serveur mutualisé de chez ovh, je
suppose que la sécu doit être blindée, et le piratage d'un compte mutu
ne doit pas permettre de passer sur un autre compte enfin j'espère)

> En fait, j'ai un lapsus : Je ne me souviens plus du nom du
> protocole web sécurisé ( = crypté sur le réseau ) permettant des
> authentifications vraiment sécurisées.

je pense que tu veux parler d'une connexion en https dans ce cas
précis.
mon hébergement ne me permet pas ça, c'est dommage d'ailleurs...

ok pour le rste et merci, peut-être d'autres se manifesteront au cas où
j'ai dit une bêtise.

--
On est ce qu'on fait, pas ce qu'on pense ni dit. (Réflexion)
tranqui...@gmail.com


Jean-Francois Ortolo

unread,
Dec 31, 2010, 5:51:46 AM12/31/10
to
Le 31/12/2010 11:41, Tr@nquille a écrit :
>
> ok, c'est bien si c'est le seul gros risque.
> j'imaginais quelqu'un envoyant via un script quelconque des tentatives
> nombreuses pour craquer le pass via bruteforce par exemple, mais ça
> semble peu probable si on ne connait pas déjà l'utilisateur par exemple.
> autre chose que j'imaginais, quelqu'un qui arrive à pirater le serveur
> hébergeant mes infos (c'est un serveur mutualisé de chez ovh, je suppose
> que la sécu doit être blindée, et le piratage d'un compte mutu ne doit
> pas permettre de passer sur un autre compte enfin j'espère)
>
>

Bonjour Monsieur

Bof, vous savez, les attaques type bruteforce, sont précisément
destinées aux mots de passe peu complexes et faciles à deviner.

A priori, si vous cherchez la sécurité, vous n'allez pas choisir de
tels mots de passe. ;)

Et puis, pour tester un compte comme celà, encore faut-il déjà avoir
le login.

En ce qui concerne les tentatives répétées et rapides de connexion à
partir d'une seule adresse ip, je suppose ( bien que je n'en connaisse
pas, mon ignorance est impardonnable. ;) ) qu'il existe des moyens de
protection, et même di'dentification de l'adresse ip en cause, mais là
je suppose qu'il faudrait faire du développement quel que soit le
langage, pour bloquer et logguer les connexions en cause.

A moins que de telles fonctionnalités existent déjà.

Et puis, vous pouvez toujours examiner les logs de votre serveur...
Mais là, ce n'est pas du direct ou automatique.

Steph. K

unread,
Dec 31, 2010, 5:54:14 AM12/31/10
to
Le 31/12/2010 11:41, Tr@nquille a écrit :

> ok pour le rste et merci, peut-être d'autres se manifesteront au cas où
> j'ai dit une bêtise.

Ca dépend de ce que tu appelles "fichiers sensibles", si c'est les codes
d'accès à fort Knox un htaccess est insuffisant si c'est le mot de passe
de ta base de données cela suffit.
Tu peux aussi crypter tes fichiers avec un mot de passe différent de
celui de ton htaccess.

--
Steph. K

Tr@nquille

unread,
Dec 31, 2010, 6:58:53 AM12/31/10
to
*Ecrit* *par* *Steph. K*:

> Le 31/12/2010 11:41, Tr@nquille a écrit :

>> ok pour le rste et merci, peut-être d'autres se manifesteront au
>> cas où
>> j'ai dit une bêtise.

> Ca dépend de ce que tu appelles "fichiers sensibles", si c'est les
> codes d'accès à fort Knox un htaccess est insuffisant si c'est le mot

oui, ça pourrait être des trucs comme ça, des codes d'accès à des
comptes entre autres...

> de passe de ta base de données cela suffit.
> Tu peux aussi crypter tes fichiers avec un mot de passe différent de
> celui de ton htaccess.

je veux pouvoir accéder à ces fichiers de n'importe où, les modifier,
etc...

--
Faire de la politique, c'est permettre aux autres de choisir en toute
connaissance de cause. (Réflexion)
tranqui...@gmail.com


Steph. K

unread,
Dec 31, 2010, 8:29:06 AM12/31/10
to
Le 31/12/2010 12:58, Tr@nquille a ï¿œcrit :

> je veux pouvoir accᅵder ᅵ ces fichiers de n'importe oᅵ, les modifier,
> etc...

Une clᅵ usb avec des fichiers cryptᅵs me semble plus universel.
Framakey + FreeOTFE devraient faire l'affaire, en plus tu es en principe
assurᅵ de ne pas laisser de traces sur l'ordinateur hᅵte.


--
Steph. K

Tr@nquille

unread,
Dec 31, 2010, 9:05:46 AM12/31/10
to
*Ecrit* *par* *Steph. K*:
> Le 31/12/2010 12:58, Tr@nquille a écrit :

>> je veux pouvoir accéder à ces fichiers de n'importe où, les
>> modifier,
>> etc...

> Une clé usb avec des fichiers cryptés me semble plus universel.


> Framakey + FreeOTFE devraient faire l'affaire, en plus tu es en

> principe assuré de ne pas laisser de traces sur l'ordinateur hôte.

le prob c'est que j'ai tendance à oublier cette clé sur les pc des
autres :-)
c'est pourquoi je cherchais une autre solution...

--
C'est tellement facile de détruire! Et c'est si difficile de
contruire... (Réflexion)
tranqui...@gmail.com


Steph. K

unread,
Dec 31, 2010, 9:42:30 AM12/31/10
to
Le 31/12/2010 15:05, Tr@nquille a écrit :

> le prob c'est que j'ai tendance à oublier cette clé sur les pc des
> autres :-)
> c'est pourquoi je cherchais une autre solution...

Alors htaccess + fichiers protégés (zip avec mot de passe, doc avec mot
de passe etc).
Les navigateurs ont la mauvaise habitude de conserver trop de choses en
mémoire, sans parler des saloperies que le pc peut héberger à l'insu de
son plein gré. C'est pour cela qu'il te faut impérativement une
protection supplémentaire.


--
Steph. K

Tr@nquille

unread,
Jan 1, 2011, 5:40:02 AM1/1/11
to
*Ecrit* *par* *Steph. K*:

ok, je vais réfléchir, merci :-)

--
Haro sur la langue de bois! (Politique)
tranqui...@gmail.com


B.M.

unread,
Jan 2, 2011, 7:19:38 AM1/2/11
to
Le 01/01/2011 11:40, Tr@nquille a ï¿œcrit :
> *Ecrit* *par* *Steph. K*:
>> Le 31/12/2010 15:05, Tr@nquille a ï¿œcrit :
>
>>> le prob c'est que j'ai tendance ᅵ oublier cette clᅵ sur les pc des

>>> autres :-)
>>> c'est pourquoi je cherchais une autre solution...
>
>> Alors htaccess + fichiers protï¿œgï¿œs (zip avec mot de passe, doc avec

>> mot de passe etc).
>> Les navigateurs ont la mauvaise habitude de conserver trop de choses
>> en mᅵmoire, sans parler des saloperies que le pc peut hᅵberger ᅵ
>> l'insu de son plein grᅵ. C'est pour cela qu'il te faut impᅵrativement
>> une protection supplï¿œmentaire.
>
> ok, je vais rï¿œflï¿œchir, merci :-)
>

Ne pas oublier que mᅵme protᅵgᅵ par htaccess ton fichier reste
accessible par les techniciens de ton hï¿œbergeur.
--
B. M.

Tr@nquille

unread,
Jan 2, 2011, 8:10:08 AM1/2/11
to
*Ecrit* *par* *B.M.*:

> Le 01/01/2011 11:40, Tr@nquille a écrit :
>> *Ecrit* *par* *Steph. K*:
>>> Le 31/12/2010 15:05, Tr@nquille a écrit :
>>
>>>> le prob c'est que j'ai tendance à oublier cette clé sur les pc
>>>> des
>>>> autres :-)
>>>> c'est pourquoi je cherchais une autre solution...
>>
>>> Alors htaccess + fichiers protégés (zip avec mot de passe, doc
>>> avec
>>> mot de passe etc).
>>> Les navigateurs ont la mauvaise habitude de conserver trop de
>>> choses
>>> en mémoire, sans parler des saloperies que le pc peut héberger à

>>> l'insu de son plein gré. C'est pour cela qu'il te faut
>>> impérativement
>>> une protection supplémentaire.
>>
>> ok, je vais réfléchir, merci :-)
>>

> Ne pas oublier que même protégé par htaccess ton fichier reste
> accessible par les techniciens de ton hébergeur.

ça c'est juste, un temps j'i envisagé de mettre en place chez moi sur
une machine, un site sécurisé etc, mais en contrepartie je perds la
sécurité des sauvegardes de mon hébergeur...
ça fait monter une grosse artillerie chez moi, pour un risque chez
l'hébergeur que je cherche à évaluer pour voir si ça vaut le coup...

--
L'histoire est une perpétuelle quête au bouc-émissaire. (Réflexion)
tranqui...@gmail.com


rm

unread,
Jan 2, 2011, 12:12:53 PM1/2/11
to
Salut et bonne année,
Le dimanche 2 janvier 2011 à 14:10, Tr@nquille<tranqui...@gmail.com> a
écrit :

> ça fait monter une grosse artillerie chez moi

Tu as essayé la fonctionnalité Unite de ton navigateur préféré ?

@+
--
rm - http://opera-fr.com

Tr@nquille

unread,
Jan 2, 2011, 12:27:14 PM1/2/11
to
*Ecrit* *par* *rm*:

> Salut et bonne année,
> Le dimanche 2 janvier 2011 à 14:10,
> Tr@nquille<tranqui...@gmail.com> a écrit :

>> ça fait monter une grosse artillerie chez moi

> Tu as essayé la fonctionnalité Unite de ton navigateur préféré ?

> @+

non, mais il me semble que cette partie demande un "pc serveur" avec
opera, ce que je ne veux pas faire...
j'ai un petit machin sous linux même pas graphique qui irait très bien,
caché dans un coin, pas d'écran, et qui reste allumé tout le temps,
c'est là que je pourrais mettre en place un serveur ftp sécurisé ou un
serveur http avec webdav, voilà mes pistes pour le moment, manque juste
une technique pour sauvegarder, genre second disque mais comme mon pc
est un vieux portable, je ne peux pas en ajouter un à l'intérieur...
peut-être qu'un truc sur unite m'a échapé...

--
On n'est jamais trop bon, ce sont ceux qui en profitent qui sont trop
cons. (Réflexion)
tranqui...@gmail.com


rm

unread,
Jan 2, 2011, 1:29:34 PM1/2/11
to
Le dimanche 2 janvier 2011 à 18:27, Tr@nquille<tranqui...@gmail.com> a
écrit :

> *Ecrit* *par* *rm*:
>> Salut et bonne année,
>> Le dimanche 2 janvier 2011 à 14:10,
>> Tr@nquille<tranqui...@gmail.com> a écrit :
>
>>> ça fait monter une grosse artillerie chez moi
>
>> Tu as essayé la fonctionnalité Unite de ton navigateur préféré ?
>
>> @+
>
> non, mais il me semble que cette partie demande un "pc serveur" avec
> opera, ce que je ne veux pas faire...
> j'ai un petit machin sous linux même pas graphique qui irait très bien,
> caché dans un coin, pas d'écran, et qui reste allumé tout le temps,
> c'est là que je pourrais mettre en place un serveur ftp sécurisé ou un
> serveur http avec webdav,

Ah, OK, effectivement Unite ne conviendra pas puisqu'il est plutôt pensé
pour ne pas avoir à administrer la grosse artillerie que tu décris comme
"un petit machin sous linux même pas graphique sans d'écran avec un serveur
ftp sécurisé ou un serveur http avec webdav" :-D

@+
--
rm

Tr@nquille

unread,
Jan 2, 2011, 1:41:43 PM1/2/11
to
*Ecrit* *par* *rm*:
> Le dimanche 2 janvier 2011 ᅵ 18:27,
> Tr@nquille<tranqui...@gmail.com> a ï¿œcrit :

>> *Ecrit* *par* *rm*:
>>> Salut et bonne annï¿œe,
>>> Le dimanche 2 janvier 2011 ᅵ 14:10,
>>> Tr@nquille<tranqui...@gmail.com> a ï¿œcrit :
>>>> ï¿œa fait monter une grosse artillerie chez moi
>>> Tu as essayᅵ la fonctionnalitᅵ Unite de ton navigateur prᅵfᅵrᅵ ?

>>> @+
>>
>> non, mais il me semble que cette partie demande un "pc serveur" avec
>> opera, ce que je ne veux pas faire...

>> j'ai un petit machin sous linux mï¿œme pas graphique qui irait trï¿œs
>> bien, cachᅵ dans un coin, pas d'ᅵcran, et qui reste allumᅵ tout le
>> temps, c'est lᅵ que je pourrais mettre en place un serveur ftp
>> sᅵcurisᅵ ou un serveur http avec webdav,

> Ah, OK, effectivement Unite ne conviendra pas puisqu'il est plutï¿œt
> pensᅵ pour ne pas avoir ᅵ administrer la grosse artillerie que tu
> dï¿œcris comme "un petit machin sous linux mï¿œme pas graphique sans
> d'ᅵcran avec un serveur ftp sᅵcurisᅵ ou un serveur http avec webdav"
> :-D

et puis, je ne peux quand-mï¿œme pas installer opera sur tous les
ordinateurs que je vais dï¿œpanner et pour lesquels j'ai besoin des docs
et outils que je veux mettre sur le web...
en plus, crï¿œer un compte chez opera, gratuit, pour y stocker des docs
sensibles...

--
On est ce qu'on fait, pas ce qu'on pense ni dit. (Rï¿œflexion)
tranqui...@gmail.com


rm

unread,
Jan 2, 2011, 3:23:04 PM1/2/11
to
Le dimanche 2 janvier 2011 à 19:41, Tr@nquille<tranqui...@gmail.com> a
écrit :

> *Ecrit* *par* *rm*:
>> Le dimanche 2 janvier 2011 à 18:27,
>> Tr@nquille<tranqui...@gmail.com> a écrit :
>
>>> *Ecrit* *par* *rm*:
>>>> Salut et bonne année,
>>>> Le dimanche 2 janvier 2011 à 14:10,
>>>> Tr@nquille<tranqui...@gmail.com> a écrit :
>>>>> ça fait monter une grosse artillerie chez moi
>>>> Tu as essayé la fonctionnalité Unite de ton navigateur préféré ?

>>>> @+
>>>
>>> non, mais il me semble que cette partie demande un "pc serveur" avec
>>> opera, ce que je ne veux pas faire...

>>> j'ai un petit machin sous linux même pas graphique qui irait très
>>> bien, caché dans un coin, pas d'écran, et qui reste allumé tout le
>>> temps, c'est là que je pourrais mettre en place un serveur ftp
>>> sécurisé ou un serveur http avec webdav,
>
>> Ah, OK, effectivement Unite ne conviendra pas puisqu'il est plutôt

>> pensé pour ne pas avoir à administrer la grosse artillerie que tu
>> décris comme "un petit machin sous linux même pas graphique sans
>> d'écran avec un serveur ftp sécurisé ou un serveur http avec webdav"
>> :-D
>
> et puis, je ne peux quand-même pas installer opera sur tous les
> ordinateurs que je vais dépanner et pour lesquels j'ai besoin des docs

> et outils que je veux mettre sur le web...

Je pige pas. Tu vas pas non plus configurer des Linux + serveurs ftp/http
sur toutes ces machines ?
Si c'est pour accéder à des appli Unite, tu peux le faire à l'aide de
n'importe quel navigateur, n'importe quelle plate-forme, mobile ou pas...

> en plus, créer un compte chez opera, gratuit, pour y stocker des docs
> sensibles...

Le compte chez Opera ne sert qu'à obtenir graciueusement un nom de
sous-domaine en operaunite.com par machine et accessoirement faire savoir
sur la communauté My Opera que tu partages des applications. Un serveur
Unite pourra très bien être atteint directement (adresse IP ou nom de
domaine perso) sans passer par un quelconque proxy appartenant à Opera et
bien sûr sans stocker quoi que ce soit chez Opera.
Sinon, ça n'aurait aucun sens, autant stocker chez un hébergeur de fichier
(comme My Opera ;) )

@+
--
rm

Tr@nquille

unread,
Jan 3, 2011, 7:35:49 AM1/3/11
to

ya un truc que j'ai pas du saisir:
"Comme les applications Opera Unite sont disponibles par Opera, et que
les données sont stockées uniquement sur votre ordinateur, vos
applications seront indisponibles si vous quittez Opera ou éteignez
votre ordinateur."

or je ne veux pas stocker sur mon ordinateur avec lequel je me déplace,
donc j'ai pas compris où est le serveur qui va stocker mes docs, et qui
va faire les sauvegardes de façon transparentes... déjà :-)

--
Et alors? Ya pas de honte à demander. La honte, c'est quand on sait et
qu'on ne répond pas. (Etat d'esprit)
tranqui...@gmail.com


rm

unread,
Jan 3, 2011, 1:24:01 PM1/3/11
to
Le lundi 3 janvier 2011 � 13:35, Tr@nquille<tranqui...@gmail.com> a
�crit :

> je ne veux pas stocker sur mon ordinateur avec lequel je me d�place,
> donc j'ai pas compris o� est le serveur qui va stocker mes docs

Tu as donn� la r�ponse plus haut : un PC ou un Mac avec "Opera inside", une
alternative simple � la "grosse artillerie". Mais qui ne te convient pas
puisque tu as d�j� les bases de la grosse artillerie.

> et qui
> va faire les sauvegardes de fa�on transparentes... d�j� :-)

Si le but du "jeu de l'auto-h�bergement" est de ne pas balancer tes donn�es
dans les nuages, je ne vois pas trop comment tu pourras confier cette
besogne importante � des tiers aussi "transparents" soient-ils ;)

@+
--
rm

Tr@nquille

unread,
Jan 4, 2011, 9:59:25 AM1/4/11
to
*Ecrit* *par* *rm*:
> Le lundi 3 janvier 2011 à 13:35, Tr@nquille<tranqui...@gmail.com>
> a écrit :

>> je ne veux pas stocker sur mon ordinateur avec lequel je me déplace,
>> donc j'ai pas compris où est le serveur qui va stocker mes docs

> Tu as donné la réponse plus haut : un PC ou un Mac avec "Opera
> inside", une alternative simple à la "grosse artillerie". Mais qui ne
> te convient pas puisque tu as déjà les bases de la grosse artillerie.

c'est exactement ça :-)

>> et qui
>> va faire les sauvegardes de façon transparentes... déjà :-)

> Si le but du "jeu de l'auto-hébergement" est de ne pas balancer tes
> données dans les nuages, je ne vois pas trop comment tu pourras
> confier cette besogne importante à des tiers aussi "transparents"
> soient-ils ;)

c'est vrai, c'est pourquoi je pèse le pour et le contre...
merci de ton intervention en tout cas.

--
Parfois, il faut savoir faire abstraction de la forme pour ne prendre
en compte que le fond (Etat d'esprit)
tranqui...@gmail.com


Olivier Masson

unread,
Jan 5, 2011, 1:21:19 PM1/5/11
to
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.
C'est beaucoup, beaucoup, beaucoup plus sûr que l'authentification par
défaut de Apache, qui est effectivement en clair.
A noter que sniffer sur le net n'est pas du tout évident. Par contre,
avec un accès au LAN (réseau local), c'est les doigts dans le nez (sauf
s'il y a des switches de qualité, bien configurés).


> lsh, rsh... Je confond avec un autre terme, qui désigne précisément (
> pour rsh ) une ancienne commande Unix ( remote shell ), qui d'ailleurs
> n'était pas du tout sécurisée à l'époque révolue où elle était utilisée. ;)
>
> Ce serait pas ssl le protocole sécurisé ? Mmmhhh... A voir...
>

Ben oui, tout bêtement (https). Mais c'est loin d'être très efficace
même si cela convient la plupart du temps.

Tr@nquille

unread,
Jan 5, 2011, 1:45:45 PM1/5/11
to
*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 :-)
... ok pour le reste

--
Il faut avant tout travailler ses points forts. (Réflexion)
tranqui...@gmail.com


Olivier Masson

unread,
Jan 6, 2011, 3:15:41 AM1/6/11
to
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.

Tr@nquille

unread,
Jan 6, 2011, 3:58:40 AM1/6/11
to

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...

Olivier Masson

unread,
Jan 6, 2011, 6:42:37 AM1/6/11
to
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...)

Tr@nquille

unread,
Jan 6, 2011, 6:51:27 AM1/6/11
to
*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)
tranqui...@gmail.com


0 new messages