【问题标题】:Choosing a secret选择一个秘密
【发布时间】:2016-01-19 06:08:15
【问题描述】:

我目前正在研究我可以做些什么来保护我发送给我的客户的 cookie 数据。事实证明,这一切都归结为签署我的 cookie - 没什么大不了的,对吧?

嗯,实际上,这只是部分正确。我一直在决定使用什么秘密。你看,我的应用是开源的,我不会突然关闭开源代码。所以我需要一种机制,让我可以保守秘密,并确保阅读我的代码的最终用户不会立即突破。因为,只要你修修补补足够长的时间,任何东西都是可以破解的——这就是我的看法。

反正我跑题了。

我正在使用 PHP 和 NodeJS。挑选一个永远保密的秘密的最佳方法是什么?

我最初的想法: - 我的服务器的私钥 - 一个随机字符串,放入世界访问之外的文本文件中

我的应用目前运行 Yii1,但我正在切换到 laravel 5。

【问题讨论】:

  • 只在安装时随机生成一个,并将其存储在数据库中。然后 eash install 将有一个唯一的秘密,唯一可以访问它的人是网站所有者。
  • 我不会将其存储在数据库中,我建议将其存储在 文档根目录之外的文件系统中

标签: php node.js security cookies


【解决方案1】:

事实证明,这一切都归结为签署我的 cookie - 没什么大不了的,对吧?

在这里要非常小心。之前很多人都尝试过实现这样的功能,只为render their apps remotely exploitable

我几乎会争辩说你不应该自己写这个。我正在为我的 libsodium 包装库构建的功能之一是 an authenticated encryption wrapper for HTTP cookies

挑选一个永远保密的秘密的最佳方法是什么?

最简单:使用来自/dev/urandom 的 32 个字节,存储在文档根目录之外的配置文件中。

最安全:Use a HSM,因此您的密钥永远无法访问,即使攻击者在您的服务器上获得了 root 权限。

【讨论】:

  • 好吧,我确实计划使用某种库;我想有人会实施一个值得信赖的解决方案。事实上,Halite 似乎正是我所寻找的。但这是仅仅看了十分钟左右。但是,有没有不需要 libsodium 的方法?原因:我不妨移植到Win32。我还能保证兼容性吗?
  • 我也刚刚通读了 CVE。我……必须说,我为开发者感到难过。这真是个大坑。但这让我明白了你的意思。我会小心避免 str_shuffle() 像这样。 :)
  • 结语:电子邮件发出后,他们立即从存储库中删除了该类。
  • 对不起@IngwiePhoenix 由于某种原因我没有看到您的第一条评论。查看不依赖 libsodium 的 github.com/defuse/php-encryption(我们正在努力开发版本 2)。
猜你喜欢
  • 1970-01-01
  • 2019-11-14
  • 1970-01-01
  • 1970-01-01
  • 2020-12-04
  • 2022-06-28
  • 1970-01-01
  • 2018-01-13
  • 2021-08-07
相关资源
最近更新 更多