[wp-hackers] Wordpress database encryption.

Mon Nov 28 14:15:05 UTC 2011

 ?Encryption doesn't help against SQL injection.?

Yes it does. When using the AES_ENCRYPT and AES_DECRYPT calls its formatted like so AES_ENCRYPT('datahere', 'somekey'); AES_DECRYPT('column_name', 'somekey') so when performing the sql with a union statement they now have to use AES_DECRYPT('column_name', 'key') 

So if they are able to retrieve any data it is double AES encrypted with different 255 character keys. This would kill brute forcing attempts. Currently wordpress uses md5 salted hashes for passwords. These can be cracked in minutes with GPU acceleration. 

https://www.google.com/search?client=ubuntu&channel=fs&q=port+443&ie=utf-8&oe=utf-8#sclient=psy-ab&hl=en&client=ubuntu&hs=bHi&channel=fs&source=hp&q=john+ripper+gpu+acceleration+support+you+tube+md5&pbx=1&oq=john+ripper+gpu+acceleration+support+you+tube+md5&aq=f&aqi=&aql=&gs_sm=e&gs_upl=1300l6597l1l6786l13l11l0l0l0l0l355l2666l0.1.6.3l10l0&bav=on.2,or.r_gc.r_pw.,cf.osb&fp=614028ccd2490d92&biw=1280&bih=712

If they have done that. all they get back is encrypted data that will not be processed by internal decrypt functions because the way I'm trying to set it up in the development branch here http://code.google.com/p/wordpress-aes/source/browse/?name=development it will only process certain queries run thru the application by means of a preg_match regex. 

If the machine is compromised in another fashion ie: service zero day, then they will have the keys. But for the most part if your services are kept up to date then you don't have anything to worry about. This would be a huge security improvement for the whole system and mitigating SQL fuzzing and injections on the system. Alot of crackers wouldn't even want to deal with the hassle of cracking the information they retrieved because it would take so long.

> Date: Mon, 28 Nov 2011 08:55:30 -0500
> From: patrick_laverty at brown.edu
> To: wp-hackers at lists.automattic.com
> Subject: Re: [wp-hackers] Wordpress database encryption.
> 
> 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
> >
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers