[wp-hackers] The security week? :)
wordpress at santosj.name
Thu Apr 17 12:30:21 GMT 2008
There were discussions about adding a field to the installation on Trac,
but it was shot down as too "advanced" for users. The current automated
definition relies on wp-config-sample.php, which has the constant and a
comment to the constant. I had plans on creating a plugin, but I just
totally forgot. Hey, even with the plugin it wouldn't probably get the
word out that it can help you.
The problem is that the constant in wp-config-sample.php is that it does
not change. Also, the problem with having it change based on modified
type is that every time the SECRET_KEY changes, means that it will
invalidate any current passwords. For each change the user will have to
use the forgot password to get a new password and would have to change
their password. I think once is okay, and I doubt that many plugins
modify the wp-config.php, but it might be annoying for users to install
a plugin and then not be able to login.
My secret key is longer than 15 characters, it is longer than 30
characters, actually, my secret key is a secret phrase, which is
completely humanly random and you would have to know me in order to
understand what it is. I think if you are going to create a secret key,
that it should be about 60 characters. Most of my passwords are between
10 and 20 characters, because that is how many characters I can
generally remember. You don't have to remember the secret key, you just
need to define it once and forget about it.
The vector for attack on getting the SECRET_SALT is that if it is not
defined in wp-config.php or elsewhere (like a plugin perhaps?) then it
is within the database table. If a hacker were to somehow get into the
database and view it, then the salt will become available. If the
default SECRET_KEY is not changed, then the hacker will know both the
SECRET_KEY and the SECRET_SALT. The steps to hack into the database are
more difficult in WordPress 2.5.
Actually, from what I can see, the documentation in wp_salt() is no
longer accurate or parts of it are incorrect, either because of a change
in the function body or from code being located elsewhere and not
readily available. I forget where the information that the SECRET_KEY
will use the database information, but if it was changed (I was sure
that code was also within pluggable.php), then SECRET_KEY must be
defined or it will be an empty string. There are also grammar errors in
the inline documentation.
I think this weekend I'm going to have to create a patch for correcting
the incorrect information, however it most likely won't be of help to
Alexander Beutl wrote:
>> The only problem with defining the SECRET_KEY and/or SECRET_SALT on the
>> installation or by a web page on the administration is that most WordPress
>> applications are sent through HTTP and not HTTPS.
> When it is possible to include that secret into wp-config without the user
> noticing it, it would be possible to do this with a randomly created one
> too. It wouldn't be hard to generate a (random lengt) phrase of between 10
> to 15 random chars or whatever.
> If there is any notice to do that within the installation dialog I didn't
> read it - if there is none how should one know to do it?
> You know there is an installation because one will not want to do everything
> by hand. You can not expect anyone to know that he/she will have to do
> anything for it.
> While members of wp-hackers mailing list may have noticed while reading the
> trac mailing list or the SVN Report (which of course isn't really required
> to be on this list), normal users can not be expected to know this.
> 2008/4/17, Stefano Aglietti <steagl4ml at gmail.com>:
>> On Wed, 16 Apr 2008 15:16:01 -0400, Mark Jaquith
>> <mark.wordpress at txfx.net> wrote:
>>> We have a couple options here:
>>> 1. Spread the word and encourage people to add it.
>>> 2. Have a "nag" in wp-admin that generates a random salt, prints the
>>> define('SECRET_KEY', $random_salt); line and tells you to add it to wp-
>>> 3. Try to automatically add the SECRET_KEY define() to wp-config.php
>>> and fall back to #2 if we cannot.
>>> #1 is going to result in very few people utilizing the feature. #2 or
>>> #3 is probably the way to go.
>> +1 to #2 and #3 sound the best and logical solution.
>> Stefano Aglietti - StallonIt on IRCnet - ICQ#: 2078431
>> Email: steve at 40annibuttati.it steagl at people.it
>> Sites: http://www.40annibuttati.it (personal blog)
>> http://www.wordpress-it.it (WordPress Italia)
>> wp-hackers mailing list
>> wp-hackers at lists.automattic.com
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
http://www.santosj.name - blog
http://funcdoc.wordpress.com - WordPress Documentation Blog/Guide Licensed under GPLv2
Also known as darkdragon and santosj on WP trac.
More information about the wp-hackers