[wp-hackers] Wordpress database encryption.

[Patrick Laverty]

Sorry for the n00b question at this point, but what are you trying to
protect? Encryption doesn't help against SQL injection, as the app
will simply decrypt the data that you get back, right? So then the
protection is against someone exporting the whole database out from
under the application? If that's the concern, aren't there really
bigger problems, like securing the machine and if they have access to
the server at that level, then they also have access to everything to
decrypt the database?

Sorry, I'm not completely understanding yet what is the goal.

Thank you.



On Mon, Nov 28, 2011 at 5:32 AM, jackie sparks
<jackie.craig.sparks at live.com> wrote:
>
> Honestly security is worth a lot more than speed. IMHO. Honestly if wordpress or joomla were to initiate these types of changes it would set a new security standard in the open source community. Enterprise grade security for even the people who can't afford it.
>
> No one else is doing it at this point, not even commercial forum and blogging solutions. This would be ahead of the curve.
>
>
> The Grub devs didn't want to mainline Michael Gorvens(in no way am I comparing me to Michael, I know there are better ways of doing what I did. I just prototyped it and still trying to figure out the best way to incorporate it into the wp-db class now.) work with boot partition encryption at first. Then Vladmir main lined it. Turned out tons of people wanted it and it helped so many people. Here soon you will see it as a option in modern distro. I really hope Ubuntu includes it in there next release.
>
>
>> Date: Mon, 28 Nov 2011 10:32:29 +0200
>> From: stas at nerd.ro
>> To: wp-hackers at lists.automattic.com
>> Subject: Re: [wp-hackers] Wordpress database encryption.
>>
>> On Lu 28 nov 2011 01:42:59 +0200, Mike Schinkel wrote:
>> > On Nov 27, 2011, at 2:05 AM, Dion Hulse (dd32) wrote:
>> >> Basically, always sanitize any data doing into a SQL statement.
>> >> For example, if you had a plugin which filtered the WHERE statement,
>> >> like so: (Yes, I realise this is wrong on so many levels, and won't
>> >> work as-is due to escaping)
>> >>
>> >> add_filter('sql_where_hook_name', function($sql) {  return $sql .  '
>> >> AND post_date>  ' . $_GET['some_field']; } );
>> >> something such as ?some_field=1 AND 0=1 UNION SELECT user_name as
>> >> post_title, user_pass as post_content FROM wp_users; --
>> >
>> > OK, thanks. It's the UNION statement I drew a blank on (embarrassed, I've only been working professionally with SQL since 1994...) I get it now.
>> >
>> >> The simplest way to avoid it happening?
>> >> - Always use prepared statements.
>> >
>> > Fortunately I've already been doing this, just didn't always know why it mattered in some cases. Now I think I do.
>> >
>> >> - don't do direct SQL calls to start with..
>> >
>> > Heh. Sometimes you can't help it.  But, that's what $wpdb->prepare() is for, right?
>> >
>> >> check if the function/filter you're using expects sanitized
>> >> data or unsanitized data to be passed/returned (simplest way to check
>> >> is that \ and ' works as expected, although that's not a definite
>> >> secure way to check)
>> >
>> > That's helpful too.
>> >
>> >> For example, if you're only
>> >> accepting an number, why not cast it to an int?  if it's a specific
>> >> command, check that string exists in an array: if (
>> >> isset($_GET['my_command']&&  !in_array($_GET['my_command'],
>> >> array('command1', 'command2') ) { die('Uh, what are you doing?'); }
>> >
>> > Ditto there.
>> >
>> >> This tutorial (even if you just look at the examples) shows how you
>> >> can exploit injections with ease:
>> >> http://www.unixwiz.net/techtips/sql-injection.html
>> >
>> > Exactly what I was asking for. Thanks!
>> >
>> >> I hope you find something of use here Mike, but my best advice is
>> >> really "Never trust a human, or a Computer for that matter, Whitelist
>> >> what they're allowed to do, Don't just block all 'DROP' in input data
>> >> (as I see some sites do)"
>> >
>> > It was very helpful, thank you.  AFAICT, I've been following all necessary best practices, I just have not understood all the main use cases that were being protected against. Now I do. Cool.
>> >
>>
>> Imho, you are doing it wrong.
>> Ages have learned you to not trust human, but in modern times (21st
>> century) this led to TDD/TBD and definitely not to solutions like this.
>> Beside complicating things, your solution will also have impact on
>> performance not mentioning portability of the stored data.
>> Anyway, as it was already said, everyone is free to act the way he
>> decides, but your impact could have been greater if you provided a set
>> of tests/specs that will cover wpdb class.
>>
>> Good luck.
>> _______________________________________________
>> wp-hackers mailing list
>> wp-hackers at lists.automattic.com
>> http://lists.automattic.com/mailman/listinfo/wp-hackers
>
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers
>