指导的安全性是否可信,或者如果可以强制系统生成许多已知的指导,指导是否可预测?

发布于 2024-10-13 20:05:49 字数 608 浏览 4 评论 0原文

要开始并定义 guid,我使用 .net 框架 Guid 这有点假设的情况 用户在执行特定操作时会生成指南。每个用户都可以看到自己的指南。如果一个用户知道另一个用户的 guid,就会造成安全隐患。

如果我们假设一个用户无法窃取另一个用户的 guid 并且只能猜测它,那么这个系统有多安全?

我知道盲目猜测指南是不可能的。即使他们有一百万个成功值,他们仍然只有 10^20 成功猜测的机会,

我担心可能存在的问题是指导预测。用户是否可以生成大量请求,查看他获得的 guid,并了解 .net guid 生成公式,从而大大提高他猜测的几率? 这些可能性是否可以降低到引起安全问题的程度? 在这种情况下,应该如何以独特的不可猜测的方式生成密钥?

我要求任何提到猜测/碰撞概率的人为其添加一些硬性含义。要么是定义赔率的确切数字,要么是类似“它可以用于存储帐户数据,但不能用于存储敏感数据”

编辑

这个问题似乎很好地进入了我最初试图用这个问题探索的领域 GUID 是(临时)加密的好密钥吗?

To start, and define guid, i am using a .net framework Guid
This is somewhat a hypothetical situation
Users when preforming a specific action have guids generated. Each user can see their own guids. If a user was to know one of another user's guid there would be a security compromise.

How safe is this system if we asume that a user has no way to steal another user's guid and can only guess it?

I understand that blindly guessing guids is impossible. Even if they had a million success values, they would still have only a 10^20 chance of a successful guess

Where i am afraid a problem may exist is guid prediction. Can a user generate a large number of requests, look at the guids he got, and knowing the .net guid generation formula greatly improve his odds of guessing?
Can these odds be reduced to a point where they would be a security concern?
In that case how should keys be generated in a unique non guessable way?

I ask anyone who mentions the odds of guesses/collisions to add some hard meaning to it. Either an exact number to define odds, or something like, "it can be used to store account data, but not sensitive data"

EDIT

this question seems to go well into the territory I originally sought to explore with this question
Is a GUID a good key for (temporary) encryption?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

西瑶 2024-10-20 20:05:49

GUID/UUID 旨在生成 128 位数字,主要用作唯一的 ID(出于所有意图和目的)。

UUID 的设计目的不是生成加密的强随机数序列,如果您想要最大程度的不可预测性,那么加密的强随机数序列正是您想要的。为此,.NET 为您提供了 RNGCryptoServiceProvider - 从头开始​​设计,通过算法手段可以合理地实现不可预测性,那么为什么不使用它呢?

例子:

byte[] GenerateRandomBytes()
{
   byte[] key = new byte[16];

    System.Security.Cryptography.RNGCryptoServiceProvider c =
        new System.Security.Cryptography.RNGCryptoServiceProvider();

    c.GetBytes(key);

    return key;
}

GUID's/UUID's are intended to generate 128 bit numbers for use primarily as ID's that are unique (for all intents and purposes).

UUID's are not designed to generate cryptographically strong random number sequences, and if you want maximum un-predictability, then cryptographically strong random number sequences are exactly what you want. For this, .NET provides you with the RNGCryptoServiceProvider - designed from the ground up to be as unpredictable as can be reasonably achieved by algorithmic means, so why not use it?

Example:

byte[] GenerateRandomBytes()
{
   byte[] key = new byte[16];

    System.Security.Cryptography.RNGCryptoServiceProvider c =
        new System.Security.Cryptography.RNGCryptoServiceProvider();

    c.GetBytes(key);

    return key;
}
所有深爱都是秘密 2024-10-20 20:05:49

Afaik .net 默认生成 版本 4 UUID 作为 Guid。这些都是随机的,如果实施得当,很难猜测。但由于未来的版本可能会使用另一种实现,我不会依赖它。我认为即使是早期版本的 Windows 或 .net 也使用基于 Mac 地址的 Guid,这更容易猜测。

所以我只使用 .net 内置的加密伪随机数生成器之一。如果生成 16 个字节,则可以直接替换 Guid。

Afaik .net generates Version 4 UUIDs as Guids by default. These are random and hard to guess if properly implemented. But since future versions might use another implementation I wouldn't rely on that. I think even earlier versions of windows or .net used Guids based on the Mac-Address which are easier to guess.

So I'd just use one of the crypto-pseudo-random-number-generators built into .net instead. If you generate 16 bytes you have a drop-in replacement for a Guid.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文