Bonjour tous.

J'ai un site web qui n'est pas héberger local, donc complètement sur le web.

Ce que j'aimerait, c'Est de trouver le moyen autre qu'un cookie pour identifier une connection avec mon ordinateur, de manière a éviter a entrer username et mdp sur le login du site peux importe où je me connecte avec mon laptop.

Donc laptop reconnu (par un moyen X) pas besoin de login.
et PC ou Laptop qui n'est pas reconnu par ce même moyen X doit se connecter au site par login user/pwl

Avec vous une idée
Merci

Si tu as une ip fixe, c'est faisable, il suffit de les comparer... mais sinon je ne vois pas ce qui te gène dans la solution du cookie ? c'est ce qu'utilise tous les sites pour identifier l'uilisateur sans qu'il ait besoin de ressaisir un mot de passe et ça marche très bien (y a qu'à voir ici )

Le cookie d'authentification n'est effectivement pas trop gênant. C'est la solution la plus simple. Mais ce post touche un peu à la protection d'un serveur domestique. Alors j'y vais de ma technique.

Pour protéger mon serveur de dvp à la maison, j'utilise une technique que j'appelle "d'ouverture par tierce clé".

Mon serveur de la maison est protégé 3 fois. Par firewall (iptables), tcp wrapper et par htaccess pour le serveur Apache. Une seule de ces protections est, en principe, suffisante. Prenons, pour le cas qui te préoccupe, la protection par htaccess.

Conditions:
1- disposer de cron ou assimilé pour Windows.
2- disposer d'un site hébérgé avec support PHP.

Définitions:
1- serveur de la maison --> M
2- serveur distant (hébergé) --> H
3- pc distant de l'endroit où tu te trouves à un moment donné --> D

Principe:
1- Sur M, lancer une tâche cron qui va lire, par exemple, toutes le 5 min. sur le site distant H la seule IP qui a accès à ton serveur de la maison.

2- De l'endroit où tu te trouves à ce moment (D), tu accèdes une page php sur H qui indentifie l'IP de D de cet endroit. ($_SERVER['REMOTE_ADDR']). Ce même script écrit cette IP capturée dans un fichier texte (fopen --> fwrite etc...)

3- la tâche cron de M, lit ce fichier texte toutes les 5 min. (wget, curl ou autre) et modifie l'htaccess à la volée.

L'htaccess: Dans cet htaccess, si tu n'accèdes pas aux pages par l'IP xxx.xxx.xxx.xxx, tu devras t'authentifier par user/pw.

C'est la ligne Allow from xxx.xxx.xxx.xxx que ton script cron doit modifier à la volée (sed ou éventuellement un script PHP si tu préfères).

Ça a l'air compliqué mais c'est relativement facile à mettre en place si tu maîtrises un tant soit peu les scripts bash ou PHP. Je contrôle également de cette manière l'accès au port ssh du serveur de la maison.

C'est un peu laborieux tout de même.
Au passage, tu n'as jamais pensé à simplement faire une requète http de ton H vers ton M, le H envoyant directement l'IP, et le M modifiant directement le .htaccess ? Cela t'éviterait un cron, non ?
Et puis dans cette solution, il y a quand même une identification du pc au H, même si elle peut être silencieuse, donc le principe est du coup le même que les cookies, on a un mot de passe que l'on envoie au serveur pour qu'il autorise l'accès.

C'est un peu laborieux tout de même.

Laborieux en apparence. Seulement quand il faut l'expliquer car la mise en oeuvre est assez simple.

Au passage, tu n'as jamais pensé à simplement faire une requète http de ton H vers ton M, le H envoyant directement l'IP, et le M modifiant directement le .htaccess ? Cela t'éviterait un cron, non ?

Non car au départ, sur mon serveur domestique (M) tous les ports sont fermés (en INPUT). Quand je quitte la maison, je lance le cron. Il reste "à l'écoute". c-à-d qu'il essaye de télécharger le fichier texte de H qui devra contenir l'IP autorisée. Le cron n'est pas bloqué en sortie (chaine OUTPUT est en ACCEPT par défaut).

Et puis dans cette solution, il y a quand même une identification du pc au H, même si elle peut être silencieuse, donc le principe est du coup le même que les cookies, on a un mot de passe que l'on envoie au serveur pour qu'il autorise l'accès.

D'accord, dans le cadre de la question posée. J'ai juste voulu profiter de l'occasion pour expliquer ma méthode. J'ai aussi pensé, au départ de ma réflexion de protection, à utiliser l'échange de clés publique/privée pour l'accès ssh ou de certificat ssl pour le serveur http mais c'est beaucoup plus lourd à mettre en place. Il faut toujours avoir sur soi une copie des clés ou certificats, les stoker sur le PC distant (D), parfois celui d'un client... Trop lourd. Avec ma technique, je peux ouvrir mes ports de n'importe quel PC. Il suffit d'enregistrer son IP sur H et d'attendre 5 minutes.

Pour être tout à fait complet, j'ai aussi utilisé un temps un dyndns. Mes fichiers iptables, tc-wrapper ou htaccess utilisait un nom de domaine au lieu d'une IP. Il suffisait que je mette à jour le dyndns de l'endroit où je me trouvais, à un instant donné, mais la propagation du nom de domaine dans les serveurs dns prenait parfois plus d'une heure. Trop lent quand je suis à l'extérieur, pris d'un soudain et irrépressible besoin de consulter ma machine à la maison!

Non car au départ, sur mon serveur domestique (M) tous les ports sont fermés (en INPUT). Quand je quitte la maison, je lance le cron. Il reste "à l'écoute". c-à-d qu'il essaye de télécharger le fichier texte de H qui devra contenir l'IP autorisée. Le cron n'est pas bloqué en sortie (chaine OUTPUT est en ACCEPT par défaut).

Oui mais dans ce cas, comment, une fois l'IP enregistrée, tu fais pour accéder à M avec ton pc ? Sachant que ton iptables filtre en INPUT ? Tu rajoutes aussi une règle de parefeu en même temps que de modifier le .htaccess ?
Sinon, apparement, si c'est le cas, c'est vrai que c'est un compromis satisfaisant, même si personnellement, si j'avais voulu être protégé par iptables et htaccess, j'aurais développé un serveur d'écoute en php sur un port exotique (ouvert par le parefeu) sur M plutôt qu'utilisé un cron.

Oui mais dans ce cas, comment, une fois l'IP enregistrée, tu fais pour accéder à M avec ton pc ? Sachant que ton iptables filtre en INPUT ? Tu rajoutes aussi une règle de parefeu en même temps que de modifier le .htaccess ?

Exact. Ainsi qu'un ajout de ligne (ou d'une référence de fichier) de le /etc/hosts.allow du tcp-wrapper. On n'est jamias trop prudent!

Sinon, apparement, si c'est le cas, c'est vrai que c'est un compromis satisfaisant, même si personnellement, si j'avais voulu être protégé par iptables et htaccess, j'aurais développé un serveur d'écoute en php sur un port exotique (ouvert par le parefeu) sur M plutôt qu'utilisé un cron.

Le cron ne mange pas de pain et un serveur supplémentaire (et son port) qui tourne en permanence est une source d'attaque possible. Le fait d'y mettre un port exotique ne change rien. Un nmap -P0 le révèlera en quelques minutes. Dans mon système, quand j'en ai fini avec mon accès à distance, je mets le fichier IP de H en "OFF". Mon script cron repasse 5 minutes après, y trouve le OFF et ferme tous les ports. Quand je rentre chez moi, j'arrête le cron. Bon, avant de repartir dans la nature le lendemain, il ne faut pas oublier de le relancer hein, sinon tu es bon pour appeler ta femme/copine/fils/fille lui dire d'allumer l'écran du serveur (du quoi?), de taper le username linux (elle est où la touche "anykey"?) de taper le mot de passe (c'est normal si rien ne s'inscrit à l'écran?) de faire crontab -e (c'est là, en général où elle te traite de tous les noms d'oiseau répertoriées et que tu regrettes sincèrement ne pas avoir lancé le cron toi-même avant de partir). Du vécu garanti. Du coup mon cron tourne souvent en permanence.

Un peu "overkill" pour la question posée mais l'occasion faisant le larron....

Le cron ne mange pas de pain

C'est long 5 minutes

un serveur supplémentaire (et son port) qui tourne en permanence est une source d'attaque possible.

Avec iptables et le système de droits linux, si le script est bien fait, je ne vois pas comment, à part avec une faille du système, ce serait possible de forcer la sécurité, surtout que le principe de n'autoriser qu'une IP est faillible aussi, une IP, ça se manipule, il suffit de faire ses paquets soi même, et de la même manière, les connexions réseaux, ça se sniffe. Bref, ce n'est jamais vraiment sécurisé…

Le fait d'y mettre un port exotique ne change rien.

Ah non, ça c'était juste pour éviter de bloquer un port spécial, ce n'était pas question de sécurité…

Dans mon système, quand j'en ai fini avec mon accès à distance, je mets le fichier IP de H en "OFF". Mon script cron repasse 5 minutes après, y trouve le OFF et ferme tous les ports. Quand je rentre chez moi, j'arrête le cron. Bon, avant de repartir dans la nature le lendemain, il ne faut pas oublier de le relancer hein, sinon tu es bon pour appeler ta femme/copine/fils/fille lui dire d'allumer l'écran du serveur (du quoi?), de taper le username linux (elle est où la touche "anykey"?) de taper le mot de passe (c'est normal si rien ne s'inscrit à l'écran?) de faire crontab -e (c'est là, en général où elle te traite de tous les noms d'oiseau répertoriées et que tu regrette sincèrement ne pas avoir lancé le cron toi-même avant de partir). Du vécu garanti. Du coup mon cron tourne souvent en permanence.

Je vois le genre

Un peu "overkill" pour la question posée mais l'occasion faisant le larron....

Ya pas de mal si ça t'as fait plaisir d'en parler.

Bonjour,

Une autre solution très rapide à mettre en place serait de modifier l'user-agent de ton navigateur et de faire une vérification dessus (par htaccess par exemple).

Pour modifier l'user-agent sous Firefox, il faut que tu tappes dans la barre d'adresse "about:config", que tu cherches le champ "general.useragent.extra.firefox", tu double-clic sur la valeur et tu rajoutes à la fin du champ un mot clé du genre "ordi_de_auclairp".
Pour modifier l'user-agent d'Internet Explorer, ça se passe dans la base de registre, Google te dira probablement où précisément...
Tu peux vérifier la valeur de ton user-agent à l'url suivante: http://ip.celeo.net
A noter que cette solution n'est pas idéale d'un point de vue sécurité vu que ton mot-clé placé dans l'user-agent va être accessible à tous les sites que tu visites. Mais si l'url privée à laquelle tu veux accéder n'est pas connu publiquement, alors les risques sont très faibles