我觉得饼干可能就是你要找的东西;这是大多数网站唯一识别访问者的方式。

如果没有用户的合作，识别访问网站的电脑是不可能的。但是，如果他们允许，您可以存储一个cookie，以便在机器再次访问您的网站时识别它。关键在于，访问者是可控的;他们可以删除cookie，并随时以新访客的身份出现。

cookie对于确定唯一访问者没有用处。用户可以清除cookie并刷新网站，然后他将再次被归类为新用户。

我认为最好的方法是实现一个服务器端解决方案(因为您需要某个地方来存储数据)。根据您对此类数据需求的复杂程度，您将需要确定哪些是唯一访问。一个明智的方法是允许一个IP地址在第二天返回，并给予一个唯一的访问。同一IP地址在一天内的多次访问不应被视为唯一的。

例如，使用PHP，获取访问者的IP地址并将其存储在文本文件(或sql数据库)中是很简单的。

服务器端解决方案可以在所有机器上工作，因为您将在用户第一次加载您的网站时跟踪用户。不要使用javascript，因为这意味着客户端脚本，而且用户可能在任何情况下都禁用了它。

希望这能有所帮助。

与前面的解决方案一样，cookie是一个很好的方法，但要注意它们可以识别浏览器。如果我先用火狐浏览器访问一个网站，然后再用ie浏览器访问，两次访问都会分别存储cookie。一些用户也禁用cookie(但更多的人禁用JavaScript)。

另一种需要考虑的方法是IP和主机名标识(请注意，对于拨号/非静态IP用户，这些可能有所不同，AOL也使用通用IP)。然而，由于这只识别网络，这可能不像cookie那样工作。

一种可能是使用flash cookie:

无处不在的可用性(95%的访问者可能会使用flash) 每个cookie可以存储更多数据(最多100 KB) 跨浏览器共享，因此更有可能唯一标识一台机器 清除浏览器cookie不会删除flash cookie。

你需要构建一个小的(隐藏的)flash电影来读写它们。

无论你选择哪种方式，确保你的用户选择被跟踪，否则你就侵犯了他们的隐私，成为坏人之一。

因为我想解决方案工作在所有机器和所有浏览器(在合理的范围内)，我试图使用javascript创建一个解决方案。

这难道不是一个不使用javascript的好理由吗?

正如其他人所说，饼干可能是你最好的选择，但要知道它的局限性。

假设您不希望用户拥有控制权，那么您就不能这样做。网络并不是这样工作的，你能期望的最好的是一些启发式。

如果你可以强迫访问者安装一些软件并使用TCPA，你可能会成功。

实际上，您想做的事情无法实现，因为协议不允许这样做。如果静态ip被普遍使用，那么你可能就能做到这一点。它们不是，所以你不能。

如果您真的想要识别用户，请让他们登录。

因为它们可能会移动到你网站上的不同页面，你需要一种方法来跟踪它们的移动。

只要他们登录了，你就可以通过cookie /链接参数/信标等跟踪他们在你网站上的会话，你就可以很确定他们在这段时间内使用的是同一台计算机。

最终，如果你的用户没有使用你自己的本地网络，也没有静态IP地址，说这能告诉你他们在使用哪台计算机是不正确的。

如果你想要做的事情是在用户的合作下完成的，每个cookie只有一个用户，他们使用单一的网络浏览器，那就使用cookie。

通过HTTP连接只能获得少量信息。

IP - But as others have said, this is not fixed for many, if not most Internet users due to their ISP's dynamic allocation policies. Useragent String - Nearly all browsers send what kind of browser they are with every request. However, this can be set by the user in many browsers today. Collection of request fields - There are other fields sent with each request, such as supported encodings, etc. These, if used in the aggregate can help to ID a user's machine, but again are browser dependent and can be changed. Cookies - Setting a cookie is another way to identify a machine, or more specifically a browser on a machine, but as others have said, these can be deleted, or turned off by the users, and are only applicable on a browser, not a machine.

So, the correct response is that you cannot achieve what you would live via the HTTP over IP protocols alone. However, using a combination of cookies, as well as IP, and the fields in the HTTP request, you have a good chance at guessing, sort of, what machine it is. Users tend to use only one browser, and often from one machine, so this may be fairly relieable, but this will vary depending on the audience...techies are more likely to mess with this stuff, and use more machines/browsers. Additionally, this could even be coupled with some attempt to geo-locate the IP, and use that data as well. But in any case, there is no solution that will be correct all of the time.

我猜结论是我不能通过编程唯一地识别一台正在访问我的网站的计算机。

I have the following question. When i use a machine which has never visited my online banking web site i get asked for additional authentification. then, if i go back a second time to the online banking site i dont get asked the additional authentification. reading the answers to my question i decided it must be a cookie involved. therefore, i deleted all cookies in IE and relogged onto my online banking site fully expecting to be asked the authentification questions again. to my surprise i was not asked. doesnt this lead one to believe the bank is doing some kind of pc tagging which doesnt involve cookies?

此外，今天在谷歌搜索了很多之后，我发现了以下公司，他们声称出售一种解决方案，可以唯一地识别访问网站的机器。http://www.the41.com/products.asp。

我很感激所有好的信息，如果你能进一步澄清这些相互矛盾的信息，我将非常感激。

The suggestions to use cookies aside, the only comprehensive set of identifying attributes available to interrogate are contained in the HTTP request header. So it is possible to use some subset of these to create a pseudo-unique identifier for a user agent (i.e., browser). Further, most of this information is possibly already being logged in the so-called "access log" of your web server software by default and, if not, can be easily configured to do so. Then, a utlity could be developed that simply scans the content of this log, creating fingerprints of each request comprised of, say, the IP address and User Agent string, etc. The more data available, even including the contents of specific cookies, adds to the quality of the uniqueness of this fingerprint. Though, as many others have stated already, the HTTP protocol doesn't make this 100% foolproof - at best it can only be a fairly good indicator.

当我使用一台从未访问过我的网上银行网站的机器时，我被要求进行额外的身份验证。然后，如果我第二次回到网上银行网站，我不会被要求额外的身份验证……我删除了IE中的所有cookie，并重新登录到我的网上银行网站，完全期待再次被问到身份验证问题。令我吃惊的是，没有人问我。这难道不会让人相信银行正在做某种不涉及cookie的PC标记吗?

这是银行使用的一种非常常见的身份验证类型。

假设您正在通过example-isp.com访问您的银行网站。第一次登录时，系统会要求您输入密码，并进行额外的身份验证。一旦您通过了认证，银行就知道用户“thatisvaliant”已通过身份验证，可以通过example-isp.com访问该网站。

将来，当您通过example-isp.com访问该网站时，它将不会要求额外的身份验证(除了您的密码)。如果您试图通过another-isp.com访问该银行，该银行将再次执行相同的程序。

总之，银行识别的是你的ISP和/或网络块，基于你的IP地址。显然，ISP上的每个用户都不是你，这就是为什么银行仍然要求你输入密码的原因。

当你在另一个国家使用信用卡时，你有没有接到信用卡公司的电话来核实事情是否正常?相同的概念。

我将使用cookie和flash cookie的组合来做到这一点。创建一个GUID并将其存储在一个cookie中。如果cookie不存在，请尝试从flash cookie中读取它。如果仍未找到，则创建它并将其写入flash cookie。通过这种方式，您可以跨浏览器共享相同的GUID。

这些人开发了一种指纹识别方法，可以非常准确地识别用户:

https://panopticlick.eff.org/static/browser-uniqueness.pdf

We investigate the degree to which modern web browsers are subject to “device fingerprinting” via the version and configuration information that they will transmit to websites upon request. We implemented one possible fingerprinting algorithm, and collected these fingerprints from a large sample of browsers that visited our test side, panopticlick.eff.org. We observe that the distribution of our finger- print contains at least 18.1 bits of entropy, meaning that if we pick a browser at random, at best we expect that only one in 286,777 other browsers will share its fingerprint. Among browsers that support Flash or Java, the situation is worse, with the average browser carrying at least 18.8 bits of identifying information. 94.2% of browsers with Flash or Java were unique in our sample.

通过观察回访用户，我们估计浏览器指纹随时间变化的速度。在我们的样本中，指纹变化很大 很快，但即使是一个简单的启发式通常也能猜出指纹是先前观察到的浏览器的“升级”版本 指纹，99.1%的猜测正确率和假阳性率只有 0.86%。

We discuss what privacy threat browser fingerprinting poses in practice, and what countermeasures may be appropriate to prevent it. There is a tradeoff between protection against fingerprintability and certain kinds of debuggability, which in current browsers is weighted heavily against privacy. Paradoxically, anti-fingerprinting privacy technologies can be self- defeating if they are not used by a sufficient number of people; we show that some privacy measures currently fall victim to this paradox, but others do not.

你可能想尝试在evercookie中设置一个唯一的ID(它可以跨浏览器工作，见他们的常见问题): http://samy.pl/evercookie/

还有一家叫做ThreatMetrix的公司，被很多大公司用来解决这个问题: http://threatmetrix.com/our-solutions/solutions-by-product/trustdefender-id/ 它们相当昂贵，而且他们的其他一些产品也不太好，但他们的设备id运行良好。

最后，还有这个开源jquery实现的panopticlick的想法: https://github.com/carlo/jquery-browser-fingerprint 它现在看起来很不成熟，但可以扩展。

希望能有所帮助!

cookie和非cookie方法都有缺陷。但是如果你能原谅cookie方法的缺点，这里有一个想法。

如果你已经在你的网站上使用谷歌Analytics，那么你不需要自己编写代码来跟踪独特的用户。谷歌分析为您通过__utma cookie值，如谷歌的文档中所述。通过重用这个值，您不会创建额外的cookie有效负载，这对于页面请求具有效率优势。

您可以很容易地编写一些代码来访问该值，或者使用脚本的getUniqueId()函数。

我的文章可能不是一个解决方案，但我可以提供一个例子，这个功能已经实现。

如果你第一次在电脑上访问www.supertorrents.org的注册页面，没问题。但如果您刷新页面或再次打开页面，它会识别出您之前访问过该页面。真正的美妙之处在于——即使你重新安装Windows或其他操作系统，它也能识别出来。

我在某处读到，他们存储CPU ID。虽然我不知道他们是怎么做到的，但我非常怀疑，他们可能使用MAC地址来做到这一点。

如果我知道怎么做，我一定会分享的。

有一种流行的方法叫做“画布指纹”，在这篇科学文章《网络永不遗忘》中有描述: 野外的持久跟踪机制。一旦你开始寻找它，你会惊讶于它被使用的频率。该方法创建一个唯一的指纹，该指纹对于每个浏览器/硬件组合都是一致的。

本文还介绍了其他持久跟踪方法，如evercookie、respawning http和Flash cookie以及cookie同步。

更多关于画布指纹的信息:

完美像素:HTML5中的指纹画布 https://en.wikipedia.org/wiki/Canvas_fingerprinting

一个技巧:

Create 2 Registration Pages: First Registration Page: without any email or security check (just with username and password) Second Registration Page: with high security level (email verification request and security image and etc.) For customer satisfaction, and easy registration, default registration page should be the (First Registration Page) but in the (First Registration Page) there is a hidden restriction. It's IP Restriction. If an IP tried to register for second time, (for example less than 1 hour) instead of showing the block page. you can show the (Second Registration Page) automatically. in the (First Registration Page) you can set (for example: block 2 attempts from 1 ip for just 1 hour or 24 hours) and after (for example) 1 hour, you can open access from that ip automatically

请注意:(第一注册页)和(第二注册页)不应在分开的页面。你只写了一页。(例如:register.php)，并在第一PHP样式和第二PHP样式之间切换

简介

我不知道是否有一种方法可以单独使用浏览器来唯一地识别机器。主要原因有:

您需要在用户计算机上保存数据。这个数据可以是 用户可以随时删除。除非你有办法重现这个 每台机器的数据都是独一无二的，那么你就会陷入困境。 验证。您需要防范欺骗、会话劫持等。

即使有不使用cookie的方法来跟踪计算机，也总有办法绕过它，软件会自动做到这一点。如果你真的需要在计算机上跟踪一些东西，你就必须写一个本地应用程序(苹果商店/安卓商店/ Windows程序等)。

我可能不能给你你问的问题的答案，但我可以告诉你如何实现会话跟踪。使用会话跟踪，您可以尝试跟踪浏览会话，而不是计算机访问您的网站。通过跟踪会话，您的数据库模式将如下所示:

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
  }, ...]

基于会话跟踪的优点:

对于已登录的用户，您总是可以从用户的用户名/密码/电子邮件生成相同的会话id。 您仍然可以使用sessionID跟踪来宾用户。 即使几个人使用同一台电脑(例如网吧)，如果他们登录，你也可以分别跟踪他们。

基于会话跟踪的缺点:

会话是基于浏览器而不是基于计算机的。如果一个用户使用2个不同的浏览器，它将导致2个不同的会话。如果这是一个问题，你可以停止阅读这里。 如果用户没有登录，会话将过期。如果用户没有登录，那么他们将使用一个来宾会话，如果用户删除cookie和浏览器缓存，该会话将失效。

实现

有许多方法可以实现这一点。我不认为我能涵盖所有，我只列出我最喜欢的，这将使这成为一个固执己见的答案。记住这一点。

基础知识

我将使用所谓的永久cookie来跟踪会话。即使用户删除了他的cookie或更新了他的浏览器，这些数据也会自动恢复。然而，当用户删除他们的cookie和浏览缓存时，它将无法存活。

为了实现这一点，我将使用浏览器缓存机制(RFC)， WebStorage API (MDN)和浏览器cookie (RFC，谷歌Analytics)。

法律

为了使用跟踪id，您需要将它们添加到您的隐私政策和使用条款中，最好是在跟踪子标题下。我们将在两个文档上使用以下键。cookie和window.localStorage:

_ga:谷歌分析数据 __utma:谷歌分析跟踪cookie 席德:SessionID

确保在所有使用跟踪功能的页面上包含指向您的隐私政策和使用条款的链接。

会话数据存储在哪里?

您可以将会话数据存储在网站数据库中或用户计算机上。因为我通常在使用第三方应用程序(谷歌Analytics / Clicky / etc)的较小网站(让超过10,000个连续连接)上工作，所以对我来说，最好将数据存储在客户端计算机上。这样做有以下优点:

没有数据库查找/开销/负载/延迟/空间等。 用户可以随时删除他们的数据，而无需给我写烦人的电子邮件。

优缺点:

必须对数据进行加密/解密和签名/验证，这会在客户端和服务器上产生cpu开销(不是很糟糕)。 当用户删除他们的cookie和缓存时，数据将被删除。(这是我真正想要的) 当用户离线时，数据无法用于分析。(仅针对当前浏览用户的分析)

UUIDS

BrowserID: Unique id generated from the browsers user agent string. Browser|BrowserVersion|OS|OSVersion|Processor|MozzilaMajorVersion|GeckoMajorVersion ComputerID: Generated from users IP Address and HTTPS session key. getISP(requestIP)|getHTTPSClientKey() FingerPrintID: JavaScript based fingerprinting based on a modified fingerprint.js. FingerPrint.get() SessionID: Random key generated when user 1st visits site. BrowserID|ComputerID|randombytes(256) GoogleID: Generated from __utma cookie. getCookie(__utma).uniqueid

机制

前几天，我和女朋友一起看wendy williams的节目，主持人建议她的观众至少每月删除一次浏览器历史记录，这让我完全震惊了。删除浏览器历史记录通常有以下效果:

删除访问网站的历史记录。 删除cookie和窗口。localStorage (aww man)。

Most modern browsers make this option readily available but fear not friends. For there is a solution. The browser has a caching mechanism to store scripts / images and other things. Usually even if we delete our history, this browser cache still remains. All we need is a way to store our data here. There are 2 methods of doing this. The better one is to use a SVG image and store our data inside its tags. This way data can still be extracted even if JavaScript is disabled using flash. However since that is a bit complicated I will demonstrate the other approach which uses JSONP (Wikipedia)

Example.com/assets/js/tracking.js(实际上是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);
}

现在我们可以在任何时候获得会话密钥:

窗口。__sid || window.localStorage.getItem("sid") || getCookie("sid") || "" "

我如何让跟踪。js坚持在浏览器?

我们可以使用Cache-Control, Last-Modified和ETag HTTP头来实现这一点。我们可以使用SessionID作为etag头的值:

setHeaders({
  "ETag": SessionID,
  "Last-Modified": new Date(0).toUTCString(),
  "Cache-Control": "private, max-age=31536000, s-max-age=31536000, must-revalidate"
})

Last-Modified头文件告诉浏览器这个文件基本上从未被修改过。cache - control告诉代理和网关不缓存文档，但告诉浏览器缓存1年。

下次浏览器请求文档时，它将发送If-Modified-Since和If-None-Match标头。我们可以使用它们返回一个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();
}

现在，每次浏览器请求trace .js时，我们的服务器都会响应一个304 Not Modified结果，并强制执行trace .js的本地副本。

我还是不明白。给我解释一下

假设用户清除了他们的浏览历史并刷新了页面。用户计算机上只剩下浏览器缓存中的tracking.js副本。当浏览器请求tracking.js时，它会收到一个304 Not Modified响应，这导致它执行它收到的第一个版本的tracking.js。trace .js执行并恢复被删除的SessionID。

验证

假设Haxor X在客户仍在登录时窃取了他们的cookie。我们如何保护他们?密码学和浏览器指纹来拯救。还记得我们最初对SessionID的定义是:

BrowserID|ComputerID|randomBytes(256)

我们可以更改为:

Timestamp|BrowserID|ComputerID|encrypt(randomBytes(256), hk)|sign(Timestamp|BrowserID|ComputerID|randomBytes(256), hk)

Where hk = sign(时间戳|BrowserID|ComputerID, serverKey)。

现在我们可以使用下面的算法来验证我们的SessionID:

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(getTimestamp($sid) + getBrowserID($sid) + getComputerID($sid) + decrypt(getRandomBytes($sid), hk), getSignature($sid), $hk) ) return false;

return true; 

为了让哈克索的攻击奏效他们必须:

Have same ComputerID. That means they have to have the same ISP provider as victim (Tricky). This will give our victim the opportunity to take legal action in their own country. Haxor must also obtain HTTPS session key from victim (Hard). Have same BrowserID. Anyone can spoof User-Agent string (Annoying). Be able to create their own fake SessionID (Very Hard). Volume atacks won't work because we use a time-stamp to generate encryption / signing key so basically its like generating a new key for each session. On top of that we encrypt random bytes so a simple dictionary attack is also out of the question.

我们可以通过转发GoogleID和FingerprintID(通过ajax或隐藏字段)并根据它们进行匹配来改进验证。

if( GoogleID != getStoredGoodleID($sid) ) return false;
if( byte_difference(FingerPrintID, getStoredFingerprint($sid) > 10%) return false;

您可以使用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 
})

在此之后，您可以根据现有用户检查所有用户并检查JSON相似性，因此即使他们的指纹发生了突变，您仍然可以跟踪他们

我将从简单到复杂给出我的想法。 在上述所有情况下，您可以创建会话，问题本质上转换为匹配会话与请求。

A)(困难:简单)使用客户端硬件显式存储某种类型的会话id/哈希(有相当多的隐私/安全问题，所以确保你哈希任何你存储的东西)，解决方案包括:

cookie存储 浏览器存储/webDB/(更奇特的浏览器解决方案) 有权限将东西存储在文件中的扩展名。

上面的问题是，如果用户不想的话，他可以清空他的缓存。

b)(难度中等)登录认证。 大多数现代web框架都提供了这样的解决方案，核心思想是让用户自愿地识别自己，这很简单，但在架构上增加了复杂性。

上述内容的复杂性增加，本质上是非公开内容。

c)(困难:困难-研发)基于元数据的识别，(浏览器ip/语言/浏览器/和其他隐私侵犯的东西，所以一定要让你的用户知道，否则你可能会被起诉) 非完美解决方案可能会变得更加复杂(用户以特定频率输入或使用特定模式的鼠标?你甚至可以应用ML解决方案)。 声称的解决方案

这是最强大的，因为用户甚至可以在没有明确要求的情况下识别他。这是对隐私的直接侵犯(参见GDPR)，并不完美。IP可以改变。