NYCPHP Meetup

NYPHP.org

[nycphp-talk] What's a good way to handle this?

Rick Retzko rick at click-rick.net
Thu May 6 20:26:43 EDT 2010


 

 

  _____  

From: talk-bounces at lists.nyphp.org [mailto:talk-bounces at lists.nyphp.org] On
Behalf Of Anthony Papillion
Sent: Thursday, May 06, 2010 11:36 AM
To: NYPHP Talk
Subject: [nycphp-talk] What's a good way to handle this?

 

Hello Everyone,

As some of you may know, during last years Presidential protests in Iran, I
developed a distributed, multi-level, Twitter proxy service called
TweetFree. For the first time in almost a year, I'm revisiting the code in
an effort to update it and make it more useful for people outside of Iran
but still in oppressive cultures.

The system has several components: a Windows Mobile, iPhone, Android, and
Blackberry application that connects to a TweetFree Relay server, the
TweetFree Relay Server itself, and the main TweetFree Network Servers.  How
this all works together is unimportant so I won't bore you with the details.

Now, the TweetFree Network Servers maintain a network block list. So every
time the Relay Servers send a post, the Network Server checks to make sure
the client that the relay is posting for isn't blocked from the network. If
it is, it says no and the relay tells the client that it couldn't post its
message.  The problem with this, of course, is that you might have thousands
of Relay Servers hitting the Network Servers (as happened during the Iranian
election) and each of those requests have to be processed. That puts a bit
of a load on the server that I'd like to alleviate.

So my thought is to maintain a blacklist of client keys on the Network
Servers and have the Relay Servers download this list every few minutes.
Then, clients could be blocked at the RELAY level instead of at the Network
level and less load would be put on the Network Servers (of which there are
only about 10).

My problem is that I'm not sure how to protect this list. The list is a
simple text file that contains client keys. No identifying information, but
client keys nonetheless. If it's a .txt file then the contents are viewable
publicly which *could* pose a security risk in highly volatile environments.
If I name it with the .php extension, it's handled like a PHP file and,
thus, the text in it can't be read.

What is the best way to handle this? I need to protect the users privacy
while still reducing network load. 

Any ideas?

Thanks!
Anthony Papillion

 

It may not be the best way, but I use
AES_ENCRYPT/AES_DECRYPT($salted_value,$password) along with a salted value
for all of my user-identifiable data.  It is a bit more work on the SQL end
of things, but keeps the data safe within the database unless a hacker could
figure out both the salt expression as well as the password.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nyphp.org/pipermail/talk/attachments/20100506/4a282e0c/attachment.html>


More information about the talk mailing list