php - Is there a PHP security framework that protects phone numbers as well as passwords?

Question

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?

Answer 1

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.]

Answer 2

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:

• Make sure the key doesn't leak when you inadvertently leak a database dump.
• Make sure your system doesn't helpfully decrypt the phone numbers when someone manages to SQL inject your system.

Of course the recommendation of not rolling your own still applies, use AES or some other well respected cipher with a reasonable key length.

Answer 3

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:

$context = new substrate_Context(
    './path/to/hole-security/hole-security-config.php'
);

$context->execute();

$hole_Security = $context->get('hole_FilterChainProxy' );
$hole_Security->doFilter();

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:

1. 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.

2. Configured filters for be applied to url patterns. Url path matcher can be plugged to, currently it ship with a ant styles path matcher.

3. Authorization Manager can be used in your application to decide wherever or not do something, always obtaining the reference from the substrate context.

4. 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.

5. 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.

6. 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.

7. 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.