Мне нужно найти способ уникальной идентификации каждого компьютера, который посещает веб-сайт, который я создаю. У кого-нибудь есть совет, как этого добиться?

Поскольку я хочу, чтобы решение работало на всех машинах и во всех браузерах (в пределах разумного), я пытаюсь создать решение с использованием JavaScript.

Печеньки не подойдут.

Мне нужна возможность в основном создать руководство, уникальное для компьютера и повторяемое, при условии, что с компьютером не произошло никаких изменений в оборудовании. Направления, о которых я думаю, это получение MAC-адреса сетевой карты и другой информации такого рода, которая будет идентифицировать машину, посещающую веб-сайт.

Эти люди разработали метод снятия отпечатков пальцев для распознавания пользователя с высоким уровнем точности:

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

Мы исследуем степень, в которой современные веб-браузеры подвергаются «дактилоскопированию устройства» с помощью информации о версии и конфигурации, которую они передают веб-сайтам по запросу. Мы реализовали один возможный алгоритм снятия отпечатков пальцев и собрали эти отпечатки пальцев из большой выборки браузеров, которые посетили нашу тестовую страницу , panopticlick.eff.org, Мы отмечаем, что распределение нашего отпечатка пальца содержит не менее 18,1 битов энтропии, а это означает, что если мы выберем браузер случайным образом, в лучшем случае мы ожидаем, что только один из 286777 других браузеров поделится его отпечатком. Среди браузеров, поддерживающих Flash или Java, ситуация хуже: средний браузер несет не менее 18,8 бит идентифицирующей информации. 94,2% браузеров с Flash или Java были уникальными в нашей выборке.

Наблюдая за постоянными посетителями, мы оцениваем, насколько быстро со временем могут изменяться отпечатки браузера. В нашей выборке отпечатки пальцев менялись довольно быстро, но даже простая эвристика обычно могла угадать, когда отпечаток пальца был «обновленной» версией ранее обнаруженного отпечатка браузера, с правильными 99,1% догадок и ошибочным положительным результатом, равным всего 0,86%. ,

Мы обсуждаем, что представляет собой на практике снятие отпечатков пальцев с угрозы конфиденциальности браузера, и какие контрмеры могут быть уместными для ее предотвращения. Существует компромисс между защитой от отпечатков пальцев и определенными видами отладки, которые в современных браузерах сильно отягощают конфиденциальность. Как это ни парадоксально, технологии защиты от отпечатков пальцев могут быть саморазрушительными, если они не используются достаточным количеством людей; мы показываем, что некоторые меры по обеспечению конфиденциальности в настоящее время становятся жертвами этого парадокса, а другие - нет ...

Введение

Я не знаю, есть ли или когда-нибудь найдется способ уникальной идентификации машин с помощью одного браузера. Основными причинами являются:

• Вам нужно будет сохранить данные на компьютере пользователя. Эти данные могут быть удалены пользователем в любое время. Если у вас нет способа воссоздать эти данные, которые являются уникальными для каждой машины, то вы застряли.
• Проверка. Вы должны остерегаться подделки, перехвата сеанса и т. Д.

Даже если есть способы отследить компьютер без использования файлов cookie, всегда найдется способ обойти его и программное обеспечение, которое сделает это автоматически. Если вам действительно нужно что-то отслеживать на компьютере, вам придется написать собственное приложение (Apple Store / Android Store / Windows Program / etc).

Возможно, я не смогу дать вам ответ на заданный вами вопрос, но я покажу вам, как реализовать отслеживание сеансов. С помощью отслеживания сеанса вы пытаетесь отслеживать сеанс просмотра, а не компьютер, посещающий ваш сайт. Отслеживая сеанс, ваша схема базы данных будет выглядеть так:

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

Преимущества отслеживания на основе сеанса:

1. Для зарегистрированных пользователей вы всегда можете сгенерировать один и тот же идентификатор сессии из пользователей username/ password/ email.
2. Вы все еще можете отслеживать гостевых пользователей, используя sessionID.
3. Даже если несколько человек используют один и тот же компьютер (например, интернет-кафе), вы можете отслеживать их отдельно, если они вошли в систему.

Недостатки отслеживания на основе сеанса:

1. Сессии основаны на браузере, а не на компьютере. Если пользователь использует 2 разных браузера, это приведет к 2 разным сеансам. Если это проблема, вы можете перестать читать здесь.
2. Сессии истекают, если пользователь не вошел в систему. Если пользователь не вошел в систему, то он будет использовать гостевой сеанс, который будет признан недействительным, если пользователь удалит файлы cookie и кэш браузера.

Реализация

Есть много способов реализации этого. Я не думаю, что смогу охватить их все, я просто перечислю свою любимую, что сделало бы этот самоуверенный ответ . Имейте это в виду.

основы

Я буду отслеживать сессию, используя так называемый файл cookie навсегда. Это данные, которые автоматически воссоздают себя, даже если пользователь удаляет свои куки или обновляет свой браузер. Тем не менее, пользователь не сможет удалить и свои куки, и кеш браузера.

Для реализации этого я буду использовать механизм кэширования браузеров ( RFC ), API WebStorage ( MDN ) и куки-файлы браузера ( RFC , Google Analytics ).

легальный

Чтобы использовать идентификаторы отслеживания, вам необходимо добавить их как в вашу политику конфиденциальности, так и в условия использования, предпочтительно в разделе « Отслеживание» . Мы будем использовать следующие клавиши на обоих document.cookieи window.localStorage:

• _ga : данные Google Analytics
• __utma : файл cookie для отслеживания Google Analytics
• sid : SessionID

Убедитесь, что вы включили ссылки на свою Политику конфиденциальности и условия использования на всех страницах, которые используют отслеживание.

Где я могу хранить свои данные сеанса?

Вы можете сохранить данные сеанса в базе данных вашего веб-сайта или на компьютере пользователя. Поскольку я обычно работаю на небольших сайтах (пусть более 10 тысяч непрерывных подключений), которые используют сторонние приложения (Google Analytics / Clicky / etc), лучше всего хранить данные на клиентском компьютере. Это имеет следующие преимущества:

1. Нет поиска в базе данных / накладные расходы / нагрузка / задержка / пробел / т. Д.
2. Пользователь может удалить свои данные в любое время без необходимости писать мне надоедливые электронные письма.

и недостатки:

1. Данные должны быть зашифрованы / дешифрованы и подписаны / проверены, что создает накладные расходы процессора на клиенте (не так уж плохо) и на сервере (ба!).
2. Данные удаляются, когда пользователь удаляет свои куки и кеш. (это то, что я действительно хочу)
3. Данные недоступны для аналитики, когда пользователи выходят в автономный режим. (аналитика только для пользователей, просматривающих в настоящее время)

UUIDs

• BrowserID : уникальный идентификатор, сгенерированный из строки пользовательского агента браузера.Browser|BrowserVersion|OS|OSVersion|Processor|MozzilaMajorVersion|GeckoMajorVersion
• ComputerID : генерируется из IP-адреса пользователя и сеансового ключа HTTPS. getISP(requestIP)|getHTTPSClientKey()
• FingerPrintID : снятие отпечатков на основе JavaScript на основе измененного fingerprint.js .FingerPrint.get()
• SessionID : случайный ключ, генерируемый при первом посещении сайта пользователем.BrowserID|ComputerID|randombytes(256)
• GoogleID : создан из __utmacookie.getCookie(__utma).uniqueid

Механизм

На днях я смотрел шоу Венди Уильямс с моей подругой и был совершенно в ужасе, когда хозяин посоветовал своим зрителям удалять историю браузера по крайней мере раз в месяц. Удаление истории браузера обычно имеет следующие эффекты:

1. Удаляет историю посещенных сайтов.
2. Удаляет печенье и window.localStorage(ооо человек).

Большинство современных браузеров делают эту опцию доступной, но не бойтесь друзей. Ибо есть решение. В браузере есть механизм кеширования для хранения скриптов / изображений и прочего. Обычно, даже если мы удаляем нашу историю, этот кеш браузера остается. Все, что нам нужно, это способ хранить наши данные здесь. Есть 2 способа сделать это. Лучше использовать SVG-изображение и хранить наши данные в его тегах. Таким образом, данные могут быть извлечены, даже если JavaScript отключен с помощью Flash. Однако, поскольку это немного сложно, я продемонстрирую другой подход, который использует JSONP ( Википедия )

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);
}

Теперь мы можем получить наш сессионный ключ в любое время:

window.__sid || window.localStorage.getItem("sid") || getCookie("sid") || ""

Как мне сделать track.js в браузере?

Мы можем добиться этого, используя HTTP-заголовки Cache-Control , Last-Modified и ETag . Мы можем использовать 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();
}

Теперь каждый раз, когда браузер запрашивает, tracking.jsнаш сервер ответит 304 Not Modifiedрезультатом и принудительно выполнит локальную копию tracking.js.

Я до сих пор не понимаю. Объясни мне

Предположим, что пользователь очищает свою историю просмотров и обновляет страницу. Единственное, что осталось на компьютере пользователя - это копия tracking.jsв кеше браузера. Когда браузер запрашивает, tracking.jsон получает 304 Not Modifiedответ, который заставляет его выполнить первую версиюtracking.js . tracking.jsвыполняет и восстанавливает то, SessionIDчто было удалено.

Проверка

Предположим, Haxor X крадет файлы cookie наших клиентов, пока они еще вошли в систему. Как мы защищаем их? Криптография и браузер снимают отпечатки пальцев на помощь. Запомните наше первоначальное определение SessionID:

BrowserID|ComputerID|randomBytes(256)

Мы можем изменить это на:

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

куда hk = sign(Timestamp|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; 

Теперь, чтобы атака Хаксора сработала, они должны:

1. Есть же ComputerID . Это означает, что у них должен быть тот же провайдер, что и у жертвы (Tricky). Это даст нашей жертве возможность подать в суд на свою страну. Хаксор также должен получить ключ сеанса HTTPS от жертвы (Hard).
2. Есть же BrowserID. Любой может подделать строку User-Agent (раздражает).
3. Уметь создавать свои собственные подделки SessionID(Very Hard). Объемные атаки не будут работать, потому что мы используем временную метку для генерации ключа шифрования / подписи, так что в основном это похоже на генерацию нового ключа для каждой сессии. Кроме того, мы шифруем случайные байты, поэтому о простой атаке по словарю также не может быть и речи.

Мы можем улучшить валидацию, перенаправляя GoogleIDи FingerprintID(через ajax или скрытые поля) и сопоставляя их.

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

Невозможно идентифицировать компьютеры, обращающиеся к веб-сайту, без сотрудничества их владельцев. Если они позволят вам, однако, вы можете сохранить куки, чтобы идентифицировать машину, когда он посещает ваш сайт снова. Ключ, посетитель контролирует; они могут удалить cookie и появиться в качестве нового посетителя в любое время.

Возможность использования флеш-куки :

• Повсеместная доступность (95 процентов посетителей, вероятно, будут иметь вспышку)
• Вы можете хранить больше данных на куки (до 100 КБ)
• Разделяется между браузерами, поэтому с большей вероятностью однозначно идентифицирует машину
• Очистка файлов cookie браузера не приводит к удалению файлов cookie Flash.

Вам нужно будет создать небольшой (скрытый) флэш-фильм, чтобы читать и писать их.

Какой бы маршрут вы ни выбрали, убедитесь, что ваши пользователи выбирают IN для отслеживания, в противном случае вы нарушаете их конфиденциальность и становитесь одним из плохих парней.

Вы можете попробовать установить уникальный идентификатор в evercookie (он будет работать в разных браузерах, см. Их часто задаваемые вопросы): http://samy.pl/evercookie/

Существует также компания ThreatMetrix, которая используется многими крупными компаниями для решения этой проблемы: http://threatmetrix.com/our-solutions/solutions-by-product/trustdefender-id/ Они довольно дорогие, и некоторые из другие их продукты не очень хороши, но их идентификатор устройства работает хорошо.

И наконец, есть реализация jquery с открытым исходным кодом идеи panopticlick: https://github.com/carlo/jquery-browser-fingerprint. На данный момент это выглядит довольно наполовину, но может быть расширено.

Надеюсь, поможет!

В этой научной статье описан популярный метод, называемый «снятие отпечатков пальцев»: «Сеть никогда не забывает: постоянные механизмы отслеживания в дикой природе». . Когда вы начнете искать его, вы будете удивлены, как часто он используется. Метод создает уникальный отпечаток пальца, который согласуется для каждой комбинации браузера и оборудования.

В статье также рассматриваются другие постоянные методы отслеживания, такие как evercookies, восстановление файлов cookie http и Flash и синхронизация cookie.

Подробнее о снятии отпечатков на холсте здесь:

• Pixel Perfect: Отпечатки холста в HTML5
• https://en.wikipedia.org/wiki/Canvas_fingerprinting

Существует только небольшое количество информации, которую вы можете получить через HTTP-соединение.

1. IP - но, как уже говорили другие, это не исправлено для многих, если не для большинства пользователей Интернета, из-за политики динамического распределения их ISP.

2. Useragent String - Почти все браузеры отправляют, какие они есть браузеры с каждым запросом. Однако это может быть установлено пользователем во многих браузерах сегодня.

3. Сбор полей запроса - есть другие поля, отправленные с каждым запросом, например, поддерживаемые кодировки и т. Д. Они, если они используются в совокупности, могут помочь идентифицировать компьютер пользователя, но опять-таки зависят от браузера и могут быть изменены.

4. Файлы cookie - установка файла cookie - это еще один способ идентификации компьютера или, более конкретно, браузера на компьютере, но, как говорили другие, они могут быть удалены или отключены пользователями и применимы только в браузере, а не в машина.

Таким образом, правильный ответ заключается в том, что вы не можете достичь того, что бы вы жили, используя только протоколы HTTP over IP. Однако, используя комбинацию файлов cookie, а также IP-адреса и полей в HTTP-запросе, у вас есть хороший шанс угадать, что это за машина. Пользователи, как правило, используют только один браузер, и часто с одного компьютера, так что это может быть довольно надежным, но это будет зависеть от аудитории ... техники, скорее всего, возятся с этим и используют больше машин / браузеров. Кроме того, это может даже сочетаться с некоторой попыткой геолокации IP и использования этих данных. Но в любом случае, не существует решения, которое будет правильным всегда.

Существуют недостатки как с использованием cookie, так и без использования cookie. Но если вы можете простить недостатки подхода cookie, вот идея.

Если вы уже используете Google Analytics на своем сайте, вам не нужно писать код для отслеживания уникальных пользователей самостоятельно. Google Analytics делает это для вас через __utmaзначение cookie, как описано в документации Google . И, повторно используя это значение, вы не создаете дополнительную полезную нагрузку на cookie, что дает преимущества в эффективности при запросах страниц.

И вы могли бы написать некоторый код достаточно легко, чтобы получить доступ к этому значению, или использовать функцию этого скрипта getUniqueId() .

Как и в предыдущих решениях, cookie-файлы являются хорошим методом, однако имейте в виду, что они идентифицируют браузеры . Если бы я посетил веб-сайт в Firefox, а затем в Internet Explorer, куки будут храниться для обеих попыток отдельно. Некоторые пользователи также отключают куки (но больше людей отключают JavaScript).

Другим методом, который следует рассмотреть, является идентификация IP и имени хоста (имейте в виду, что они могут различаться для коммутируемых / нестатических пользователей IP, AOL также использует общие IP). Однако, поскольку это только идентифицирует сети, это может работать не так, как куки.

Предложения об использовании файлов cookie, единственный полный набор идентифицирующих атрибутов, доступных для опроса, содержатся в заголовке HTTP-запроса. Таким образом, можно использовать некоторое их подмножество для создания псевдо-уникального идентификатора для пользовательского агента (т. Е. Браузера). Кроме того, большая часть этой информации, возможно, уже зарегистрирована в так называемом «журнале доступа» программного обеспечения вашего веб-сервера по умолчанию и, если нет, может быть легко настроена для этого. Затем может быть разработан целый набор, который просто сканирует содержимое этого журнала, создавая отпечатки пальцев.каждого запроса, состоящего, скажем, из IP-адреса и строки агента пользователя и т. д. Чем больше доступных данных, даже включая содержимое конкретных файлов cookie, тем выше качество уникальности этого отпечатка пальца. Хотя, как уже говорили многие другие, протокол HTTP не делает его на 100% надежным - в лучшем случае это может быть лишь довольно хороший показатель.

Когда я использую устройство, которое никогда не посещало мой веб-сайт онлайн-банкинга, меня просят о дополнительной аутентификации. затем, если я возвращаюсь во второй раз на сайт онлайн-банкинга, меня не спрашивают о дополнительной аутентификации ... я удалил все куки-файлы в IE и перезагружен на мой сайт онлайн-банкинга, ожидая, что мне снова будут заданы вопросы аутентификации. к моему удивлению, меня не спросили. разве это не заставляет поверить, что банк делает какие-то компьютерные теги, которые не включают куки?

Это довольно распространенный тип аутентификации, используемый банками.

Допустим, вы заходите на сайт своего банка через example-isp.com. При первом посещении вас попросят ввести пароль и дополнительную аутентификацию. После того, как вы прошли, банк знает, что пользователь «thatisvaliant» аутентифицирован для доступа к сайту через example-isp.com.

В будущем он не будет запрашивать дополнительную аутентификацию (помимо вашего пароля), когда вы заходите на сайт через example-isp.com. Если вы попытаетесь получить доступ к банку через another-isp.com, банк снова выполнит ту же процедуру.

Таким образом, чтобы подвести итог, то, что банк идентифицирует, является вашим интернет-провайдером и / или сетевым блоком, на основе вашего IP-адреса. Очевидно, что не каждый пользователь вашего интернет-провайдера - это вы, поэтому банк по-прежнему запрашивает ваш пароль.

Вам когда-нибудь звонили в компанию, обслуживающую кредитную карту, чтобы убедиться, что все в порядке, когда вы используете кредитную карту в другой стране? Та же концепция.

На самом деле то, что вы хотите сделать, не может быть сделано, потому что протоколы не позволяют этого. Если бы статические IP-адреса использовались повсеместно, вы могли бы это сделать. Их нет, поэтому вы не можете.

Если вы действительно хотите идентифицировать людей , попросите их войти в систему.

Поскольку они, вероятно, будут перемещаться на разные страницы вашего веб-сайта, вам нужен способ отслеживать их по мере их перемещения.

Пока они вошли в систему и вы отслеживаете их сеанс на своем сайте с помощью файлов cookie / link-parameters / beacons / что угодно, вы можете быть уверены, что они используют один и тот же компьютер в течение этого времени.

В конечном счете, неверно говорить, что это говорит вам, какой компьютер они используют, если ваши пользователи не используют вашу локальную сеть и не имеют статических IP-адресов.

Если то, что вы хотите сделать, выполняется в сотрудничестве с пользователями, и для каждого файла cookie используется только один пользователь, и они используют один веб-браузер, просто используйте файл cookie.

Файлы cookie не будут полезны для определения уникальных посетителей. Пользователь может очистить куки и обновить сайт - он снова классифицируется как новый пользователь.

Я думаю, что лучший способ сделать это - реализовать решение на стороне сервера (так как вам нужно где-то хранить свои данные). В зависимости от сложности ваших потребностей в таких данных вам нужно будет определить, что классифицируется как уникальное посещение. Разумным способом было бы позволить IP-адресу вернуться на следующий день и получить уникальное посещение. Несколько посещений с одного IP-адреса за один день не следует считать уникальными.

Например, используя PHP, тривиально получить IP-адрес посетителя и сохранить его в текстовом файле (или в базе данных sql).

Решение на стороне сервера будет работать на всех машинах, потому что вы собираетесь отслеживать пользователя при первой загрузке вашего сайта. Не используйте javascript, так как он предназначен для скриптов на стороне клиента, плюс пользователь может отключить его в любом случае.

Надеюсь, это поможет.

Поскольку я хочу, чтобы решение работало на всех машинах и во всех браузерах (в пределах разумного), я пытаюсь создать решение с использованием JavaScript.

Разве это не очень хорошая причина не использовать JavaScript?

Как уже говорили другие - куки, вероятно, ваш лучший вариант - просто помните об ограничениях.

Вы можете использовать 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, так что даже если их отпечатки пальцев будут видоизменяться, вы все равно сможете отслеживать их

Я думаю, вердикт в том, что я не могу программно однозначно идентифицировать компьютер, который посещает мой веб-сайт.

У меня следующий вопрос. Когда я использую устройство, которое никогда не посещало мой веб-сайт онлайн-банкинга, меня просят о дополнительной аутентификации. затем, если я возвращаюсь во второй раз на сайт онлайн-банкинга, меня не спрашивают о дополнительной аутентификации. читая ответы на мой вопрос, я решил, что это должно быть печенье. поэтому я удалил все файлы cookie в IE и снова подключился к своему сайту онлайн-банкинга, ожидая, что мне снова будут заданы вопросы аутентификации. к моему удивлению, меня не спросили. разве это не заставляет поверить, что банк делает какие-то компьютерные теги, которые не включают куки?

Кроме того, после долгих поисков сегодня я нашел следующую компанию, которая утверждает, что продает решение, которое однозначно идентифицирует машины, которые посещают веб-сайт. http://www.the41.com/products.asp .

Я ценю всю полезную информацию, если бы вы могли уточнить эту противоречивую информацию, которую я нашел, я был бы очень признателен.

Я бы сделал это, используя комбинацию файлов cookie и flash-файлов cookie. Создайте GUID и сохраните его в файле cookie. Если файл cookie не существует, попробуйте прочитать его из файла cookie. Если он все еще не найден, создайте его и запишите в файл cookie cookie. Таким образом, вы можете использовать один и тот же GUID в разных браузерах.

Я думаю, что куки могут быть то, что вы ищете; именно так большинство сайтов однозначно идентифицируют посетителей.

Предполагая, что вы не хотите, чтобы пользователь контролировал, вы не можете. Сеть не работает таким образом, лучшее, на что вы можете надеяться, это некоторая эвристика.

Если есть возможность заставить вашего посетителя установить какое-либо программное обеспечение и использовать TCPA, вы можете что-то осуществить.

Мой пост может не быть решением, но я могу привести пример, где эта функция была реализована.

Если вы посетите страницу регистрации www.supertorrents.org с вашего компьютера, это нормально. Но если вы обновите страницу или откроете ее снова, это будет означать, что вы ранее посещали страницу. Настоящая красота приходит сюда - она ​​определяет, даже если вы переустановите Windows или другую ОС.

Я где-то читал, что они хранят идентификатор процессора. Хотя я не мог найти, как они это делают, я серьезно сомневаюсь в этом, и они могут использовать MAC-адрес для этого.

Я обязательно поделюсь, если найду, как это сделать.

Трюк:

1. Создать 2 страницы регистрации:

   Первая страница регистрации: без какой-либо электронной почты или проверки безопасности (только с именем пользователя и паролем)

   Вторая страница регистрации: с высоким уровнем безопасности (запрос подтверждения электронной почты, изображение безопасности и т. Д.)

2. Для удовлетворения клиентов и простой регистрации страница регистрации по умолчанию должна быть (Первая страница регистрации), но на (Первая страница регистрации) есть скрытое ограничение. Это ограничение IP. Если IP попытался зарегистрироваться во второй раз (например, менее 1 часа) вместо отображения страницы блокировки. Вы можете показать (Вторая страница регистрации) автоматически.

3. на (Первая страница регистрации) вы можете установить (например: блокировать 2 попытки с 1 ip всего за 1 час или 24 часа), а через (например) 1 час вы можете автоматически открыть доступ с этого ip

Обратите внимание: (Первая страница регистрации) и (Вторая страница регистрации) не должны быть на отдельных страницах. Вы делаете только 1 страницу. (например: register.php) и сделайте умным переключение между первым стилем PHP и вторым стилем PHP