代码之家  ›  专栏  ›  技术社区  ›  Scott Vander Molen

我应该隐藏主键值吗?

  •  16
  • Scott Vander Molen  · 技术社区  · 16 年前

    我开始怀疑我是否只是在妄想。可逆加密(base64)可能很容易被任何愿意尝试的人破坏,使URL非常难看,而且比其他方式更长。我是否应该放弃加密并以明文形式发送我的主密钥?

    10 回复  |  直到 16 年前
        1
  •  24
  •   cletus    16 年前

    你所做的基本上是混淆。可逆加密(base64实际上不算加密)主键仍然是主键。

    你所阅读的内容可以归结为:你通常不希望你的主键在系统之外有任何意义。这就是所谓的 技术主键 而不是 自然主键 自然主键 ).

    通常地 与自然主键相比更受欢迎,因为看起来不变的东西会发生变化,这可能会导致问题。甚至国家也可以存在和消失。

    如果您确实拥有技术主键,那么您不希望通过赋予它们本来没有的含义而使它们成为事实上的自然主键。我认为在URL中放置主键是可以的,但安全性是一个单独的主题。如果有人可以更改该URL并访问他们不应该访问的内容,那么这是一个安全问题,需要通过身份验证和授权来处理。

    有些人会争辩说,用户永远不应该看到它们。我觉得你没必要走那么远。

        2
  •  8
  •   John Wiseman    16 年前

    关于暴露主键的危险,您需要阅读“ autoincrement considered harmful “,作者:约书亚·沙赫特。

    包含标识符的URL将 让你失望的原因有三个。

    第一个是给定 一些物体,你可以找出 围绕着它。这暴露了 竞争对手或你可能认识的其他人 不希望获得此信息(如 通过查看序列号。)

    第二,在某个时刻某个混蛋会 获得编写shell脚本的想法 使用for循环并尝试获取每个 绝对没有乐趣。

    最后,对于用户来说,它 允许人们推导出某种类型的 劫持和/或黑客 高声望低数字ICQ ID。

        3
  •  4
  •   user111013 user111013    16 年前

    如果您担心有人更改URL以尝试查看其他值,那么您可能需要查看令牌生成。

    例如,不是给用户一个“SearchID”值,而是给他们一个SearchToken,这是一个长的、唯一的psuedo随机值(Read:GUID),然后在内部映射到SearchID。

    当然,您还需要应用会话安全性和soforth,因为即使是具有非顺序ID的唯一URL也无法防止服务器和用户之间的任何嗅探。

        4
  •  2
  •   Asaph    16 年前

        5
  •  2
  •   Patrick Mevzek James Dean    7 年前

    PostgreSQL为该问题提供了多种解决方案,可适用于其他RDBMs:

    • hashids : https://hashids.org/postgresql/

      Hashids是一个小型的开源库,它从数字生成简短、唯一、非顺序的id。 它将347这样的数字转换为yr8这样的字符串,或将[27986]这样的数字数组转换为3kTMd。 您还可以将这些ID解码回来。这对于将多个参数捆绑到一个参数中或将其作为短UID使用非常有用。

    • optimus 哈希德 但仅提供整数作为输出: https://github.com/jenssegers/optimus

    • skip32 https://wiki.postgresql.org/wiki/Skip32_(crypt_32_bits)

    • pseudo_encrypt() https://wiki.postgresql.org/wiki/Pseudo_encrypt :

      伪加密(int)可以用作唯一值的伪随机生成器。它生成一个与整数输入唯一关联的整数输出(通过数学排列),但同时看起来是随机的,没有冲突。这有助于传达顺序生成的数字,而不显示其在序列中的顺序位置(对于票号、URL缩写、促销代码…)

    • 本文详细介绍了Instagram是如何做到这一点的: https://instagram-engineering.com/sharding-ids-at-instagram-1cf5a71e5a5c

      通过使用PL/PGSQL、Postgres内部编程语言和Postgres现有的自动增量功能,我们已将ID创建委派给每个切分中的每个表。 我们的每个ID包括: 41位表示以毫秒为单位的时间(为我们提供了41年的ID和自定义纪元) 10位,表示一个自动递增的序列,模数1024。这意味着我们可以生成1024个ID,每个碎片,每毫秒

        6
  •  1
  •   Tor Valamo    16 年前

        7
  •  1
  •   leepowers    16 年前

    出于您的目的(构建搜索引擎),加密数据库主键的安全性折衷好处可以忽略不计。Base64编码不是加密——它通过隐蔽性实现了安全性,甚至不会对攻击者造成威胁。

        8
  •  1
  •   L̲̳o̲̳̳n̲̳̳g̲̳̳p̲̳o̲̳̳k̲̳̳e̲̳̳    16 年前

    当您在URL中看到base64时,您几乎可以肯定该站点的开发人员不知道他们在做什么,并且该站点易受攻击。

        9
  •  0
  •   Mr. TA    16 年前

    包含标识符的URL将

    错,错,错。

    首先,必须验证每个请求,不管它是以带有id的HTTP GET、POST或web服务调用的形式出现。

    第二,一个制作得当的网站需要防范依赖于IP地址跟踪和请求频率分析的僵尸程序;隐藏ID可能会阻止某些人编写shell脚本来获取一系列对象,但也有其他方法可以通过使用某种暴力攻击来利用网站。

    第三,ICQ ID很有价值,但这仅仅是因为它们与用户相关,是用户的主要身份识别手段;这是一种独一无二的用户身份验证方法,不被任何其他服务、程序或网站使用。

    总之。。是的,您需要担心刮刀、DDOS攻击、数据保护和一大堆其他问题,但隐藏ID并不能正确解决所有这些问题。

        10
  •  0
  •   Casey Crookston    8 年前

    推荐文章