有没有可以保护电话号码和密码的 PHP 安全框架?
当谈到站点安全框架时,我理解“不要自己开发”的格言。
无论如何,对于大多数情况。
我将在一个将短信集成到系统中的网站上进行合作。
我想使用现有的、经过充分测试的安全框架来保护用户数据,但我也需要它来保护用户的电话号码。
我不想成为一系列用户手机号码被劫持和垃圾邮件的责任人。
社区可以提供哪些建议?
I understand the mantra of "don't roll your own" when it comes to site security frameworks.
For most cases anyway.
I'm going to be collaborating on a site that integrates text-messaging into the system.
I'd like to use an existing, well-tested security framework to protect the users data, but I need it to also protect a users phone number as well.
I wouldn't want to be the one responsible for a list of users cell phone numbers getting jacked and spammed.
What suggestions can the community offer?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
我很高兴地宣布发布 PHP 漏洞安全系统。
该项目代表为 PHP 带来由 Spring Security(以前的 Acegi Security System for Spring)在 Java 中提供的安全性。 它的设计目的是对 Spring Security 用户有吸引力,因为理念是相同的。 这是一种为 PHP 站点添加安全性的低调方法。 该配置是使用底层 IoC/DI 进行的,就像 Spring Security 使用 Spring IoC/DI 一样。
框架附带了一个示例配置,可以像这样使用:
只需确保框架的引导代码在您选择的 MVC 的引导之前执行。
网站:
http://code.google.com/p/hole-security/
文档:
目前,您可以在适用的地方使用 Spring Security 的参考文档。 您可以使用 Acegi Security 参考文档获得一个总体概念,因为漏洞安全性使用相同的配置方式,但请记住它基于 Spring Security。
执照:
它是根据 Apache 许可证版本 2.0 发布的。
特征:
hole-security 带来了一个可插拔的安全系统,您可以在其中采用您环境的安全要求。 目前有一个非常简单的安全系统,因为它是第一个版本,但有了它带来的基础,您可以建议或请求将新功能添加到项目中。
当前功能:
内存 dao 身份验证作为概念证明,您可以切换到您喜欢的 dao 或实现,从数据库或存储位置获取用户数据。 在未来版本中,将创建基于 PDO 的实现。
配置的过滤器适用于 url 模式。 可以插入 URL 路径匹配器,目前它附带了 ant 样式路径匹配器。
授权管理器可用于在您的应用程序中决定何时或不执行某些操作,始终从底层上下文获取引用。
授权管理器可用于
如果应用了hole_HttpSessionContextIntegrationFilter,则可以从应用程序的任何代码访问共享安全上下文。 您可以使用此上下文来保存与会话相关的信息,而无需直接使用会话对象。
您可以使用自定义登录页面并根据hole_AuthenticationProcessingFilter配置进行自定义,或者根据您的自定义登录页面自定义hole_AuthenticationProcessingFilter。
默认的密码编码器是纯文本,不进行编码。 未来版本将实现 MD5、基于 Sha、Base64 和其他相关编码。 您可以创建自己的密码编码器并进行配置。
所有对象都会根据需要加载,如果像过滤器之类的东西不用于请求,则不会加载。 这提高了应用程序的性能
还有其他与漏洞安全性相关的功能。
I’m pleased to announce the release of hole-security system for PHP
This project stands for bring to PHP the kind of security that is provided in Java by Spring Security the formerly Acegi Security System for Spring. It’s designed to be attractive to Spring Security users because the philosophy is the same. It’s an unobtrusive way to add security to a PHP site. The configuration is made using substrate IoC/DI as Spring Security use Spring IoC/DI.
An example configuration ship with the framework and can be used like this:
Just be sure that the bootstrap code of the framework is executed before the bootstrap of the MVC of your choice.
WebSite:
http://code.google.com/p/hole-security/
Documentation:
For the moment you can use reference documentation of Spring Security where it’s apply. You can get a general idea using the Acegi Security reference documentation because hole-security use the same way of configuration, but keep in mind that it’s based on Spring Security.
License:
It’s released under Apache License Version 2.0.
Features:
hole-security brings an pluggable security system where you can adopt the security requirement of your environment. Currently there is a very simple security system because it’s on the first release but with the base foundation that it brings you could suggest or request for new features to be added to the project.
Currently Features:
In memory dao authentication as a proof of concept, you can switch to your preferred dao or implementation that get’s user data from database or wherever you store it. In futures release an PDO based implementation will be created.
Configured filters for be applied to url patterns. Url path matcher can be plugged to, currently it ship with a ant styles path matcher.
Authorization Manager can be used in your application to decide wherever or not do something, always obtaining the reference from the substrate context.
Shared Security Context accessible from any code of your application if hole_HttpSessionContextIntegrationFilter is applied. You can use this context to save information related to the session without use the session object directly.
You can use a custom login page and customize it according to the hole_AuthenticationProcessingFilter configuration, or customize hole_AuthenticationProcessingFilter according to your custom login page.
The default password encoder is plain text, without encoding. Futures releases will have implementations for MD5, Sha based, Base64 and others related encoding. You can create your own password encoder and get configured.
All the objects are loaded as required, if something like a filter it’s not used for a request would not be loaded. This increase the performance of the application
There are others features related that hole-security have.
由于您需要能够检索电话号码,因此您真正可以做的唯一事情是保护它们(除了保护数据库的正常操作之外)就是对它们进行加密。 这意味着您需要:
当然,不自行实施的建议仍然适用,请使用 AES 或其他一些受人尊敬的密码,并具有合理的密钥长度。
Since you need to be able to retrieve the phone numbers, the only thing you can really do to protect them (beyond the normal things you would do to protecting your db) is encrypt them. This means that you need to:
Of course the recommendation of not rolling your own still applies, use AES or some other well respected cipher with a reasonable key length.
请注意,应用于密码的技术在这里不适用。 您可以存储加盐和散列的密码(尽管这样做的价值可能存在争议),但这不适用于电话号码。
如果有人劫持了你的服务器,他们就可以做服务器能做的任何事情。 这必须包括恢复电话号码,但不包括恢复密码(如果密码散列良好)。 所以电话号码只是保护机密数据的一个特例。
如果电话号码确实是应用程序中唯一的敏感数据,那么您可以考虑隔离应用程序发送文本的部分,并对电话号码进行非对称加密。 在不同的进程中(或在不同的计算机上)运行具有解密电话号码密钥的应用程序。 该应用程序的界面可能有一个函数,用于获取加密的否和要发送的消息。 保持这个应用程序简单,并测试和审计它的鼻涕。 要么向外界隐藏它,要么使用身份验证来证明请求确实来自您的主应用程序,或者两者兼而有之。
数据库和应用程序的主要部分都无法解密电话号码(例如您无法搜索它们),但它们可以对其进行加密以添加到数据库中。
一般的技术称为“权限分离”,上面只是一个例子。
请注意,在加密之前,电话号码通常需要用随机数据填充(例如对散列密码进行加盐处理)。 否则,在不知道私钥的情况下,可以回答“加密的电话号码 X 是吗?”的问题。 从垃圾邮件发送者窃取您的通讯组列表的角度来看,这可能不是问题,但从声称您的电话号码被安全存储的角度来看,这是一个问题,因为这意味着暴力攻击变得可行:只有几十亿个电话号码。电话号码,并且可以针对给定用户大幅缩小范围。
抱歉,这并不能直接回答你的问题:我不知道是否有一个PHP框架可以帮助实现权限分离。
[编辑添加:事实上,我想到在“保持特权应用程序简单”的标题下,您可能根本不想使用框架。 这在某种程度上取决于您是否认为您更有可能或不太可能在真正需要的少量代码中留下错误,而不是框架作者在他们更大(但更广泛使用)的代码中留下错误。已经写了。 但这过于简单化了。]
Note that techniques applied to passwords aren't applicable here. You can store a password salted and hashed (although the value of doing so can be disputed), but that doesn't work for phone numbers.
If someone jacks your server, they can do anything the server can. This must include recovering the phone number, but doesn't include recovering the password if it's hashed well. So the phone number is just a particular case of protecting confidential data.
If phone nos truly are the only sensitive data in the app, then you could look at walling off the part of the app that sends the texts, and asymmetrically encrypting the phone nos. In a different process (or on a different machine) run an app that has the key to decrypt phone nos. This app's interface would have maybe one function taking an encrypted no and the message to send. Keep this app simple, and test and audit the snot out of it. Either hide it from the outside world, or use authentication to prove the request really came from your main app, or both.
Neither the db nor the main part of the app is capable of decrypting phone nos (so for example you can't search on them), but they can encrypt them for addition to the db.
The general technique is called "Privilege separation", the above is just one example.
Note that phone nos would generally need to be padded with random data before encryption (like salting a hashed password). Otherwise it's possible to answer the question "is the encrypted phone number X?", without knowing the private key. That may not be a problem from the POV of spammers stealing your distribution list, but it is a problem from the POV of claiming that your phone numbers are securely stored, since it means a brute force attack becomes feasible: there are only a few billion phone nos, and it may be possible to narrow that down massively for a given user.
Sorry this doesn't directly answer your question: I don't know whether there's a PHP framework which will help implement privilege separation.
[Edit to add: in fact, it occurs to me that under the heading of 'keep the privileged app simple', you might not want to use a framework at all. It sort of depends whether you think you're more or less likely leave bugs in the small amount of code you really need, than the framework authors are to have left bugs in the much larger (but more widely used) amount of code they've written. But that's a huge over-simplification.]