Comment identifier de manière unique les ordinateurs visitant mon site Web?
Je dois trouver un moyen d’identifier de manière unique chaque ordinateur qui visite le site Web que je crée. Quelqu'un a-t-il des conseils pour y parvenir?
Parce que je veux que la solution fonctionne sur toutes les machines et tous les navigateurs (dans des limites raisonnables), j'essaie de créer une solution à l'aide de javascript.
J'apprécie l'aide. Merci.
MODIFIER:
Les cookies ne feront pas.
J'ai besoin de la capacité de créer en principe un GUID unique et reproductible, en supposant qu'aucun changement matériel ne soit intervenu sur l'ordinateur. Les instructions auxquelles je pense obtiennent le code MAC de la carte réseau et d’autres informations de cette nature qui permettront à la machine de se rendre sur le site Web.
Ces personnes ont mis au point une méthode d’empreinte digitale permettant de reconnaître un utilisateur avec un niveau de précision élevé:
https://panopticlick.eff.org/static/browser-uniqueness.pdf
Nous étudions dans quelle mesure les navigateurs Web modernes sont soumis à une "empreinte digitale de périphérique" via les informations de version et de configuration qu'ils transmettront aux sites Web sur demande. Nous avons implémenté un algorithme d'empreinte digitale possible et avons collecté ces empreintes digitales à partir d'un large échantillon de navigateurs ayant visité notre site de test, panopticlick.eff.org . Nous observons que la distribution de nos empreintes digitales contient au moins 18,1 bits d'entropie, ce qui signifie que si nous choisissons un navigateur au hasard, nous nous attendons au mieux à ce qu'un seul des 286 777 autres navigateurs partage son empreinte digitale. Parmi les navigateurs prenant en charge Flash ou Java, la situation est encore pire: le navigateur moyen contient au moins 18,8 bits d'informations d'identification. 94,2% des navigateurs avec Flash ou Java étaient uniques dans notre échantillon.
En observant les visiteurs fidèles, nous estimons à quelle vitesse les empreintes digitales des navigateurs peuvent changer avec le temps. Dans notre échantillon, les empreintes digitales changeaient assez rapidement, mais même une simple heuristique était généralement capable de deviner quand une empreinte digitale était une version "améliorée" de l'empreinte digitale d'un navigateur précédemment observé, avec 99,1% des suppositions correctes et un taux de faux positif de seulement 0,86%. .
Nous discutons des empreintes digitales des navigateurs qui menacent la confidentialité des données personnelles en pratique et des mesures qui pourraient être prises pour les éviter. Il existe un compromis entre la protection contre l’empreinte digitale et certains types de débogage, ce qui, dans les navigateurs actuels, pèse lourdement sur la confidentialité. Paradoxalement, les technologies de confidentialité anti-empreintes digitales peuvent être contre-productives si elles ne sont pas utilisées par un nombre suffisant de personnes; nous montrons que certaines mesures de protection de la vie privée sont actuellement victimes de ce paradoxe, mais pas d'autres ...
Introduction
Je ne sais pas s'il existe ou ne sera jamais un moyen d'identifier de manière unique les machines à l'aide d'un navigateur uniquement. Les principales raisons sont:
- Vous devrez enregistrer les données sur l'ordinateur de l'utilisateur. Ces données peuvent être supprimées par l'utilisateur à tout moment. Sauf si vous avez un moyen de recréer ces données qui sont uniques pour chaque machine, votre ordinateur est bloqué.
- Validation. Vous devez vous protéger contre l'usurpation d'identité, le détournement de session, etc.
Même s'il existe des moyens de suivre un ordinateur sans utiliser de cookies, il y aura toujours un moyen de le contourner et les logiciels le feront automatiquement. Si vous avez vraiment besoin de suivre quelque chose sur un ordinateur, vous devrez écrire une application native (Apple Store/Android Store/Programme Windows/etc).
Je ne serais peut-être pas en mesure de vous répondre à la question que vous avez posée mais je peux vous montrer comment implémenter le suivi de session. Avec le suivi de session, vous essayez de suivre la session de navigation au lieu de l'ordinateur visitant votre site. En suivant la session, votre schéma de base de données ressemblera à ceci:
sesssion:
sessionID: string
// Global session data goes here
computers: [{
BrowserID: string
ComputerID: string
FingerprintID: string
userID: string
authToken: string
ipAddresses: ["203.525....", "203.525...", ...]
// Computer session data goes here
}, ...]
Avantages du suivi basé sur la session:
- Pour les utilisateurs connectés, vous pouvez toujours générer le même identifiant de session à partir des utilisateurs
username/password/email. - Vous pouvez toujours suivre les utilisateurs invités en utilisant
sessionID. - Même si plusieurs personnes utilisent le même ordinateur (cybercafé), vous pouvez les suivre séparément si elles se connectent.
Inconvénients du suivi basé sur la session:
- Les sessions sont basées sur un navigateur et non sur un ordinateur. Si un utilisateur utilise 2 navigateurs différents, il en résulte 2 sessions différentes. Si cela pose un problème, vous pouvez arrêter de lire ici.
- Les sessions expirent si l'utilisateur n'est pas connecté. Si un utilisateur n'est pas connecté, il utilisera une session d'invité qui sera invalidée si l'utilisateur supprime les cookies et le cache du navigateur.
La mise en oeuvre
Il y a plusieurs façons de mettre cela en œuvre. Je ne pense pas pouvoir tout couvrir. Je vais simplement énumérer mon préféré, ce qui en ferait une réponse avec opinion . Gardez cela à l'esprit.
Les bases
Je vais suivre la session en utilisant ce qu'on appelle un cookie pour toujours. Ce sont des données qui se recréeront automatiquement même si l'utilisateur supprime ses cookies ou met à jour son navigateur. Cependant, il ne survivra pas à la suppression par l'utilisateur de ses cookies et de son cache de navigation.
Pour implémenter cela, je vais utiliser le mécanisme de mise en cache des navigateurs ( [~ # ~] rfc [~ # ~] ), API WebStorage ( [~ # ~ ] mdn [~ # ~] ) et cookies de navigateur ( [~ # ~] rfc [~ # ~] , Google Analytics ).
Légal
Afin d'utiliser les identifiants de suivi, vous devez les ajouter à la fois à votre politique de confidentialité et à vos conditions d'utilisation, de préférence sous la sous-rubrique Suivi . Nous allons utiliser les clés suivantes sur document.cookie Et window.localStorage:
- _ ga : données Google Analytics
- __ utma : cookie de suivi Google Analytics
- sid : ID de session
Assurez-vous d'inclure des liens vers votre politique de confidentialité et vos conditions d'utilisation sur toutes les pages qui utilisent le suivi.
Où dois-je stocker mes données de session?
Vous pouvez stocker vos données de session dans la base de données de votre site Web ou sur l'ordinateur de l'utilisateur. Comme je travaille normalement sur des sites plus petits (plus de 10 000 connexions continues) qui utilisent des applications tierces (Google Analytics/Clicky/etc.), il est préférable pour moi de stocker des données sur l'ordinateur client. Cela présente les avantages suivants:
- Aucune recherche dans la base de données/surcharge/charge/latence/espace/etc.
- L'utilisateur peut supprimer ses données à tout moment sans avoir besoin de m'écrire des courriels ennuyeux.
et inconvénients:
- Les données doivent être chiffrées/déchiffrées et signées/vérifiées, ce qui crée une surcharge de traitement du processeur sur le client (pas si mal) et le serveur (bah!).
- Les données sont supprimées lorsque l'utilisateur supprime ses cookies et son cache. (c'est ce que je veux vraiment)
- Les données ne sont pas disponibles pour l'analyse lorsque les utilisateurs passent en mode hors connexion. (analyse pour les utilisateurs actuellement en navigation uniquement)
UUIDS
- BrowserID : identifiant unique généré à partir de la chaîne d'agent utilisateur des navigateurs.
Browser|BrowserVersion|OS|OSVersion|Processor|MozzilaMajorVersion|GeckoMajorVersion - ComputerID : généré à partir de l'adresse IP et de la clé de session HTTPS de l'utilisateur.
getISP(requestIP)|getHTTPSClientKey() - FingerPrintID : empreinte basée sur JavaScript et basée sur une empreinte digitale.js modifiée .
FingerPrint.get() - SessionID : clé aléatoire générée lors de la première visite du site par l'utilisateur.
BrowserID|ComputerID|randombytes(256) - GoogleID : généré à partir du cookie
__utma.getCookie(__utma).uniqueid
Mécanisme
L'autre jour, je regardais le show de wendy williams avec ma petite amie et j'étais complètement horrifié lorsque l'hôte a conseillé à ses téléspectateurs de supprimer l'historique de leurs navigateurs au moins une fois par mois. La suppression de l'historique du navigateur a normalement les effets suivants:
- Supprime l'historique des sites Web visités.
- Supprime les cookies et
window.localStorage(Aww man).
La plupart des navigateurs modernes rendent cette option disponible, mais ne craignez pas les amis. Car il y a une solution. Le navigateur dispose d’un mécanisme de mise en cache pour stocker les scripts/images et autres éléments. Habituellement, même si nous supprimons notre historique, le cache de ce navigateur reste toujours. Tout ce dont nous avons besoin est un moyen de stocker nos données ici. Il y a 2 méthodes pour le faire. Le mieux consiste à utiliser une image SVG et à stocker nos données dans ses balises. De cette façon, les données peuvent toujours être extraites même si JavaScript est désactivé à l'aide de Flash. Cependant, comme c'est un peu compliqué, je vais démontrer l'autre approche qui utilise JSONP ( Wikipedia )
example.com/assets/js/tracking.js (en fait, tracking.php)
var now = new Date();
var window.__sid = "SessionID"; // Server generated
setCookie("sid", window.__sid, now.setFullYear(now.getFullYear() + 1, now.getMonth(), now.getDate() - 1));
if( "localStorage" in window ) {
window.localStorage.setItem("sid", window.__sid);
}
Maintenant, nous pouvons obtenir notre clé de session à tout moment:
window.__sid || window.localStorage.getItem("sid") || getCookie("sid") || ""
Comment faire en sorte que tracking.js reste dans le navigateur?
Nous pouvons y arriver en utilisant Cache-Control , Last-Modified et ETag En-têtes HTTP. Nous pouvons utiliser le SessionID comme valeur pour l'en-tête etag:
setHeaders({
"ETag": SessionID,
"Last-Modified": new Date(0).toUTCString(),
"Cache-Control": "private, max-age=31536000, s-max-age=31536000, must-revalidate"
})
L'en-tête Last-Modified Indique au navigateur que ce fichier n'est fondamentalement jamais modifié. Cache-Control Indique aux mandataires et aux passerelles de ne pas mettre le document en cache, mais au navigateur de le mettre en cache pendant un an.
La prochaine fois que le navigateur demandera le document, il enverra les en-têtes If-Modified-Since Et If-None-Match. Nous pouvons les utiliser pour renvoyer une réponse 304 Not Modified.
example.com/assets/js/tracking.php
$sid = getHeader("If-None-Match") ?: getHeader("if-none-match") ?: getHeader("IF-NONE-MATCH") ?: "";
$ifModifiedSince = hasHeader("If-Modified-Since") ?: hasHeader("if-modified-since") ?: hasHeader("IF-MODIFIED-SINCE");
if( validateSession($sid) ) {
if( sessionExists($sid) ) {
continueSession($sid);
send304();
} else {
startSession($sid);
send304();
}
} else if( $ifModifiedSince ) {
send304();
} else {
startSession();
send200();
}
Maintenant, chaque fois que le navigateur demande tracking.js, Notre serveur répond avec un résultat 304 Not Modified Et force l'exécution de la copie locale de tracking.js.
Je ne comprends toujours pas. Expliquez-moi
Supposons que l'utilisateur efface son historique de navigation et actualise la page. La seule chose qui reste sur l'ordinateur de l'utilisateur est une copie de tracking.js Dans le cache du navigateur. Lorsque le navigateur demande tracking.js, Il reçoit une réponse 304 Not Modified Qui lui permet d'exécuter la première version de tracking.js Qu'il a reçue. tracking.js Exécute et restaure le SessionID qui a été supprimé.
Validation
Supposons que Haxor X vole les cookies de nos clients alors qu'ils sont toujours connectés. Comment les protégeons-nous? Cryptographie et empreinte de navigateur à la rescousse. Rappelez-vous notre définition originale de SessionID était:
BrowserID|ComputerID|randomBytes(256)
Nous pouvons changer cela en:
Timestamp|BrowserID|ComputerID|encrypt(randomBytes(256), hk)|sign(Timestamp|BrowserID|ComputerID|randomBytes(256), hk)
Où hk = sign(Timestamp|BrowserID|ComputerID, serverKey).
Nous pouvons maintenant valider notre SessionID en utilisant l'algorithme suivant:
if( getTimestamp($sid) is older than 1 year ) return false;
if( getBrowserID($sid) !== createBrowserID($_Request, $_Server) ) return false;
if( getComputerID($sid) !== createComputerID($_Request, $_Server) return false;
$hk = sign(getTimestamp($sid) + getBrowserID($sid) + getComputerID($sid), $SERVER["key"]);
if( !verify(decrypt(getRandomBytes($sid)), getSignature($sid), $hk) ) return false;
return true;
Maintenant, pour que l'attaque de Haxor fonctionne, ils doivent:
- Avoir même
ComputerID. Cela signifie qu'ils doivent avoir le même fournisseur d'accès Internet que la victime (Tricky). Cela donnera à notre victime la possibilité d'intenter une action en justice dans son propre pays. Haxor doit également obtenir la clé de session HTTPS auprès de la victime (dure). - Avoir même
BrowserID. Tout le monde peut usurper la chaîne User-Agent (ennuyeux). - Être capable de créer leur propre faux
SessionID(très difficile). Volume atack ne fonctionnera pas car nous utilisons un horodatage pour générer la clé de cryptage/signature, ce qui revient essentiellement à générer une nouvelle clé pour chaque session. En plus de cela, nous chiffrons des octets aléatoires, de sorte qu'une attaque par dictionnaire est également hors de question.
Nous pouvons améliorer la validation en transférant GoogleID et FingerprintID (via des champs ajax ou cachés) et en les comparant à ceux-ci.
if( GoogleID != getStoredGoodleID($sid) ) return false;
if( byte_difference(FingerPrintID, getStoredFingerprint($sid) > 10%) return false;
Une possibilité utilise cookies flash :
- Disponibilité omniprésente (95% des visiteurs auront probablement le flash)
- Vous pouvez stocker plus de données par cookie (jusqu'à 100 Ko)
- Partagé sur plusieurs navigateurs, donc plus susceptible d'identifier de manière unique une machine
- Effacer les cookies du navigateur ne supprime pas les cookies flash.
Vous aurez besoin de créer un petit film flash (caché) pour les lire et les écrire.
Quel que soit le chemin que vous choisissez, assurez-vous que vos utilisateurs choisissent IN de se faire suivre, sinon vous empiétez sur leur vie privée et devenez l'un des méchants.
Il est impossible d'identifier les ordinateurs accédant à un site Web sans la coopération de leurs propriétaires. Toutefois, s’ils vous le permettent, vous pouvez enregistrer un cookie pour identifier la machine lorsqu’elle visite à nouveau votre site. La clé est que le visiteur est en contrôle; ils peuvent supprimer le cookie et apparaître en tant que nouveau visiteur à tout moment.
Vous voudrez peut-être essayer de définir un identifiant unique dans un evercookie (cela fonctionnera sur plusieurs navigateurs, consultez leur FAQ): http://samy.pl/evercookie/
Il existe également une société appelée ThreatMetrix qui est utilisée par beaucoup de grandes entreprises pour résoudre ce problème: http://threatmetrix.com/our-solutions/solutions-by-product/trustdefender-id/ Ils sont assez chers et certains de leurs autres produits ne sont pas très bons, mais leur identifiant de périphérique fonctionne bien.
Enfin, il y a cette implémentation open source de l’idée panopticlick: https://github.com/carlo/jquery-browser-fingerprint Elle est jolie à moitié cuite à l’heure actuelle mais pourrait être développée.
J'espère que ça aide!
Il existe une méthode populaire appelée empreinte de toile, décrite dans cet article scientifique: Le Web n'oublie jamais: les mécanismes de suivi persistants à l'état sauvage . Une fois que vous avez commencé à le rechercher, vous serez surpris de la fréquence d'utilisation. La méthode crée une empreinte unique, cohérente pour chaque combinaison navigateur/matériel.
L'article passe également en revue d'autres méthodes de suivi persistant, telles que les cookies toujours créatifs, le réapparition des cookies HTTP et Flash et la synchronisation des cookies.
Plus d'informations sur les empreintes de toile ici:
Il n’ya que peu d’informations que vous pouvez obtenir via une connexion HTTP.
IP - Mais comme d’autres l’ont dit, cela n’est pas résolu pour beaucoup, sinon la plupart des utilisateurs d’Internet, en raison des politiques d’allocation dynamique de leur FAI.
Useragent String - Presque tous les navigateurs envoient quel type de navigateur ils sont à chaque demande. Cependant, cela peut être défini par l'utilisateur dans de nombreux navigateurs aujourd'hui.
Collection de champs de requête - Il existe d'autres champs envoyés avec chaque requête, tels que les codages pris en charge, etc. Ceux-ci, s'ils sont utilisés dans leur ensemble, peuvent aider à identifier la machine d'un utilisateur, mais ils dépendent également du navigateur et peuvent être modifiés.
Cookies - La définition d’un cookie est un autre moyen d’identifier une machine, ou plus précisément un navigateur sur une machine, mais comme d’autres l'ont déjà dit, ils peuvent être supprimés ou désactivés par les utilisateurs et ne s'appliquent que sur un navigateur. machine.
La réponse correcte est donc que vous ne pouvez pas atteindre ce que vous vivez via les seuls protocoles HTTP sur IP. Cependant, en utilisant une combinaison de cookies, ainsi que d'IP et des champs de la requête HTTP, vous avez une bonne chance de deviner, en quelque sorte, de quelle machine il s'agit. Les utilisateurs ont tendance à utiliser un seul navigateur, et souvent à partir d'une seule machine. Cela peut donc être relativement fiable, mais cela varie en fonction du public cible ... les techniciens sont plus susceptibles de gâcher ce genre de choses et utilisent plus de machines/navigateurs. En outre, cela pourrait même être associé à une tentative de géolocalisation de l'IP et à l'utilisation de ces données. Mais dans tous les cas, il n’ya pas de solution qui soit correcte tout le temps.
Il existe des failles dans les approches cookie et non-cookie. Mais si vous pouvez pardonner les inconvénients de l’approche des cookies, voici une idée.
Si vous utilisez déjà Google Analytics sur votre site, vous n'avez pas besoin d'écrire de code pour suivre vous-même des utilisateurs uniques. Google Analytics le fait pour vous via la valeur du cookie __utma, Comme décrit dans documentation de Google . Et en réutilisant cette valeur, vous ne créez pas de charge supplémentaire de cookie, ce qui présente des avantages en termes d'efficacité avec les demandes de page.
Et vous pourriez écrire du code assez facilement pour accéder à cette valeur, ou utiliser la fonction de ce scriptgetUniqueId().
Comme pour les solutions précédentes, les cookies sont une bonne méthode, sachez qu’ils identifient navigateurs bien. Si je visitais un site Web dans Firefox, puis dans Internet Explorer, les cookies seraient stockés séparément pour les deux tentatives. Certains utilisateurs désactivent également les cookies (mais davantage de personnes désactivent JavaScript).
Une autre méthode à considérer serait I.P. et l’identification du nom d’hôte (sachez que ceux-ci peuvent varier pour les utilisateurs IP distants/non statiques, AOL utilise également des adresses IP générales). Cependant, étant donné que cela identifie uniquement les réseaux, cela pourrait ne pas fonctionner aussi bien que les cookies.
Les suggestions d'utilisation des cookies mis à part, le seul ensemble complet d'attributs d'identification disponibles à interroger sont contenus dans l'en-tête de la requête HTTP. Il est donc possible d’utiliser un sous-ensemble de ceux-ci pour créer un pseudo-identifiant unique pour un agent d’utilisateur (navigateur, par exemple). En outre, la plupart de ces informations sont éventuellement déjà enregistrées dans le "journal d'accès" de votre logiciel de serveur Web par défaut et, si ce n'est pas le cas, peuvent être facilement configurées pour le faire. Ensuite, un outil pourrait être développé pour analyser simplement le contenu de ce journal en créant empreintes digitales de chaque demande composée, par exemple, de l'adresse IP et de la chaîne de l'agent utilisateur, etc. Le plus grand nombre de données disponibles, même le contenu de cookies spécifiques, ajoute à la qualité du caractère unique de cette empreinte digitale. Comme beaucoup d’autres l’ont déjà dit, le protocole HTTP ne le rend pas infaillible à 100% - au mieux, il ne peut qu’être un assez bon indicateur.
Lorsque j'utilise une machine qui n'a jamais visité mon site Web de services bancaires en ligne, on me demande une authentification supplémentaire. puis, si je retourne une seconde fois sur le site de banque en ligne, je ne reçois pas d'authentification supplémentaire ... J'ai supprimé tous les cookies dans IE et je suis rebrogé sur mon site de banque en ligne avec l'espoir d'être complètement A nouveau, à ma grande surprise, je n'ai pas posé de question sur l'authentification. Cela ne nous amène-t-il pas à croire que la banque effectue une sorte de marquage sur ordinateur qui n'implique pas de cookies?
C'est un type assez courant d'authentification utilisé par les banques.
Supposons que vous accédez au site Web de votre banque via example-isp.com. La première fois que vous y êtes, votre mot de passe vous sera demandé, ainsi qu'une authentification supplémentaire. Une fois que vous avez réussi, la banque sait que l'utilisateur "thatisvaliant" est authentifié pour accéder au site via example-isp.com.
À l'avenir, il ne demandera pas d'authentification supplémentaire (au-delà de votre mot de passe) lorsque vous accédez au site via example-isp.com. Si vous essayez d'accéder à la banque via un autre site-isp.com, la banque effectuera à nouveau la même procédure.
Donc, pour résumer, ce que la banque identifie est votre FAI et/ou netblock, en fonction de votre adresse IP. Évidemment, tous les utilisateurs de votre fournisseur de services Internet ne sont pas vous, ce qui explique pourquoi la banque vous demande toujours votre mot de passe.
Avez-vous déjà appelé une société émettrice de cartes de crédit pour vérifier que tout allait bien lorsque vous utilisez une carte de crédit dans un autre pays? Même concept.
En réalité, ce que vous voulez faire ne peut pas être fait car les protocoles ne le permettent pas. Si les adresses IP statiques étaient utilisées universellement, vous pourriez peut-être le faire. Ils ne le sont pas, donc vous ne pouvez pas.
Si vous voulez vraiment identifier personnes, demandez-leur de se connecter.
Comme ils se déplaceront probablement sur différentes pages de votre site Web, vous avez besoin d'un moyen de les suivre au fur et à mesure qu'ils se déplacent.
Tant qu'ils sont connectés et que vous suivez leur session sur votre site via des cookies/paramètres de liens/balises/peu importe, vous pouvez être certain qu'ils utilisent le même ordinateur pendant cette période.
En fin de compte, il est incorrect de dire que cela vous indique quel ordinateur ils utilisent si vos utilisateurs n'utilisent pas votre propre réseau local et ne possèdent pas d'adresses IP statiques.
Si ce que vous voulez faire est fait avec la coopération des utilisateurs et qu'il n'y a qu'un seul utilisateur par cookie et qu'ils utilisent un seul navigateur Web, utilisez simplement un cookie.
Parce que je veux que la solution fonctionne sur toutes les machines et tous les navigateurs (dans des limites raisonnables), j'essaie de créer une solution à l'aide de javascript.
N’est-ce pas une très bonne raison pas d’utiliser javascript?
Comme d'autres l'ont déjà dit, les cookies sont probablement votre meilleure option. Soyez simplement conscient des limites.
Les cookies ne seront pas utiles pour déterminer les visiteurs uniques. Un utilisateur peut supprimer les cookies et actualiser le site. Il est à nouveau classé comme nouvel utilisateur.
Je pense que la meilleure façon de procéder consiste à implémenter une solution côté serveur (car vous aurez besoin d’un endroit pour stocker vos données). En fonction de la complexité de vos besoins pour de telles données, vous devrez déterminer ce qui constitue une visite unique. Une méthode judicieuse serait de permettre à une adresse IP de revenir le lendemain et de recevoir une visite unique. Plusieurs visites d'une même adresse IP en une journée ne doivent pas être considérées comme uniques.
En utilisant PHP, par exemple, il est facile d’obtenir l’adresse IP d’un visiteur et de la stocker dans un fichier texte (ou une base de données SQL).
Une solution côté serveur fonctionnera sur toutes les machines, car vous allez suivre l'utilisateur lorsqu'il charge votre site pour la première fois. N'utilisez pas javascript, car il est destiné aux scripts côté client. En outre, l'utilisateur peut l'avoir désactivé dans tous les cas.
J'espère que ça t'as aidé.
Vous pouvez utiliser fingerprintjs2
new Fingerprint2().get(function(result, components) {
console.log(result) // a hash, representing your device fingerprint
console.log(components) // an array of FP components
//submit hash and JSON object to the server
})
Après cela, vous pouvez comparer tous les utilisateurs existants et vérifier la similarité JSON. Ainsi, même si leur empreinte digitale mute, vous pouvez toujours les suivre.
Je suppose que le verdict est que je ne peux pas identifier de manière unique, par programme, un ordinateur qui visite mon site Web.
J'ai la question suivante. Lorsque j'utilise une machine qui n'a jamais visité mon site Web de services bancaires en ligne, on me demande une authentification supplémentaire. puis, si je retourne une seconde fois sur le site de banque en ligne, je ne me fais pas demander l’authentification supplémentaire. En lisant les réponses à ma question, j'ai décidé qu'il devait s'agir d'un cookie. Par conséquent, j'ai supprimé tous les cookies dans IE et me suis connecté de nouveau sur mon site bancaire en ligne, m'attendant à ce que les questions d'authentification soient à nouveau posées. À ma grande surprise, rien ne m'a été demandé. fait-il une sorte de marquage de pc qui n'implique pas des cookies?
de plus, après avoir passé beaucoup de temps sur Google, j’ai trouvé la société suivante qui prétend vendre une solution permettant d’identifier de manière unique les machines qui visitent un site Web. http://www.the41.com/products.asp .
j'apprécie toutes les informations utiles si vous pouviez clarifier davantage ces informations contradictoires. Je les aurais grandement appréciées.
Je le ferais en utilisant une combinaison de cookies et de cookies flash. Créez un GUID et stockez-le dans un cookie. Si le cookie n'existe pas, essayez de le lire à partir du cookie flash. S'il n'est toujours pas trouvé, créez-le et écrivez-le dans le flash cookie. De cette façon, vous pouvez partager le même GUID entre les navigateurs.
Je pense que les cookies pourraient être ce que vous recherchez; C'est ainsi que la plupart des sites Web identifient de manière unique les visiteurs.
En supposant que vous ne voulez pas que l'utilisateur soit en contrôle, vous ne pouvez pas. Le Web ne fonctionne pas comme ça, le mieux que vous puissiez espérer, ce sont des heuristiques.
S'il est possible d'obliger votre visiteur à installer un logiciel et à utiliser TCPA, vous pourrez peut-être tirer quelque chose.
n tour:
Créez 2 pages d'inscription:
Première page d'inscription: sans aucun email ni contrôle de sécurité (avec juste un nom d'utilisateur et un mot de passe)
Deuxième page d'inscription: avec un niveau de sécurité élevé (demande de vérification de courrier électronique, image de sécurité, etc.)
Pour satisfaire le client et faciliter l’enregistrement, la page d’enregistrement par défaut doit être (Première page d’enregistrement) mais dans (Première page d’enregistrement), il existe une restriction masquée. C'est la restriction IP. Si une adresse IP tente de s’enregistrer pour la deuxième fois (par exemple, moins de 1 heure) au lieu d’afficher la page de blocage. vous pouvez afficher le (Deuxième page d'inscription) automatiquement.
- dans le (Première page d'inscription) vous pouvez définir (par exemple: bloquer 2 tentatives à partir d'une adresse IP pour seulement 1 heure ou 24 heures) et après (par exemple) 1 heure, vous pouvez ouvrir l'accès à partir de cette ip automatiquement
Remarque: (Première page d'inscription) et (Deuxième page d'inscription) ne doit pas figurer dans des pages séparées. vous faites juste 1 page. (par exemple: register.php) et assurez-vous qu'il est judicieux de basculer entre First PHP Style et Second PHP Style
Mon message n'est peut-être pas une solution, mais je peux vous donner un exemple dans lequel cette fonctionnalité a été mise en œuvre.
Si vous visitez la page d'inscription de www.supertorrents.org pour la première fois depuis votre ordinateur, ça va. Mais si vous actualisez la page ou rouvrez la page, cela indique que vous avez déjà visité la page. La vraie beauté vient ici - elle identifie même si vous réinstallez Windows ou un autre système d'exploitation.
J'ai lu quelque part qu'ils stockent l'ID du processeur. Bien que je ne puisse pas trouver comment ils le font, j'en doute sérieusement et ils pourraient utiliser l'adresse MAC pour le faire.
Je vais certainement partager si je trouve comment le faire.