如何让用户从唯一一台机器（通过获取CPU串口）登录到ASP.NET-MVC web应用程序
How to enable user log in from the only one machine(by acquiring CPU Serial) to the ASP.NET-MVC web application
场景：
我已经部署了 Web ASP.NET-MVC 5 应用程序，具有个人用户帐户：身份 2.x。每个用户都有一个电子邮件和密码可以通过浏览器登录网络应用程序，这意味着用户可以通过任何带有互联网浏览器的设备登录。
我想启用用户登录条件，即他每次登录时都使用完全相同的 PC class 机器。
如有必要，我可以礼貌地要求用户使用 运行 任何 桌面 .NET(.exe) 应用程序。如果插件是实现此目的所必需的，我也可以要求用户使用 Chrome 浏览器。从字面上看，我可以假设任何事情。解决方案可能会很不舒服，没关系。
我的半解：
通过桌面应用程序获取CPU序列号（我们称它为Authorizer.exe）应用程序，它将在登录时将此唯一ID发送到ASP.NET-MVC Web应用程序进入它以授权该用户使用某些PC。 Authorizer.exe 将通过嗅探通过网络的数据包来检测登录到 Web 应用程序。
加
检测用户的位置，这会限制他移动他的计算机。
创建桌面应用程序，该应用程序只能使用 Web 应用程序提供的唯一序列号激活一次。只有打开此桌面应用程序才能登录 ASP.NET-MVC。（我不知道该怎么做）。
为什么要问这个问题：
如果有人窃取了用户的电子邮件和密码，我不想让小偷能够登录但对我来说最重要的是我不想让用户从不同的设备登录。
您的解决方案非常困难，需要大量工作。我建议你做一些更简单的事情。
首先，您向用户数据库添加一个二进制字段'FirstTime'，并默认使用'true' 初始化它。
当用户第一次登录时，你给他一个cookie（为了更好的安全我会加密它）并将用户记录中的字段更改为'false'。当用户再次登录时，您会检查此 cookie，如果 cookie 不存在，则不允许他登录。因此，你让每个用户从任何地方登录一次，然后他或她只能从同一个浏览器和同一台机器登录。
见如下伪代码：
Login (Email, Password)
{
if (FirstTime)
{
DoLogin();
SetCookie();
FirstTime = false;
}
else
{
if (GetCookie())
DoLogin();
else
ConfirmError();
}
}
此解决方案的唯一弱点是理论上用户可能会尝试将 cookie 复制到另一台机器。但是，它要求您的用户成为非常优秀的黑客，而根据您的描述，我认为他们不是。
更新：
我对你的问题考虑了很多，我会尝试向你建议一个改进的解决方案，它仍然很容易实施，不需要几周的努力，不需要花很多钱，也不会强迫客户去完成复杂的操作。
想法是结合多种客户端检测方法，虽然传递每一种方法可能并不难，但将所有方法一起传递确实是个问题。
所以，你可以做三件事：
- 设置加密cookie。即使复制不是什么大问题，它也是潜在 'hacker' 不应忘记的一项操作。
- 在浏览器本地存储中复制它。同样，欺骗是可能的，但没有人说骗子需要这样做。
- 使用浏览器指纹技术。有关它的更多信息，请阅读 here and here。至少您可以检查用户代理、HTTP Headers、屏幕尺寸和颜色深度以及浏览器插件详细信息。即使在同一个组织内部，两个浏览器的指纹足够接近的可能性也很低。
您可以将每个用户存储在数据库中的所有这些信息以及这些因素的组合将提供可靠的决策基础。例如，如果某人有一个 cookie，但 Local Storage 记录丢失了，很明显该 cookie 被复制了。禁止访问并删除 cookie。让我们想象一下作弊者回到原来的电脑，找到了一个 Local Storage 记录，也复制了它并尝试再次连接……但是这里已经没有 cookie 了！并且不要忘记更难制造的浏览器指纹。如果你限制在一定时间内连接失败的次数，那么你的保护就很难被破解了。
检查任何硬件信息，例如 CPU Id 无法使用 javascript，因为它不能 运行 离开浏览器的沙箱。不过用 c# 做是可能的：
public static string GetCpuId()
{
var mbs = new ManagementObjectSearcher("select ProcessorId from Win32_processor");
var mbsList = mbs.Get();
var cpuId = "";
foreach (var mo in mbsList)
{
cpuId = mo["ProcessorId"].ToString();
break;
}
return cpuId;
}
但是里面没有任何意义。
假设用户尝试使用电子邮件和密码登录。有人在嗅探流量并窃取用户的凭据。所以他想登录您的网络应用程序，但意识到这是不可能的，因为他还需要 CpuId。你真的认为把它连同密码一起窃取然后做一个假的登录请求来获取 cookie 很难吗？不，这不对。
让桌面授权应用程序更糟糕，因为任何 10 年的黑客都会在几秒钟内破解授权工具。
恕我直言，好的方法是实现某种 3D-secure，例如:
- 用户在登录页面上输入他的凭据
- 应用程序将带有一些密码的短信发送到用户的手机
phone
- 用户输入密码
- 盈利！
您还需要对所有安全敏感流量使用 HTTPS。
如果您不想让用户使用来自任何其他设备的应用程序 - 那么您需要在服务器端实现一些 api，桌面应用程序（客户端）可以使用) 集成硬件许可
CPU 序列号解决方案不实用，因为其他人也提到它不在客户端脚本的方法中。
然而，我想到的有关桌面应用程序的想法是，一旦应用程序通过网络下载并激活，该应用程序就必须保留唯一的序列号。此桌面应用程序将每隔（假设）30 分钟后 ping 您的 web api/ web 服务，并会告诉您安装它的计算机的 IP 地址以及唯一序列号并将其保存在数据库中.当登录请求到达您的 Web 应用程序时，您将检查该请求来自哪个 IP 地址，以及它是否与桌面应用程序调用提供的 IP 地址相同。
另一个想法，但有一个小漏洞：
如果您的用户可以允许 ActiveX 控件，则必须执行以下操作：
<script type="text/javascript">
var cpu_id = "";
var get_cpuid = GetObject("winmgmts:{impersonationLevel=impersonate}");
e = new Enumerator(get_cpuid.InstancesOf("Win32_Processor"));
for(; !e.atEnd(); e.moveNext()) {
var s = e.item();
cpu_id = s.ProcessorID;
}
</script>
你可以像这样使用它：
<b>Client CPU-ID : </b><span id="show_cpu_id" />
<script type="text/javascript">
document.getElementById("show_cpu_id").innerHTML = cpu_id;
</script>
但因为它在客户端，所以用户仍然可以操纵该值和 post 一些不同的值。
这是一道难题。我想到的解决方案很少：
- 在客户端使用ActiveX将客户端设备的MAC地址传递给服务器并使用它进行身份验证。这是相当可靠的，因为 MAC 是静态分配给网络接口卡的。
- 另一种选择是在客户端机器上安装某种证书并在登录时传递它。类似于 SSH 密钥身份验证的方式。然而，这要求用户不能在机器之间移动密钥。
我能想到的唯一解决方案是颁发客户端证书，并在您的应用程序中使用证书身份验证。
管理证书
要管理证书，您需要实施 PKI，这需要：
- 获取颁发证书所需的证书颁发机构（它可以是 public CA，也可以使用自签名证书）
- 使用 CA 为您的 Web 服务器颁发证书
- 将您的应用配置为通过 HTTPS 运行，并需要证书身份验证
- 为您的用户颁发证书，并将它们安装在他们的浏览器中
确保用户无法将证书移动到其他机器
弱者link排在最后。您必须注意如何安装以及如何颁发证书。
正在用户浏览器上安装证书
在浏览器中安装证书。您可以：
- 创建证书文件，用于在浏览器中导入证书
- 使用允许通过使用浏览器访问页面来请求证书的 PKI 基础结构（证书服务器），并且需要使用相同的浏览器在其中安装证书，一旦颁发（即其请求是公认）。
注意：在这两种情况下，您都必须接受请求并颁发证书或拒绝它。证书不会自动颁发
第一个选项有一个问题：如果您将证书发送给您的用户，他将能够在任何机器上安装它，安装次数不限。要解决这个问题，您需要访问您用户的计算机，复制文件，安装它，然后删除它。第二个选项解决了这个问题。
第二种选择更安全。但是知识渊博的用户仍然可以在这个过程中恢复服务器下发的文件，并在不同的地方安装证书。
使私钥不可导出
要考虑的另一个非常重要的一点是，当您颁发证书时，通常会有一个选项允许导出其私钥。如果设置此选项，用户可以从安装它的浏览器中导出 PK，并将其安装在其他地方。显然你想避免这种情况。所以，禁用这个选项。
使用此选项，用户仍然可以导出证书，但没有私钥，因此无法安装到其他地方。
设置 PKI
我不提供有关如何设置 PKI 的更多详细信息，因为它在很大程度上取决于基础架构（OS 和版本）。如果您想了解更多关于证书和 PKI 的信息 wikipedia entry for "X.509" and wikipedia entry for PKI。然后您可以查找有关在特定基础架构中设置 PKI 的其他信息 (OS)。
此系统的安全性
你可以放心，这个系统真的很安全：例如，在我的国家，你可以通过这种方式证明自己的身份，从而做出很多"official"事情，比如申报和纳税。
吊销证书
而且，如果您想知道如果您想要拒绝访问已经拥有证书的用户会发生什么。答案是您可以随时撤销证书，这样服务器将不允许您的用户使用他的证书进行身份验证，因为它已被撤销。
用户和机器安全
另一件让您担心的事情是其他用户使用同一台机器登录您的应用程序。由于以下原因，它比看起来更难：
- 只有当您使用安装它的同一用户登录到他的计算机时，该证书才可用
- 安装证书时，您可以OS在有人要使用证书时请求密码
- 你可以让你的应用拥有双重授权：
- 首先是证书授权（这个其实是IIS自己处理的）
- 其次，询问用户名和密码（或使用证书的用户名，并询问与用户关联的附加密码）
编辑：肮脏的解决方案，以及所有解决方案中的王后 evercookie，它将数据存储在 12 个不同的可想到和不可想象的地方
我见过很多建议使用 "magic way" 来识别用户机器的答案，而他不知道并接受它，或者可能会被某些用户操作破坏。这些解决方案不稳定，甚至可能不合法。此外，none 的解释解决方案是可靠的或易于实施的，但我会在回答结束时向您提供的解决方案。但在此之前，请允许我解释一下为什么我更喜欢证书解决方案。
安装已颁发的证书不会对用户隐藏，除非用户故意删除证书，否则无法破解。可以通知用户他需要证书才能访问应用程序，因此您既没有作弊，也没有使用 "magic" 来识别他的机器。这是一个干净的、受支持的、有文档记录的解决方案。而且证书不能被破解和破解（严格意义上说，任何东西都可以破解或破解，但这太难破解了）。除此之外，同一个证书可以被所有浏览器共享，因为它不是安装在浏览器中，而是安装在机器的证书库中。因此，即使用户使用不同的浏览器打开应用程序，证书仍会存在。而且很容易检查验证问题是否是缺少证书（或与之相关的东西）。
但是，如果您仍然希望实施无需用户批准或不解释其工作原理即可识别用户机器的解决方案，则可以使用 "supercookies"。如果你 google 喜欢这个，你会在很多地方发现它利用了闪存。甚至闪存 + HTML5 存储。或者它甚至可以使用许多其他地方来存储所需的信息。但是您会发现这种技术不受欢迎。并且可以反低而使你惹上麻烦。然而，话虽如此，如果你还想做这种 "dirty" 的事情，你可以使用 evercookie。它在JavaScript中实现，你可以从这个link:
看到信息和下载代码
免责声明：如果你用这个邪物惹出什么事，别怪我！我告诉你了！
没有任何浏览器可以让您在没有某种插件的情况下获得 CPU 序列号。此外，您获取该信息的方式也会因操作系统而异。因此，您将不得不在客户端计算机上向 运行 编写应用程序代码。鉴于您正在失去使用 Web 浏览器访问您的应用程序的大部分优势。
您可以编写一个简单的桌面应用程序，使用类似 Awesomium 的东西在其中嵌入渲染引擎。然后你可以编写任何你喜欢的安全性并将所需的令牌直接嵌入为 http headers.
几年前我在编写呼叫中心应用程序时做了类似的事情，因为它允许我发明一个新的 URL 方案允许我控制操作员 phone.
执行此操作的方法很少，
使用 Ever Cookies (https://github.com/samyk/evercookie)
优点：
这也是一个很靠谱的鉴别方法
缺点：
如果用户重新安装 OS / 或者用户清除所有存储信息的地方，这将不起作用
从浏览器执行 ActiveX 控件来获取 CPU ID，这将是非常准确的
优势
这是一种非常可靠的鉴定方法
缺点
每次用户登录都会提示执行ActiveX
除 IE 之外的许多浏览器需要更改配置/可能无法正常工作
如果用户更改 PC 的 CPU 这将不起作用
使用 flash cookies
优势
这也是一个很靠谱的鉴别方法
缺点
用户需要安装flash播放器
如果用户重新安装 OS
，这将不起作用
如果用户清除 flash cookie，这将不起作用
您可以充当证书颁发者，为每台机器颁发证书并将其与用户登录相关联。用户甚至可以签名。
Apple 使用此过程使任何 Mac 成为 iOS/Mac 开发人员。您必须从您的计算机创建请求并将其发送到会员中心，将为您的计算机创建一个仅使用 private/public 密钥方案（加密）的证书。
这与您想要的相似。为了保证用户不会获取证书或将其安装到另一台机器上，您可以创建一个程序来生成随机密钥并将其保存到计算机中。证书是使用该密钥创建的。如果用户尝试更改密钥，服务器会说此密钥未用于生成此特定证书，最后，无法更改证书，因为它是由只有服务器知道的私钥生成的。
场景：
我已经部署了 Web ASP.NET-MVC 5 应用程序，具有个人用户帐户：身份 2.x。每个用户都有一个电子邮件和密码可以通过浏览器登录网络应用程序，这意味着用户可以通过任何带有互联网浏览器的设备登录。
我想启用用户登录条件，即他每次登录时都使用完全相同的 PC class 机器。
如有必要，我可以礼貌地要求用户使用 运行 任何 桌面 .NET(.exe) 应用程序。如果插件是实现此目的所必需的，我也可以要求用户使用 Chrome 浏览器。从字面上看，我可以假设任何事情。解决方案可能会很不舒服，没关系。
我的半解：
通过桌面应用程序获取CPU序列号（我们称它为Authorizer.exe）应用程序，它将在登录时将此唯一ID发送到ASP.NET-MVC Web应用程序进入它以授权该用户使用某些PC。 Authorizer.exe 将通过嗅探通过网络的数据包来检测登录到 Web 应用程序。 加 检测用户的位置，这会限制他移动他的计算机。
创建桌面应用程序，该应用程序只能使用 Web 应用程序提供的唯一序列号激活一次。只有打开此桌面应用程序才能登录 ASP.NET-MVC。（我不知道该怎么做）。
为什么要问这个问题：
如果有人窃取了用户的电子邮件和密码，我不想让小偷能够登录但对我来说最重要的是我不想让用户从不同的设备登录。
您的解决方案非常困难，需要大量工作。我建议你做一些更简单的事情。
首先，您向用户数据库添加一个二进制字段'FirstTime'，并默认使用'true' 初始化它。 当用户第一次登录时，你给他一个cookie（为了更好的安全我会加密它）并将用户记录中的字段更改为'false'。当用户再次登录时，您会检查此 cookie，如果 cookie 不存在，则不允许他登录。因此，你让每个用户从任何地方登录一次，然后他或她只能从同一个浏览器和同一台机器登录。
见如下伪代码：
Login (Email, Password)
{
if (FirstTime)
{
DoLogin();
SetCookie();
FirstTime = false;
}
else
{
if (GetCookie())
DoLogin();
else
ConfirmError();
}
}
此解决方案的唯一弱点是理论上用户可能会尝试将 cookie 复制到另一台机器。但是，它要求您的用户成为非常优秀的黑客，而根据您的描述，我认为他们不是。
更新：
我对你的问题考虑了很多，我会尝试向你建议一个改进的解决方案，它仍然很容易实施，不需要几周的努力，不需要花很多钱，也不会强迫客户去完成复杂的操作。
想法是结合多种客户端检测方法，虽然传递每一种方法可能并不难，但将所有方法一起传递确实是个问题。
所以，你可以做三件事：
- 设置加密cookie。即使复制不是什么大问题，它也是潜在 'hacker' 不应忘记的一项操作。
- 在浏览器本地存储中复制它。同样，欺骗是可能的，但没有人说骗子需要这样做。
- 使用浏览器指纹技术。有关它的更多信息，请阅读 here and here。至少您可以检查用户代理、HTTP Headers、屏幕尺寸和颜色深度以及浏览器插件详细信息。即使在同一个组织内部，两个浏览器的指纹足够接近的可能性也很低。
您可以将每个用户存储在数据库中的所有这些信息以及这些因素的组合将提供可靠的决策基础。例如，如果某人有一个 cookie，但 Local Storage 记录丢失了，很明显该 cookie 被复制了。禁止访问并删除 cookie。让我们想象一下作弊者回到原来的电脑，找到了一个 Local Storage 记录，也复制了它并尝试再次连接……但是这里已经没有 cookie 了！并且不要忘记更难制造的浏览器指纹。如果你限制在一定时间内连接失败的次数，那么你的保护就很难被破解了。
检查任何硬件信息，例如 CPU Id 无法使用 javascript，因为它不能 运行 离开浏览器的沙箱。不过用 c# 做是可能的：
public static string GetCpuId()
{
var mbs = new ManagementObjectSearcher("select ProcessorId from Win32_processor");
var mbsList = mbs.Get();
var cpuId = "";
foreach (var mo in mbsList)
{
cpuId = mo["ProcessorId"].ToString();
break;
}
return cpuId;
}
但是里面没有任何意义。
假设用户尝试使用电子邮件和密码登录。有人在嗅探流量并窃取用户的凭据。所以他想登录您的网络应用程序，但意识到这是不可能的，因为他还需要 CpuId。你真的认为把它连同密码一起窃取然后做一个假的登录请求来获取 cookie 很难吗？不，这不对。
让桌面授权应用程序更糟糕，因为任何 10 年的黑客都会在几秒钟内破解授权工具。
恕我直言，好的方法是实现某种 3D-secure，例如:
- 用户在登录页面上输入他的凭据
- 应用程序将带有一些密码的短信发送到用户的手机 phone
- 用户输入密码
- 盈利！
您还需要对所有安全敏感流量使用 HTTPS。
如果您不想让用户使用来自任何其他设备的应用程序 - 那么您需要在服务器端实现一些 api，桌面应用程序（客户端）可以使用) 集成硬件许可
CPU 序列号解决方案不实用，因为其他人也提到它不在客户端脚本的方法中。
然而，我想到的有关桌面应用程序的想法是，一旦应用程序通过网络下载并激活，该应用程序就必须保留唯一的序列号。此桌面应用程序将每隔（假设）30 分钟后 ping 您的 web api/ web 服务，并会告诉您安装它的计算机的 IP 地址以及唯一序列号并将其保存在数据库中.当登录请求到达您的 Web 应用程序时，您将检查该请求来自哪个 IP 地址，以及它是否与桌面应用程序调用提供的 IP 地址相同。
另一个想法，但有一个小漏洞： 如果您的用户可以允许 ActiveX 控件，则必须执行以下操作：
<script type="text/javascript">
var cpu_id = "";
var get_cpuid = GetObject("winmgmts:{impersonationLevel=impersonate}");
e = new Enumerator(get_cpuid.InstancesOf("Win32_Processor"));
for(; !e.atEnd(); e.moveNext()) {
var s = e.item();
cpu_id = s.ProcessorID;
}
</script>
你可以像这样使用它：
<b>Client CPU-ID : </b><span id="show_cpu_id" />
<script type="text/javascript">
document.getElementById("show_cpu_id").innerHTML = cpu_id;
</script>
但因为它在客户端，所以用户仍然可以操纵该值和 post 一些不同的值。
这是一道难题。我想到的解决方案很少：
- 在客户端使用ActiveX将客户端设备的MAC地址传递给服务器并使用它进行身份验证。这是相当可靠的，因为 MAC 是静态分配给网络接口卡的。
- 另一种选择是在客户端机器上安装某种证书并在登录时传递它。类似于 SSH 密钥身份验证的方式。然而，这要求用户不能在机器之间移动密钥。
我能想到的唯一解决方案是颁发客户端证书，并在您的应用程序中使用证书身份验证。
管理证书
要管理证书，您需要实施 PKI，这需要：
- 获取颁发证书所需的证书颁发机构（它可以是 public CA，也可以使用自签名证书）
- 使用 CA 为您的 Web 服务器颁发证书
- 将您的应用配置为通过 HTTPS 运行，并需要证书身份验证
- 为您的用户颁发证书，并将它们安装在他们的浏览器中
确保用户无法将证书移动到其他机器
弱者link排在最后。您必须注意如何安装以及如何颁发证书。
正在用户浏览器上安装证书
在浏览器中安装证书。您可以：
- 创建证书文件，用于在浏览器中导入证书
- 使用允许通过使用浏览器访问页面来请求证书的 PKI 基础结构（证书服务器），并且需要使用相同的浏览器在其中安装证书，一旦颁发（即其请求是公认）。
注意：在这两种情况下，您都必须接受请求并颁发证书或拒绝它。证书不会自动颁发
第一个选项有一个问题：如果您将证书发送给您的用户，他将能够在任何机器上安装它，安装次数不限。要解决这个问题，您需要访问您用户的计算机，复制文件，安装它，然后删除它。第二个选项解决了这个问题。
第二种选择更安全。但是知识渊博的用户仍然可以在这个过程中恢复服务器下发的文件，并在不同的地方安装证书。
使私钥不可导出
要考虑的另一个非常重要的一点是，当您颁发证书时，通常会有一个选项允许导出其私钥。如果设置此选项，用户可以从安装它的浏览器中导出 PK，并将其安装在其他地方。显然你想避免这种情况。所以，禁用这个选项。
使用此选项，用户仍然可以导出证书，但没有私钥，因此无法安装到其他地方。
设置 PKI
我不提供有关如何设置 PKI 的更多详细信息，因为它在很大程度上取决于基础架构（OS 和版本）。如果您想了解更多关于证书和 PKI 的信息 wikipedia entry for "X.509" and wikipedia entry for PKI。然后您可以查找有关在特定基础架构中设置 PKI 的其他信息 (OS)。
此系统的安全性
你可以放心，这个系统真的很安全：例如，在我的国家，你可以通过这种方式证明自己的身份，从而做出很多"official"事情，比如申报和纳税。
吊销证书
而且，如果您想知道如果您想要拒绝访问已经拥有证书的用户会发生什么。答案是您可以随时撤销证书，这样服务器将不允许您的用户使用他的证书进行身份验证，因为它已被撤销。
用户和机器安全
另一件让您担心的事情是其他用户使用同一台机器登录您的应用程序。由于以下原因，它比看起来更难：
- 只有当您使用安装它的同一用户登录到他的计算机时，该证书才可用
- 安装证书时，您可以OS在有人要使用证书时请求密码
- 你可以让你的应用拥有双重授权：
- 首先是证书授权（这个其实是IIS自己处理的）
- 其次，询问用户名和密码（或使用证书的用户名，并询问与用户关联的附加密码）
编辑：肮脏的解决方案，以及所有解决方案中的王后 evercookie，它将数据存储在 12 个不同的可想到和不可想象的地方
我见过很多建议使用 "magic way" 来识别用户机器的答案，而他不知道并接受它，或者可能会被某些用户操作破坏。这些解决方案不稳定，甚至可能不合法。此外，none 的解释解决方案是可靠的或易于实施的，但我会在回答结束时向您提供的解决方案。但在此之前，请允许我解释一下为什么我更喜欢证书解决方案。
安装已颁发的证书不会对用户隐藏，除非用户故意删除证书，否则无法破解。可以通知用户他需要证书才能访问应用程序，因此您既没有作弊，也没有使用 "magic" 来识别他的机器。这是一个干净的、受支持的、有文档记录的解决方案。而且证书不能被破解和破解（严格意义上说，任何东西都可以破解或破解，但这太难破解了）。除此之外，同一个证书可以被所有浏览器共享，因为它不是安装在浏览器中，而是安装在机器的证书库中。因此，即使用户使用不同的浏览器打开应用程序，证书仍会存在。而且很容易检查验证问题是否是缺少证书（或与之相关的东西）。
但是，如果您仍然希望实施无需用户批准或不解释其工作原理即可识别用户机器的解决方案，则可以使用 "supercookies"。如果你 google 喜欢这个，你会在很多地方发现它利用了闪存。甚至闪存 + HTML5 存储。或者它甚至可以使用许多其他地方来存储所需的信息。但是您会发现这种技术不受欢迎。并且可以反低而使你惹上麻烦。然而，话虽如此，如果你还想做这种 "dirty" 的事情，你可以使用 evercookie。它在JavaScript中实现，你可以从这个link:
看到信息和下载代码免责声明：如果你用这个邪物惹出什么事，别怪我！我告诉你了！
没有任何浏览器可以让您在没有某种插件的情况下获得 CPU 序列号。此外，您获取该信息的方式也会因操作系统而异。因此，您将不得不在客户端计算机上向 运行 编写应用程序代码。鉴于您正在失去使用 Web 浏览器访问您的应用程序的大部分优势。
您可以编写一个简单的桌面应用程序，使用类似 Awesomium 的东西在其中嵌入渲染引擎。然后你可以编写任何你喜欢的安全性并将所需的令牌直接嵌入为 http headers.
几年前我在编写呼叫中心应用程序时做了类似的事情，因为它允许我发明一个新的 URL 方案允许我控制操作员 phone.
执行此操作的方法很少，
使用 Ever Cookies (https://github.com/samyk/evercookie)
优点：
这也是一个很靠谱的鉴别方法
缺点：
如果用户重新安装 OS / 或者用户清除所有存储信息的地方，这将不起作用
从浏览器执行 ActiveX 控件来获取 CPU ID，这将是非常准确的
优势
这是一种非常可靠的鉴定方法
缺点
每次用户登录都会提示执行ActiveX
除 IE 之外的许多浏览器需要更改配置/可能无法正常工作
如果用户更改 PC 的 CPU 这将不起作用
使用 flash cookies
优势
这也是一个很靠谱的鉴别方法
缺点
用户需要安装flash播放器
如果用户重新安装 OS
，这将不起作用如果用户清除 flash cookie，这将不起作用
您可以充当证书颁发者，为每台机器颁发证书并将其与用户登录相关联。用户甚至可以签名。
Apple 使用此过程使任何 Mac 成为 iOS/Mac 开发人员。您必须从您的计算机创建请求并将其发送到会员中心，将为您的计算机创建一个仅使用 private/public 密钥方案（加密）的证书。
这与您想要的相似。为了保证用户不会获取证书或将其安装到另一台机器上，您可以创建一个程序来生成随机密钥并将其保存到计算机中。证书是使用该密钥创建的。如果用户尝试更改密钥，服务器会说此密钥未用于生成此特定证书，最后，无法更改证书，因为它是由只有服务器知道的私钥生成的。