Creating Secure PM's??

[doubledee]

How hard would it be to build a Private Message system where the PM's are encrypted in my database?

 

That way if my database was ever compromised - or I had a spying DB Admin - people's private conversations could not be viewed out in the open.

 

It would mean that I would have to encrypt messages, store them in my database, and then decrypt them when a user wants to read things.

 

Just curious...

 

Thanks,

 

 

Debbie

 

[The Little Guy]

you could store them as a base64 string using a salt

[doubledee]

you could store them as a base64 string using a salt

 

I don't understand what you are recommending...

 

 

Debbie

 

[l0gic]

Well, try this..

<?php
$str = "This is an encoded string";
echo base64_encode($str); // Should output VGhpcyBpcyBhbiBlbmNvZGVkIHN0cmluZw==
?>

 

So..

<?php
$str =  "This is an encoded string";
echo "Original: " $str . "<br>\n";
$str = base64_encode($str);
echo "Encoded: " $str . "<br>\n";
echo "Decoded: " base64_decode($str) . "<br>\n";
?>

 

Pretty much copy/pasted from:

http://php.net/manual/en/function.base64-encode.php

http://php.net/manual/en/function.base64-decode.php

 

Personally I'd just be pickier about who can see the DB.

 

Edit: Fixed my error in second lot of code.

[The Little Guy]

This is just a rough draft, but it does work (please read the comments):

 

<?php
$salt = "oasd83or34509ig6DF";

echo $message = "Hello, what are you doing tonight?";

echo "<br><br><br>";
// Encode it for the database:
echo $val = base64_encode(base64_encode($salt).base64_encode($message));

echo "<br><br><br>";
// An attempt to decode it if you DON'T know how it was hashed:
// It will return something like this: "b2FzZDgzb3IzNDUwOWlnNkRGSGVsbG8sIHdoYXQgYXJlIHlvdSBkb2luZyB0b25pZ2h0Pw=="
// You need the salt to get past, and the algorithm
echo $return = base64_decode($val);

echo "<br><br><br>";
// An attempt to decode it if you DO know how it was hashed:
echo $return = base64_decode(base64_encode($salt).base64_decode($val));

echo "<br><br><br>";
// Remove the salt (2 salts were added for some reason)
echo preg_replace("/^$salt$salt/i", "", $return);

[scootstah]

Well, try this..

<?php
$str = 'This is an encoded string';
echo base64_encode($str); // Should output VGhpcyBpcyBhbiBlbmNvZGVkIHN0cmluZw==
?>

 

So..

<?php
$str =  "This is an encoded string";
echo "Original: " $str . "<br>\n";
$str = base64_encode($str);
echo "Encoded: " $str . "<br>\n";
echo "Decoded: " base64_decode($str) . "<br>\n";
?>

 

Pretty much copy/pasted from:

http://php.net/manual/en/function.base64-encode.php

http://php.net/manual/en/function.base64-decode.php

 

Personally I'd just be pickier about who can see the DB.

 

Edit: Fixed my error in second lot of code.

 

That's not encryption and is just as easy to see as plain text.

 

I don't think there's a lot of merit for doing something like this. Your users are stupid to begin with to disclose sensitive information in a random website. Plus if you're not using SSL it's rather pointless.

 

But since you asked, you can do it with the mcrypt library. http://www.php.net/manual/en/function.mcrypt-encrypt.php

[l0gic]

That's not encryption and is just as easy to see as plain text.

 

Yes, but seeing is not the same as reading.

 

And if anyone browsing the DB through say PhpMyAdmin or an SQL dump has the ability to decode that in their mind, then they deserve to be able to read it.. If they have the ability to pull it out and use base64_decode() then it wasn't worth doing in the first place.

 

Common sense is usually secure enough. If people shouldn't be able to see things, don't give them the means to see things.

[scootstah]

base64 is usually pretty recognizable. It is absolutely trivial to decode it; I have a Firefox addon to do it in about 2 key presses.

 

base64 was not made to be secure, so it is stupid to use it in such a way.

[cpd]

Unless your planning on having loads of DBA's or just people with the ability to log into your database, its not worth worrying about.

 

As already mentioned, mcrypt is a good route to go along and one of the best. You can look into bit shifting with the bitwise operators as well to make it a little more difficult.

[cpd]

base64 is usually pretty recognizable. It is absolutely trivial to decode it; I have a Firefox addon to do it in about 2 key presses.

 

base64 was not made to be secure, so it is stupid to use it in such a way.

 

And scootstah is right its not intended as an encryption tool. It's use is to ensure data isn't manipulated in some manner when being transferred from one location to another.

[l0gic]

Fair enough, I'll retract my previous statements with the exception of...

 

"Personally I'd just be pickier about who can see the DB."

[scootstah]

"Personally I'd just be pickier about who can see the DB."

 

That's not the point. The point is that in the event her database was hacked, she doesn't want the hackers to be able to read the private message conversations. This has little to nothing to do with "who can see the DB".

[l0gic]

This has little to nothing to do with "who can see the DB".

 

..or I had a spying DB Admin..

 

Right.. Carry on.. I'm off to the pub.

[scootstah]

This has little to nothing to do with "who can see the DB".

 

..or I had a spying DB Admin..

 

Right.. Carry on.. I'm off to the pub.

 

My apologies, apparently I skipped over that.

[l0gic]

Looking into it more mcrypt would be the way to go if you really wanted to do this.

 

I can't say I've ever come across the need to do it though. And your users should be aware of what the send via private message, it comes back to that common sense thing.

 

For example, Scootstah might PM me asking if he can use my credit card to buy something. I wouldn't reply saying "Yeah, of course my CC number is 5402........... etc" I'd just say yes, that it could be arranged.

[scootstah]

For example, Scootstah might PM me asking if he can use my credit card to buy something. I wouldn't reply saying "Yeah, of course my CC number is 5402........... etc" I'd just say yes, that it could be arranged.

 

So uhh, I was looking at this new laptop...

[cpd]

Wow, that's dirt cheap... not as awesome as the Raspberry PI though

[l0gic]

Kinda walked into that didn't I?

 

See what Santa brings you.

[doubledee]

That's not encryption and is just as easy to see as plain text.

 

Yes, but seeing is not the same as reading.

 

And if anyone browsing the DB through say PhpMyAdmin or an SQL dump has the ability to decode that in their mind, then they deserve to be able to read it.. If they have the ability to pull it out and use base64_decode() then it wasn't worth doing in the first place.

 

Common sense is usually secure enough. If people shouldn't be able to see things, don't give them the means to see things.

 

Let's step back for a minute here...

 

1.) If I run a website that becomes widly popular - even mildly popular - and I have people posting away their lives - even if it is just their thoughts and opinions - then I feel a fiduciary responsibility to *reasonably* protect that information.

 

If someone hacked my website or database, I don't want to give away everything.  The bad guys should have to at least work to get at the data.

 

 

2.) Since I am building an e-commerce site, what about the non-credit card info I might be storing (e.g. Name, Address, Order History) that is still sensitive.  I would feel pretty bad if I lost the mailing addresses for 10,000 Members who trusted me.

 

And before some smar*ss says something...

 

No, I am not the Defense Department nor do I have a billion dollars to build the world's most secure data center?!

 

But there is nothing wrong with taking baby steps and doing what I can to make it extremely difficult for people to get at my User's data even if it is inconsequential like what they think about the article "Postage Meters Cab Save You Money"?!

 

 

Debbie

 

[doubledee]

"Personally I'd just be pickier about who can see the DB."

 

That's not the point. The point is that in the event her database was hacked, she doesn't want the hackers to be able to read the private message conversations. This has little to nothing to do with "who can see the DB".

 

Bingo!!!

 

 

Debbie

 

[doubledee]

Looking into it more mcrypt would be the way to go if you really wanted to do this.

 

I can't say I've ever come across the need to do it though. And your users should be aware of what the send via private message, it comes back to that common sense thing.

 

For example, Scootstah might PM me asking if he can use my credit card to buy something. I wouldn't reply saying "Yeah, of course my CC number is 5402........... etc" I'd just say yes, that it could be arranged.

 

Honey, if you have a credit card - with LOTS OF Available Credit - then this thread no longer matters and we should talk offline...    *LOL* *ROFL*

 

 

Debbie

[l0gic]

Honey, if you have a credit card - with LOTS OF Available Credit - then this thread no longer matters and we should talk offline...    *LOL* *ROFL*

 

 

Debbie

 

Actually, it's a debit card.. But I guess "lots" still applies.

 

Have you considered splitting your database?

[darkfreaks]

if you plan on using mcrypt  you could use something similar to this.

 

http://www.itnewb.com/tutorial/PHP-Encryption-Decryption-Using-the-MCrypt-Library-libmcrypt

[doubledee]

Have you considered splitting your database?

 

What do you mean?

 

 

Debbie

 

[l0gic]

What do you mean?

 

Debbie

 

Well some people would look at a 'large' site and split their database into several smaller databases to handle each part of the site.

 

For example, and online store with a forum might have:

 

User Info: Containing user information like usernames, real names, contact information, personal details, etc.

Shop: Containing products, product info, prices, comments, etc.

Forums: Containing forum topics, posts and replies, etc.

Purchases: Purchase history, invoices, orders, etc.

 

I don't know if people still do it much like this, but imagine when you're users sign-in they have to authenticate themselves and set a session variable. Now they authenticate themselves using your database which also contains personal data, orders, etc.. They're all open to inject-type attacks. But if they're only authenticating to using a database that only stores login data and what-not then that type of attack has no direct path to those other details.

 

Same as forum posts, the purchases database wouldn't be as easily attacked from an attack on the forum database.

 

Following?

 

Again, I don't know if this is widely used or not.. Maybe someone who worries about security more than I can chime in?