哈希与数字身份证

时间:2008-10-13 04:38:47

标签: hash web-applications

在创建一个Web应用程序时,某些如何显示重复实体(YouTube上的视频,或像我的网站上的书籍部分)的唯一标识符的显示,是否更好地使用像哈希一样的统一长度标识符或数据库中项目的唯一键(1,2,3等)。

除了揭示一点,我认为是非物质的,关于你的应用程序内部的信息,为什么使用哈希比仅使用唯一ID更好?

简而言之:哪个最好用作公开显示的唯一标识符 - 哈希值或数据库中的唯一键?

编辑:我再次打开这个问题,因为Dmitriy提出了不要将命名绑定到db特定属性的好处。这种束缚会阻止我将来优化​​/规范化数据库吗?

平台使用php / python和ISAM / w MySQL。

8 个答案:

答案 0 :(得分:5)

除非你试图隐藏你的内部对象ID计数器的状态,否则哈希不必要地慢(生成和比较),不必要的长,不必要的丑陋和不必要的冲突。 GUID也很长而且丑陋,使它们像哈希一样不适合人类消费。

对于类似库存的东西,只需使用顺序(或分片)计数器。如果迁移到其他数据库,则只需将新计数器初始化为至少与最大现有记录ID一样大的值。几乎每个数据库服务器都为您提供了一种方法。

如果 试图隐藏您的计数器状态,可能是因为您计算用户并且不希望竞争对手知道您拥有多少,我建议您避免显示您的内部标识。如果您坚持要显示它们并且不想要哈希的缺点,您可以考虑使用最大周期linear feedback shift register来生成ID。

答案 1 :(得分:2)

如果我不希望用户能够猜测系列中的下一个ID,我通常会使用哈希值。但是对于你的书籍部分,我会坚持使用数字ID。

答案 2 :(得分:2)

例如,如果由于某种原因需要重建数据库,并且排序更改,则最好使用哈希。序数会四处移动 - 但是哈希值会保持不变。

不依赖于你把东西放入盒子的顺序,但是对于物品的属性,似乎......更安全。

但显然要注意碰撞。

答案 3 :(得分:1)

用哈希

  1. 如果需要,可以自由地将数据库与类似的数据库(或备份)合并
  2. 没有做一些可以帮助猜测攻击的事情
  3. 不披露有关用户的更多私人信息,例如如果有人在您当前的数据库登录中看到用户编号为2,他们就会收到他是老人的信息。
  4. (假设您使用长哈希或GUID),如果您被YouTube收购并且他们决定整合您的数据库,则会大大帮助您。
  5. 如果出现按GUID索引的搜索引擎,请自行帮助。
  6. 如果过去6个月让您对此问题有所了解,请告知我们......

答案 4 :(得分:0)

不保证哈希是唯一的,我相信也不一致。

答案 5 :(得分:0)

您的用户是否必须记住/使用该值?或者你是从安全POV看它吗?

从安全角度来看,这应该不重要 - 因为你不应该只依赖于那些不会猜测他们不应该看到的不同但有效的ID的人来阻止他们。

答案 6 :(得分:0)

是的,我不认为你正在寻找哈希 - 你更有可能寻找一个Guid。如果你在.Net平台上,请尝试使用System.Guid。

但是,不使用Guid的最重要原因是性能。在(长)字符串上执行数据库连接和查找非常不理想。数字很​​快。所以,除非你真的需要它,否则不要这样做。

答案 7 :(得分:0)

哈希的优点是,您可以检查它们是否有效,然后再对数据库执行任何检查,无论它们是否存在。这可以帮助您抵御随机哈希攻击,因为您不需要使用虚假查找来增加数据库的负担。

因此,如果您的哈希值具有某种明确定义的格式,例如最后的校验和,您可以检查它是否正确而无需转到数据库。