[Phpmyadmin-devel] fallback login to http or cookie when config fails?

Hi, how about fall back to cookie or http auth if config auth fails? would make it more easy to run phpMyAdmin out of the box (at least for localhost) but only if config is set to root without password if config_auth_fail, user == 'root', pw == '' than switch to cookie auth and display message about it -- Sebastian Mendel www.sebastianmendel.de

Hi On Thu, 22 Mar 2007 09:29:09 +0100 Sebastian Mendel <lists@sebastianmendel.de> wrote:
how about fall back to cookie or http auth if config auth fails?
would make it more easy to run phpMyAdmin out of the box (at least for localhost)
but only if config is set to root without password
if config_auth_fail, user == 'root', pw == '' than switch to cookie auth and display message about it
I already saw request on some generic fallback configuration scheme somewhere, but I'm unable to find it right now... -- Michal Čihař | http://cihar.com | http://blog.cihar.com

Michal Čihař schrieb:
Hi
On Thu, 22 Mar 2007 09:29:09 +0100 Sebastian Mendel <lists@sebastianmendel.de> wrote:
how about fall back to cookie or http auth if config auth fails?
would make it more easy to run phpMyAdmin out of the box (at least for localhost)
but only if config is set to root without password
if config_auth_fail, user == 'root', pw == '' than switch to cookie auth and display message about it
I already saw request on some generic fallback configuration scheme somewhere, but I'm unable to find it right now...
but i am not sure ... it gives everybody the possibility for bruteforce attacks on new installations ... or? btw. we have no protection against bruteforce, or? such a protection would require a shared place to store data: db, shmem or file -- Sebastian Mendel www.sebastianmendel.de

Sebastian Mendel schrieb:
Michal Čihař schrieb:
Hi
On Thu, 22 Mar 2007 09:29:09 +0100 Sebastian Mendel <lists@sebastianmendel.de> wrote:
how about fall back to cookie or http auth if config auth fails?
would make it more easy to run phpMyAdmin out of the box (at least for localhost)
but only if config is set to root without password
if config_auth_fail, user == 'root', pw == '' than switch to cookie auth and display message about it I already saw request on some generic fallback configuration scheme somewhere, but I'm unable to find it right now...
but i am not sure ... it gives everybody the possibility for bruteforce attacks on new installations ... or?
weird ... just forget about this ...
btw. we have no protection against bruteforce, or?
such a protection would require a shared place to store data: db, shmem or file
-- Sebastian Mendel www.sebastianmendel.de

Sebastian Mendel wrote:
Michal Čihař schrieb:
Hi
On Thu, 22 Mar 2007 09:29:09 +0100 Sebastian Mendel <lists@sebastianmendel.de> wrote:
how about fall back to cookie or http auth if config auth fails?
would make it more easy to run phpMyAdmin out of the box (at least for localhost)
but only if config is set to root without password
if config_auth_fail, user == 'root', pw == '' than switch to cookie auth and display message about it
I already saw request on some generic fallback configuration scheme somewhere, but I'm unable to find it right now...
but i am not sure ... it gives everybody the possibility for bruteforce attacks on new installations ... or?
btw. we have no protection against bruteforce, or?
such a protection would require a shared place to store data: db, shmem or file
-- Sebastian Mendel
being granted all rights if there is no config.inc and if root has no pw set in mysql is even worse, isn't it? -- View this message in context: http://www.nabble.com/fallback-login-to-http-or-cookie-when-config-fails--tf... Sent from the phpmyadmin-devel mailing list archive at Nabble.com.

Juergen Wind schrieb:
Sebastian Mendel wrote:
Michal Čihař schrieb:
Hi
On Thu, 22 Mar 2007 09:29:09 +0100 Sebastian Mendel <lists@sebastianmendel.de> wrote:
how about fall back to cookie or http auth if config auth fails?
would make it more easy to run phpMyAdmin out of the box (at least for localhost)
but only if config is set to root without password
if config_auth_fail, user == 'root', pw == '' than switch to cookie auth and display message about it I already saw request on some generic fallback configuration scheme somewhere, but I'm unable to find it right now... but i am not sure ... it gives everybody the possibility for bruteforce attacks on new installations ... or?
btw. we have no protection against bruteforce, or?
such a protection would require a shared place to store data: db, shmem or file
being granted all rights if there is no config.inc and if root has no pw set in mysql is even worse, isn't it?
yes, thats why i wrote forget about it ... -- Sebastian

Sebastian Mendel a écrit :
Hi,
how about fall back to cookie or http auth if config auth fails?
would make it more easy to run phpMyAdmin out of the box (at least for localhost)
but only if config is set to root without password
if config_auth_fail, user == 'root', pw == '' than switch to cookie auth and display message about it
I would prefer to remove "config" auth. Now that we require cookie support in browser, I don't see any advantage for "config" auth, only security issues because their user/password in the file, which requires protection on the web-server level and protection from spies on a shared server. Setup script already generates a blowfish secret. Our config sample uses "cookie" auth as default. Marc

Marc Delisle schrieb:
Sebastian Mendel a écrit :
Hi,
how about fall back to cookie or http auth if config auth fails?
would make it more easy to run phpMyAdmin out of the box (at least for localhost)
but only if config is set to root without password
if config_auth_fail, user == 'root', pw == '' than switch to cookie auth and display message about it
I would prefer to remove "config" auth.
i always use config! -- Sebastian Mendel www.sebastianmendel.de

Marc Delisle wrote:
Sebastian Mendel a écrit :
Hi,
how about fall back to cookie or http auth if config auth fails?
would make it more easy to run phpMyAdmin out of the box (at least for localhost)
but only if config is set to root without password
if config_auth_fail, user == 'root', pw == '' than switch to cookie auth and display message about it
I would prefer to remove "config" auth. Now that we require cookie support in browser, I don't see any advantage for "config" auth, only security issues because their user/password in the file, which requires protection on the web-server level and protection from spies on a shared server.
Setup script already generates a blowfish secret.
Our config sample uses "cookie" auth as default. Marc
objection again ;) i have all my pma versions in a .htaccess protected folder and normally use "config" auth ("cookie" only for testing/reproducing error reports). But i suggest to use "http" in config.default insted of "config" (cookie would be even better, but requires a unique "blowfish" secret). just my 2 euro cent -- View this message in context: http://www.nabble.com/fallback-login-to-http-or-cookie-when-config-fails--tf... Sent from the phpmyadmin-devel mailing list archive at Nabble.com.

Juergen Wind schrieb:
Marc Delisle wrote:
Sebastian Mendel a écrit :
Hi,
how about fall back to cookie or http auth if config auth fails?
would make it more easy to run phpMyAdmin out of the box (at least for localhost)
but only if config is set to root without password
if config_auth_fail, user == 'root', pw == '' than switch to cookie auth and display message about it
I would prefer to remove "config" auth. Now that we require cookie support in browser, I don't see any advantage for "config" auth, only security issues because their user/password in the file, which requires protection on the web-server level and protection from spies on a shared server.
Setup script already generates a blowfish secret.
Our config sample uses "cookie" auth as default. Marc
objection again ;) i have all my pma versions in a .htaccess protected folder and normally use "config" auth ("cookie" only for testing/reproducing error reports). But i suggest to use "http" in config.default insted of "config" (cookie would be even better, but requires a unique "blowfish" secret).
we could easily create a random 'secret', and store it in the session, it limits the cookie login time to session length - but this should not hurt and it gives each individual, f.e. example on shared hoster, a unique 'secret' it has the side effect that someone 'evil' getting somehow the 'secret' from the config and uses XSS to send stored cookies cannot decrypt the cookie -- Sebastian
participants (4)
-
Juergen Wind
-
Marc Delisle
-
Michal Čihař
-
Sebastian Mendel