[wp-hackers] The security week? :)
Alexander Beutl
xel at netgra.de
Thu Apr 17 13:58:23 GMT 2008
>
> a secret phrase, which is completely humanly random
while we all should be aware that human randomnes is not random enogh for
cryptografical issues. There are several weeknesses in human random strings.
You are of course right: more than 15 chars is better anyway, but I didn't
want to argue about length but about being able to randomly create a string
in the installer which sets a compleatly random passphrase which shouldn't
be of a fixed lenght.
2008/4/17, Alexander Beutl <xel at netgra.de>:
>
> Ok 2 questions:
>
> first: Why is it possible to fill in the database information but not a
> random secret key in wp-config.php while installing - shouldn't that be
> quite as easy? The key doesn't need to be setable by users - it could be set
> via php with no user interaction - and therefor no transfer - needed.
>
> second: Why the hack is the only thing I need to do after changing
> SECRET_KEY logging in? I understand that what was saved in my cookie doesn't
> validate anymore. I do not understand why I do not have to let the pass be
> send via mail like I think you indicated with this:
>
> > 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.
>
>
> Thanks
> Alex
>
> 2008/4/17, Jacob Santos <wordpress at santosj.name>:
> >
> > 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 2.5.x
> > users.
> >
> > 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.
> > >
> > > Alex
> > >
> > > 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-
> > > > > config.php
> > > > > 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
> > > > 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
> > >
> > >
> >
> >
> > --
> >
> > Jacob Santos
> >
> > 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.
> >
> > _______________________________________________
> > 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