Page 1 sur 1

Sécurisation d'un accès : interdire les échanges de code

Posté : 02 mars 2007, 17:17
par naholyr
Titre peu explicite s'il en est mais le problème est simple.

J'ai un client qui met à disposition des siens des fichiers PDF, mais cet accès est censé être limité. Il a donc mis en place une sécurité minimale : login/mot de passe, authentification HTTP.
J'ai à ma disposition un serveur Apache/PHP/Perl sur un serveur dédié (donc toute bidouille est imaginable).

Tout ceci fonctionne bien, le fichier n'est accessible que si on a le bon login/mdp pas de problème. Le problème c'est que ses clients refilent leurs identifiants à d'autres, et que du coup la sécurité devient toute relative.

Il faudrait donc un système permettant de limiter (voir d'annihiler) cette possibilité.
J'ai pensé à plusieurs systèmes, chacun ayant un avantage et un inconvénient :

- Utiliser des certificats sur le poste client : cela me paraît la solution la plus efficace, mais je ne vois pas du tout comment ça se met en place, et ça me paraît extrèmement compliqué. Quelqu'un a des exemples d'implémentation de ce type d'authentification ? De plus cela limiterait l'accès à une seule machine au lieu d'un seul réseau ?

- Associer chaque login à une adresse IP : que faire des clients qui n'ont pas d'IP fixe (rares certes, mais quand-même) ?

- Associer chaque login à un range d'IP selon le fournisseur du client : pas forcément une trop mauvaise solution, l'utilisateur ne pouvant alors refiler son mot de passe qu'à quelqu'un du même FAI (ça limite la casse, mais en même temps des FAI il n'y en a pas 50 en France surtout côté pro).

- Déterminer un nombre de machines maximum ayant accès aux données. Si on fixe ce nombre à 1, c'est contraignant mais au moins on est tranquille, et on peut déterminer ce nombre par clients. Les machines seront identifiées par cookie. Le niveau de sécurité est acceptable vu que ce seront à 99% des buses qui n'ont aucune idée de ce qu'est un cookie (le % restant est acceptable). Par contre s'il y a changement de navigateur sur la même machine, ça comptera pour deux !

- Passer par un logiciel tiers pour l'identification voire le téléchargement de fichier, mais entre un navigateur et le codage d'un client maison, il va falloir un intérêt très fort, or je vois mal comment sécuriser plus efficacement. À la rigueur un binaire DRMisé qui ne peut pas changer de machine, et qui contienne le login/mdp en dur (donc pas de possibilité de le transmettre). Mais là c'est un développement qui me paraît bien complexe.

- Limiter l'accès à une certaine adresse MAC, assez difficile à mettre en oeuvre (je vois mal mon client demander au sien l'adresse MAC de son routeur :lol: ) et de toute façon je ne sais pas comment limiter une connexion à une adresse MAC.

Que me conseilleriez-vous ?

Posté : 02 mars 2007, 18:11
par jojolapine
juste une autre idée, est-ce que tu veux limiter le nombre de téléchargment pour une personne ?
Si oui ça peu être simple... Tu préviens les cliens qu'il n'ont le droit qu'a deux téléchargement (ou même qu'un seul), et donc qu'ils ont pas interet à refiler leurs idéentifiants aux copains...

Posté : 02 mars 2007, 18:15
par naholyr
Non, l'objectif est qu'ils aient un accès illimité à tous les fichiers.

Mais ce que je suis en train de me dire, ce à quoi je n'ai pas pensé et mon client non plus c'est : une fois le fichier téléchargé, il peut bien en faire ce qu'il veut et le redistribuer aux copains... Après à part une menace d'action en justice je vois mal comment sécuriser réellement le biniou.

Posté : 02 mars 2007, 18:20
par jojolapine
faire un truc similaire à windev (mais la ça deviens du lourd), il faudrait avoir une clé branché sur le port parallele, qui dit que oui on à le droit de lire le fichier sur ce post....
Mais houlà :shock: je te souhaite bonne chance :langue:

ps: ardu cette histoire :?

Posté : 02 mars 2007, 18:25
par naholyr
Comme le client ne propose que des fichiers PDF, il y a peut-être un début de solution.

Apparemment Adobe a développé un système de DRM pour les PDF. Cela peut être une bonne solution pour ce client, d'autant plus que le reader est disponible gratuitement sur toutes les plateformes. Je regarde de ce côté là, mais là encore problème : il faut générer une licence, et donc un PDF, différent pour chaque client...

Posté : 02 mars 2007, 18:45
par Hywan
Bonjour :)

J'aime ce genre de petit casse-tête.

Il faut déjà -- à mon avis -- réfléchir à l'accès aux téléchargements. On verra ensuite comment limiter la diffusion d'un document déjà télécharger. C'est deux problèmes distincts. Car tu peux mettre un petit avant-garde stipulant que tout document téléchargé sur le site (que tu es en train de faire) ne peut être distribué librement, sous peine d'une quelconque action extérieure. Bref, faut trouver un truc bien ronflant qui te déresponsabilise vis-à-vis de la diffusion du document téléchargé.

Donc le problème actuel est : comment limiter les téléchargements ?

J'ai déjà essayé ta première idée, celle du certificat présent sur la machine du client. Mais il suffit de copier le certificat et la sécurité saute. De plus, les trois quarts du temps, le client a perdu ou supprimé son certificat (si si, j'en ai marre de lui refiler à chaque fois, on perd vite patience).
Pour les cookies, c'est pas une mauvaise idée. Mais là, même problème, il nettoie ces cookies avec son navigateur et hop.
Toutes les solutions ont, comme tu l'as signalé, des avantages et des inconvénients.

La solution que je vois, qui est contraignante pour le client, mais un peu d'organisation et le tour est joué, serait la suivante :

Tous les n jours (ou heures, peu importe), un nouveau mot de passe écrase l'ancien. Ce nouveau mot de passe est alors envoyé par email au client (encore lui faut-il un accès internet, mais il l'a forcément pour accéder au site, à moins que l'accès se fasse aussi en local ?). Et le client récupèrant son nouveau mot de passe par email pourra l'utiliser.
  • Avantages : il ne va pas distribuer son nouveau mot de passe à chaque fois ! C'est du boulot de le redonner à tout le monde, ça va le dissuader. Si comme tu le dis également, c'est tous des billes en infos, il ne va pas créer un document contenant le nouveau mot de passe qu'il mettrait à jours à chaque fois. Si c'est une bille, rien à craindre.
    En plus, on ne pourra pas deviner le mot de passe, puisqu'il change régulièrement (à intervalle proche, c'est mieux évidement).

    Inconvénients : le client doit régulièrement regarder ces mails pour revoir son mot de passe. Ce sera aussi un mot de passe généré aléatoirement, donc pas moyen de le mémoriser. Mais j'ai fais quelque fois l'expérience de ce système, ce n'est pas vraiment gênant je trouve, il suffit de s'y faire.
Au final, ce n'est pas compliquer à programmer, ça dissuade le client de ne pas diffuser ses logs d'accès, et ça renforce la sécurité.

Bonne idée ?

Posté : 02 mars 2007, 18:46
par Hywan
Ah bonne nouvelle.

Si tu peux DRMiser ton fichier téléchargé, tu peux encore plus renforcer les accès :)

Posté : 02 mars 2007, 19:12
par naholyr
Bonne idée le mdp rechargé régulièrement, je la mets de côté. Tellement simple que ça m'agace un peu de n'y avoir pas pensé :lol: mais j'ai peur que ça ne lui plaise pas (

Posté : 02 mars 2007, 19:18
par zeus
Il existe une solution simple qui ne demande aucun développement, qui a déjà été citée et qui te déresponsabilise entièrement :
UN MESSAGE D'AVERTISSEMENT ;)

Tu indiques au client lorsque tu lui transmets le document que ce mot de passe est incessible et que c'est lui qui est responsable de toute action menée sur le serveur avec ce compte.

A côté de ça, tu gères un compteur d'accès et, si le client se connecte trop souvent ou plusieurs fois en même temps, tu le dégages. Libre à toi de prévoir ensuite une souplesse liée au client ;)

Posté : 02 mars 2007, 20:43
par Hywan
Tu as pleins de solutions.
Maintenant le plus dur : la décision ^^

Tiens nous au jus ;-)

Posté : 03 mars 2007, 15:57
par Spols
autre solution, un accés un peu du genre webbanking,

une petite application qui est envoyé au client qui transforme sont mot de passe en un autre code selon un algo qui ne lui est pas connu (un peu de C) mais cette application envoyer en .exe au client s'installe et s'autodétruit, pas moyen d'envoyer à d'autre ce programme

ensuite sur le site, plutot que le mot de passe fixe habituelle, tu demande le mot de passe donnée par ce programme.

Je sais pas ssi je suis claire je résume

une application autodestructive qui donne par exemple le md5 du mot de passe plus l'heurearrondi à l'heure par exemple

et le site qui compare cette même clé par rapport à l'identifiant.

Le hic c'est que je ne connait que le php, si tous est possible coté serveur, je sais pas si c'est faisable coté client

Posté : 03 mars 2007, 19:21
par Xenon_54
- Un accès FTP limité à une connection par utilisateur?
- Un mot de passe qui se reset à chaque connection et donc réenvoyé par courriel au client?
- Un système de DRM à la RIAA?
- Un seul poste de travail peut accéder avec un gros garde du corps qui regarde par dessus votre épaule?
- Un système qui vérifie le nombre de connections par IP et peut vérifier s'il y a partage de code?

Posté : 03 mars 2007, 20:13
par Hywan
Le cumule est toléré ? :twisted: