2

我有一个 php/js 站点,其中信息被编码并放入数据库。信息的加密密钥是随机生成的,然后在用户通过表单发送帖子后返回给用户。加密密钥根本不存储在我的数据库中。一个单独的、随机生成的 ID 形成并存储在数据库中,用于在解密之前查找项目本身。

我的问题是,是否有可能查看日志并找到可以揭示密钥的信息?我试图使读取任何 SQL 数据成为不可能,而不是拥有代码的人(谁可以用它做任何他想做的事),或者通过暴力攻击(如果有人得到我的 SQL 数据库,这是不可避免的)?

只是为了重复我的步骤:

  1. 用户通过 POST 发送信息
  2. php 文件生成随机 ID 和访问密钥。数据使用访问密钥加密,然后以 ID 作为 PRIMARY KEY 放入 php 数据库。
  3. php 文件只回显随机 ID 和访问密钥。
  4. 网站使用 jQuery 从密钥和mysite.com?i=cYFogD3Se8RkLSE1CA [9 digit A-Ba-b09 = ID][9 digit A-Ba-b09 = key]创建链接

如果有人可以访问可以读取信息的我的服务器,是否有任何可能性?我希望它成为我自己阅读消息的信息。信息必须是可解码的,它不能是单向编码。

4

4 回答 4

2

让我们从一些基本定义开始:

代码通过将数据翻译成另一种语言(通常是私有语言)来保护数据。翻译成西班牙语的英语是编码的,但它不是很安全,因为很多人都懂西班牙语。

Cipher通过使用密钥对数据进行加扰来保护数据。Julius Caesar 首先记录的字母替换密码就是一个例子。现代技术涉及使用素数对二进制数据进行数学处理。最好的技术使用非对称密钥;用于加密数据的密钥无法解密,需要不同的密钥。这允许公开密钥并且是 SSL 浏览器通信的基础。

加密通过编码和/或加密数据来保护数据。

所有这些术语通常可以互换使用,但它们是不同的,而且这些差异有时很重要。您要做的是通过密码保护数据。

如果数据是“清晰的”,那么如果它被截获,它就会丢失。如果它被加密,那么数据和密钥都需要被截获。如果它被加密和编码,那么需要截取数据、密钥和代码。

您的数据在哪里易受攻击?

  1. 任何数据最容易受到攻击的地方是当它明确属于某人的个人财产、存储设备(USB、CD、一张纸)或在他们的头脑中时,因为该人很容易受到诱导或胁迫。这是 Wikileaks 的基础——信任信息的人被诱使背叛了这种信任——我把这个道德问题留给你个人的良心。
  2. 当它在客户端和服务器之间传输时,反之亦然。除了具有国家安全重要性的数据外,SSL 加密方法应该是足够的。
  3. 当它在程序的内存中时。程序的源代码是存储密钥的最佳位置,但是,它们本身需要使用您在每次程序运行时输入的密码(最好)加密存储,该密码是在您编译和发布时输入的,或者是嵌入到您的代码中(最差)。除非您有充分的理由,否则一把钥匙就足够了;不是每个用户一个。您还应该对内存中的数据进行加密,除非您确实需要它,并且您应该立即使用任何内存中的明文数据结构,并在完成后立即销毁它们。密钥必须存储在某个地方,否则数据将无法恢复。但是考虑一下,谁可以访问源代码(包括备份和替代版本)以及如何检查后门或木马?
  4. 当它在程序的机器和数据存储之间传输时。如果您只在程序和数据存储之间发送加密数据并且不将密钥存储在数据存储中,这应该没问题。
  5. 当它存储在数据存储中时。同上。

不要忽视物理安全,窃取数据的最简单方法通常是走到服务器并复制硬盘驱动器。许多公司(以及令人遗憾的国防/安全部队)花费数百万用于在线数据安全,然后将他们的数据放在一个没有锁的房间里。他们还有一个 10 岁的孩子可以绕过的访问协议。

您现在拥有了可爱的加密数据——您将如何阻止您的程序将其以明文形式提供给任何需要它的人?

这给我们带来了识别、验证和授权。更多定义:

识别一个人声称他们是某某。这通常由用户名在计算机程序中处理。在物理安全应用程序中,它是由一个人展示自己并说“我是某某”;这可以通过口头声明或出示护照等身份证件明确表示,也可以通过您认识的警卫默示承认您。

验证这是一个人是他们所说的人的证明。在计算机中,这是密码的作用;更准确地说,这证明他们知道他们所说的那个人的密码,这是整个事情中的大问题。在物理安全方面,它是通过将可信文件(如护照)中记录的物理指标(外观、身高等)与声明进行比较;您需要制定协议以确保您可以信任该文档。顺便说一句,这是面部识别技术在识别坏人时出现问题的主要原因——它使用验证技术来尝试识别某人。“这家伙看起来像坏家伙 #1”;你猜怎么着?70亿人口中的很多人也是如此。

授权一旦一个人被识别和验证,他们就会被授权做某些事情并去某些地方。为此,他们可能会获得临时身份证明文件;想想访客 ID 徽章或 cookie。根据他们去哪里,他们可能需要重新识别和重新验证自己;想想银行的网站;您识别并验证自己以查看您的银行帐户,然后再次进行转账或付款。

总的来说,这是任何计算机安全系统中最薄弱的部分。我要窃取你的数据很难,我要窃取你的身份并将数据提供给我要容易得多。

在你的情况下,这可能不是你关心的问题,只要你做了正常的事情,允许用户以正常的商业方式设置、更改和检索他们的密码,你可能已经做了所有你能做的。

请记住,数据安全性是一方面的安全性与另一方面的信任和可用性之间的权衡。把事情弄得太难(比如低价值数据的高复杂性密码),你会危及整个系统(因为人就是人,他们会把它们写下来)。

就像计算机中的一切一样——用户是个问题!

你为什么要保护这些数据,你愿意为此付出什么?

这是一个经典的风险管理问题。实际上,您需要考虑丢失此数据的不利后果、在您当前的保护措施下发生这种情况的风险以及降低额外保护措施所花费的风险是否值得。

丢失数据可能意味着以下任何或全部:

  1. 公之于众
  2. 如果落入错误的人之手
  3. 被恶意或意外破坏。(备份,人们!)
  4. 让它改变。如果您知道它已更改,则等于丢失它;如果你不这样做,这可能会更糟,因为你可能会根据虚假数据采取行动。

这种思维导致国防和政府中的数据分为绝密、机密、受限和非受限(澳大利亚分类)。人的因素在这里再次介入;由于官僚主义的性质,没有动机对文件进行低分类和大量抑制;所以文件经常被过度分类。这意味着,由于许多具有受限分类的文档需要分发给没有适当许可的人,只是为了使该死的东西工作,这就是发生的事情。

您也可以将其视为层次结构;我个人的想法是:

  1. 无论你在想什么级别,保卫领域妥协都会对我的国家/公司/家庭的战略生存产生严重的不利影响。
  2. 生死妥协会使某人的生命或健康处于危险之中。
  3. 财务妥协将使某人的钱/汽车/船/航天飞机被盗。
  4. 商业妥协将导致未来财务收益的损失。
  5. 羞辱性妥协会造成尴尬。当然,如果你是一名政治家,这可能是第一名。
  6. 个人这些是您宁愿不发布但不会特别惊天动地的细节。我会把我的个人病史放在这里,但是,违反隐私法的影响可能会将其推向羞辱(如果人们发现)或财务(如果你被起诉或起诉)。
  7. 私人这不是别人的事,但如果他们发现了,实际上并不会伤害你。
  8. 公开将其打印在纸上,以供任何人关心。

无论级别如何,您都不希望任何此类数据丢失或更改,但如果是,您需要知道这已经发生。对于纳粹来说,破解他们的 Enigma 密码是很糟糕的。不知道它已经发生是灾难性的。

在下面的评论中,我被要求描述最佳实践。如果不知道数据的风险(以及组织的风险承受能力),这是不可能的。在数据安全上花费过多与花费过少一样糟糕。

于 2013-01-11T03:44:06.630 回答
2

我喜欢包含解密密钥的 URL 系统,因此即使您没有仅在用户计算机上可用的数据,也无法访问。

我仍然看到一些问题。

  1. URL 通常保存在 Web 服务器日志中。如果你登录到磁盘,他们得到了磁盘,然后他们得到了密钥。

  2. 如果攻击者可以访问您的数据库,他可能对您的系统有足够的访问权限,可以秘密安装记录 URL 的软件。他甚至可以做一些平淡无奇的事情,比如重新登录。

  3. 访问您网站的人至少会将 URL 加入书签(否则对他来说毫无用处),并且它很可能会出现在他的浏览器历史记录中。通常,书签和历史记录不被视为安全数据。因此,对用户计算机的攻击者(通过直接坐下或计算机受到恶意软件的攻击)也可以访问数据。如果有效负载足够令人满意,那么有人可能会创建专门挖掘您的静态身份验证令牌的病毒或恶意软件,并且可以达到合理的命中率。这些 URL 可用于浏览器插件,甚至可用于以“立即导入您的书签”的看似合理的幌子运行的其他应用程序。

所以在我看来,最好的安全措施是让客户不仅拥有书签(虽然它是信息,但它不会保存在任何人的脑海中,因此可以被认为是“他拥有的东西”),而且对他来说也是也必须展示“他知道的东西”。所以也用他的密码加密,不要保存密码。当他提供 URL 时,要求输入密码,然后用两者(串行或组合)解密,数据是安全的。

最后,我知道第三方可以使用 Google 的双因素身份验证(例如,我将它与 Dropbox 一起使用)。这通过要求访问资源的人拥有他的手机或什么都没有,从而创建了另一个“你拥有的东西”。是的,如果您丢失了手机,有追索权,但它通常涉及另一个电话号码,或已打印出来并存放在钱包中的特殊 Google 提供的一次性长密码。

于 2013-01-11T04:06:37.747 回答
1

首先也是最重要的是,您需要一个非常好的、无懈可击的法律免责声明。

其次,根本不存储用户的数据。

相反,当用户提交数据(使用 SSL)时,生成 SessionID 和系统日期时间的哈希值。将此哈希与日期时间一起存储在您的表中并获取记录 ID。使用此哈希加密用户的数据,并生成一个带有记录 ID 和其中数据的 URL,并将其发送回用户(再次使用 SSL)。此 URL 的安全性现在是用户的问题,您不再有他们发送的任何记录(确保它没有被记录)。

通常,从数据库中删除过时的(4 小时、24 小时?)记录。

当检索请求进入时(使用 SSL)查找哈希,如果不存在,则告诉用户 URL 已过时。如果是,请解密他们发送的数据并将其发回(使用 SSL)并从数据库中删除记录。

于 2013-01-11T05:24:24.123 回答
0

让我们稍微想想

  1. 使用 SSL - 数据已加密
  2. 使用用户名/密码进行授权

如果有人打破了它 - 你确实有安全问题

花精力解决这个问题。在这种情况下,灾难恢复是浪费精力。只需正确设置基本案例即可。

于 2013-01-11T02:16:18.020 回答