[wp-hackers] Wordpress database encryption.

jackie sparks jackie.craig.sparks at live.com
Mon Nov 28 09:15:42 UTC 2011

Doing what wrong? Affecting data portability? It's still all the same data. It would only be encrypted data.

Performance? I really don't see that as being a issue in a day and age where we have 1.2 ghz processors packed into computers tha size of thumb drives and muti-processor multi-core systems capable of sustaining 50-100 websites at once. Honestly on my 2 ghz laptop I don't notice a difference in the speed. 

--[Witty Signature Goes Below]---------------------------------------------------------------------------------------------------------------------
http://www.linkedin.com/profile/view?id=53668912&trk=tab_pro - linked in profile

http://www.facebook.com/skrapsrwt - feel free to add me on facebook.





http://www.phonesnake.com - looking for support by sharing and liking our page and also sponsors to help with the project.

http://www.communicationslibrary.info - taking the knowlege outside the classroom so anyone can be a technician

http://chunkhost.com/r/getachunk - Support my VPS host sign up now 





This e-mail (including attachments) is covered by the Electronic
Communications Privacy Act, 18 U.S.C. Sections 2510-2521, is
confidential, and is intended solely for the use of the individuals or
entities to whom it is addressed. If you are not the intended
recipient or the person responsible for delivering the e-mail to the
intended recipient, be advised that you have received this e-mail in
error and that any use, dissemination, forwarding, printing, or
copying of this e-mail and any file attachments is strictly
prohibited. If you have received this e-mail in error, please
immediately notify me by email at jackie.craig.sparks at live.com. You must destroy
the original transmission and its contents.

> 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

More information about the wp-hackers mailing list