Closed GoogleCodeExporter closed 8 years ago
I'm guessing the hash change resulted this and thus all the old passwords are
now invalid, but there is no way to log back in to change the password OR no
one can use the password reset feature to get a new password (and that should
result a new hash in the database?)
Original comment by Logic...@gmail.com
on 29 Oct 2013 at 7:34
This was already fixed, but did not end up in the 2.2.2 release. I'll make a
new release, but attached is the new version of the
LostPasswordService.class.php.
What is the error when you try to log in? I tested the update quite many times,
it is supposed to work so that old password is left there and new hash is
stored whenever user logs in and does not have it. After that, the old is not
used anymore.
Original comment by samuli.j...@gmail.com
on 29 Oct 2013 at 7:44
Attachments:
It simply gives "Incorrect Username or Password" below on that long gray line
Original comment by Logic...@gmail.com
on 29 Oct 2013 at 7:46
Is there anything in the PHP error log?
Original comment by samuli.j...@gmail.com
on 29 Oct 2013 at 7:49
The new LostPasswordService.class.php does not work either, error code is:
MOLLIFY ERROR: PHP error #2, is_readable(): open_basedir restriction in effect.
File(/dev/urandom) is not within the allowed path(s):
(LIST_OF_PHP_OPEN_BASEDIR_EXCEPTIONS)
(C:\PATH_TO_MOLLIFY\backend\vendor\phpass\PasswordHash.php:51)
{0:{function:globalErrorHandler, args:{0:2, 1:is_readable(): open_basedir
restriction in effect. File(/dev/urandom) is not within the allowed path(s):
(LIST_OF_PHP_OPEN_BASEDIR_EXCEPTIONS),
2:PATH_TO_MOLLIFY\MOLLIFY\backend\vendor\phpass\PasswordHash.php, 3:51,
4:{count:16, output:}}},
1:{file:PATH_TO_MOLLIFY\backend\vendor\phpass\PasswordHash.php, line:51,
function:is_readable, args:{0:/dev/urandom}}, 2:{file:...
This error continues, if you need the full one, tell me, but it seems to be
just repeating the same stuff over and over i copy/pasted above.
Original comment by Logic...@gmail.com
on 29 Oct 2013 at 7:52
@ "Is there anything in the PHP error log?"
By just trying to log in without using password reset, there is nothing in PHP
Error Log, but there are errors when trying to use the new class or the old one.
Original comment by Logic...@gmail.com
on 29 Oct 2013 at 7:53
Wait a minute, i think there is while user is trying to log in, it gives:
MOLLIFY ERROR: ServiceException: INVALID_CONFIGURATION=User auth info missing 25
and
MOLLIFY ERROR:
{0:{file:C:PATH_TO_MOLLIFY\backend\include\Authentication.class.php, line:114,
function:auth, class:Authentication, type:->, args:{0:{id:25,
name:USERNAME_IN_PLAIN_TEXT, lang:, email:MAIL_IN_PLAIN_TEXT}, 1:,
2:PASSWORD_IN_PLAIN_TEXT}},
1:{file:C:\PATH_TO_MOLLIFY\backend\include\services\SessionServices.class.php,
line:59, function:login, class:Authentication, type:->, args:{0:... continues
and repeats itself.
Notice the plain text things.
Original comment by Logic...@gmail.com
on 29 Oct 2013 at 8:02
Seems like the update script did not make any inserts into the "user_auth"
table, can you check that?
There is one possible explanation to this, but I do wonder how did it work on
my test site. The original insert clause is this:
INSERT INTO `{TABLE_PREFIX}user_auth` (user_id, type, salt, hash) SELECT id,
auth, '-' as salt, '-' as hash FROM `{TABLE_PREFIX}user`;
My theory here is that since the column names are not identical, the insert
will not work. If you can try running manually this clause:
INSERT INTO `{TABLE_PREFIX}user_auth` (user_id, type, salt, hash) SELECT id as
user_id, auth as type, '-' as salt, '-' as hash FROM `{TABLE_PREFIX}user`;
(naturally remove or replace the {TABLE_PREFIX}. I'll run few tests with this
before I make new release, but running this script should fix the login
problems.
Original comment by samuli.j...@gmail.com
on 30 Oct 2013 at 5:29
I also saw in the logs:
PHP error # 2, is_readable (): open_basedir restriction in effect. File
(/dev/urandom) is not within the allowed path (s):.............
to solve this problem, I add in php_admin_value open_basedir
".......:/dev/urandom:"
Original comment by SerChe...@gmail.com
on 30 Oct 2013 at 5:29
There are inserts in "user_auth" table in MySQL, just in case tho, i deleted
them and ran your script, the results are the same, still unable to log in.
Original comment by Logic...@gmail.com
on 30 Oct 2013 at 8:14
Ok, i got something, it seems to be like this:
I make your insert into the "user_auth" table and whenever i log in with a
user, it disappears from the "user"auth" table for some weird reason.
I noticed this when i saw some fields were missing from user_auth table after
some time, i wondered what caused them, i noticed they disappear every time
after a user tries to log in and gets the error.
So in short: Trying to log into Mollify makes the corresponding user_id entry
disappear from "user_auth" table. For example my admin user_id is 20 and every
time i try to log in with it, it disappears from the table. Adding it back wont
make difference, because it goes away again after trying to log in.
Original comment by Logic...@gmail.com
on 30 Oct 2013 at 8:25
Strange... Would it be possible for you to enable the debug logging (add
"debug"=>TRUE in configuration.php, clear the PHP log, rerun the script and
then try logging in. And then get me everything there is in the log. That way I
could see what's going on with the auth_table.
Original comment by samuli.j...@gmail.com
on 30 Oct 2013 at 8:30
This error occurs first when i run your script and all the rows in the table
"user_auth" are there (user still can't log in):
MOLLIFY ERROR: PHP error #2, is_readable(): open_basedir restriction in effect.
File(/dev/urandom) is not within the allowed path(s):
(OPEN_BASEDIR_DIRECTORY_LIST)
(PATH_TO_MOLLIFY\backend\vendor\phpass\PasswordHash.php:51)
{0:{function:globalErrorHandler, args:{0:2, 1:is_readable(): open_basedir
restriction in effect. File(/dev/urandom) is not within the allowed path(s):
(OPEN_BASEDIR_DIRECTORY_LIST),
2:PATH_TO_MOLLIFY\backend\vendor\phpass\PasswordHash.php, 3:51, 4:{count:16,
output:}}}, 1:{file:PATH_TO_MOLLIFY\backend\vendor\phpass\PasswordHash.php,
line:51, function:is_readable, args:{0:/dev/urandom}},
2:{file:PATH_TO_MOLLIFY\backend\vendor\phpass\PasswordHash.php, line:213,
function:get_random_bytes, class:PasswordHash, object:PasswordHash, type:->,
args:{0:16}},
3:{file:PATH_TO_MOLLIFY\backend\include\auth\PasswordHash.class.php, line:25,
function:HashPassword, class:PasswordHash, object:PasswordHash, type:->,
args:{0:MOLLIFY_SERVER_SALTUSER_PASSWORD_PLAINTEXT5270c5809f4621.29438657}},
4:{file:PATH_TO_MOLLIFY\backend\include\configuration\ConfigurationDao.class.php
, line:78, function:createHash, class:Mollify_PasswordHash,
object:Mollify_PasswordHash, type:->, args:{0:USER_PASSWORD_PLAINTEXT}},
5:{file:PATH_TO_MOLLIFY\backend\include\auth\AuthenticatorPW.class.php,
line:26, function:storeUserAuth, class:ConfigurationDao,
object:ConfigurationDao, type:->, args:{0:25, 1:USERNAME_PLAINTEXT, 2:,
3:USER_PASSWORD_PLAINTEXT}},
6:{file:PATH_TO_MOLLIFY\backend\include\Authentication.class.php, line:136,
function:authenticate, class:Mollify_Authenticator_PW,
object:Mollify_Authenticator_PW, type:->, args:{0:{id:25,
name:USERNAME_PLAINTEXT, lang:, email:USER_EMAIL_PLAINTEXT},
1:USER_PASSWORD_PLAINTEXT, 2:{user_id:25, type:, hash:-, salt:-}}},
7:{file:PATH_TO_MOLLIFY\backend\include\Authentication.class.php, line:114,
function:auth, class:Authentication, object:Authentication, type:->,
args:{0:{id:25, name:USERNAME_PLAINTEXT, lang:, email:USER_EMAIL_PLAINTEXT},
1:{user_id:25, type:, hash:-, salt:-}, 2:USER_PASSWORD_PLAINTEXT}},
8:{file:PATH_TO_MOLLIFY\backend\include\services\SessionServices.class.php,
line:59, function:login, class:Authentication, object:Authentication, type:->,
args:{0:USERNAME_PLAINTEXT, 1:USER_PASSWORD_PLAINTEXT}},
9:{file:PATH_TO_MOLLIFY\backend\include\services\SessionServices.class.php,
line:51, function:authenticate, class:SessionServices, object:SessionServices,
type:->, args:{}},
10:{file:PATH_TO_MOLLIFY\backend\include\services\ServicesBase.class.php,
line:59, function:processPost, class:SessionServices, object:SessionServices,
type:->, args:{}},
11:{file:PATH_TO_MOLLIFY\backend\include\MollifyBackend.class.php, line:82,
function:processRequest, class:ServicesBase, object:SessionServices, type:->,
args:{}}, 12:{file:PATH_TO_MOLLIFY\backend\r.php, line:63,
function:processRequest, class:MollifyBackend, object:MollifyBackend, type:->,
args:{0:Request}}}
This error occurs second when the user row disappeared after the first try of
the log in (user still can't log in):
MOLLIFY ERROR: ServiceException: INVALID_CONFIGURATION=User auth info missing
25 (this nr 25 here is the user id)
MOLLIFY ERROR:
{0:{file:PATH_TO_MOLLIFY\backend\include\Authentication.class.php, line:114,
function:auth, class:Authentication, type:->, args:{0:{id:25,
name:USERNAME_PLAINTEXT, lang:, email:USER_EMAIL_PLAINTEXT}, 1:,
2:USER_PASSWORD_PLAINTEXT}},
1:{file:PATH_TO_MOLLIFY\backend\include\services\SessionServices.class.php,
line:59, function:login, class:Authentication, type:->,
args:{0:USERNAME_PLAINTEXT, 1:USER_PASSWORD_PLAINTEXT}},
2:{file:PATH_TO_MOLLIFY\backend\include\services\SessionServices.class.php,
line:51, function:authenticate, class:SessionServices, type:->, args:{}},
3:{file:PATH_TO_MOLLIFY\backend\include\services\ServicesBase.class.php,
line:59, function:processPost, class:SessionServices, type:->, args:{}},
4:{file:PATH_TO_MOLLIFY\backend\include\MollifyBackend.class.php, line:82,
function:processRequest, class:ServicesBase, type:->, args:{}},
5:{file:PATH_TO_MOLLIFY\backend\r.php, line:63, function:processRequest,
class:MollifyBackend, type:->, args:{0:Request}}}
The second error just keeps repeating itself and the row in "user_auth" table
is gone.
Original comment by Logic...@gmail.com
on 30 Oct 2013 at 8:47
I got the same error after upgrading to the newest version. The user_auth row
is gone after i try to login
Original comment by schnett...@gmail.com
on 30 Oct 2013 at 9:01
So you have the same thing as in:
https://code.google.com/p/mollify/issues/detail?id=485
Can you try adding the htaccess entry and see if it helps. I need to make a
correction so that there is a db transaction that prevents losing the old row
if creating new one fails.
Original comment by samuli.j...@gmail.com
on 30 Oct 2013 at 9:06
To summarize, adding this to htaccess should fix the hash generator:
<DirectoryMatch "/yoursite/here/">
php_admin_value open_basedir "/dev/urandom"
</DirectoryMatch>
Latest version should already have the warning suppression (@-sign in
include/vendor/phpass/PasswordHash.class line 51), so I guess it won't help
here.
I chose PHPass because it seemed like a password hash generator that should
work on all servers, many other hash generator seem to require PHP server
version greater than 5.3, which many service providers not offer.
Original comment by samuli.j...@gmail.com
on 30 Oct 2013 at 9:13
I never had .htaccess on Mollify and really don't want to give any extra
permissions to Mollify script for security reasons to be able to run .htaccess
commands, this was the entire reason i chose Mollify in the first place, no
extra permissions, all the script files could be read only when in working
order etc.
I tried the DirectoryMatch, but it didn't help, reverting back to Latest oldest
Mollify and using it as long as i can.
Original comment by Logic...@gmail.com
on 30 Oct 2013 at 9:28
It's not a script or a command. That htaccess simply says that it is ok to
access /dev/urandom/ in your server. I just had no problems with this myself.
I really don't know why they have chosen to get random data from /dev/urandom,
and did not see this coming. Perhaps PHP random generator is not good enough, I
only know that PHPPass is widely used and suggested lib for password hashing. I
have to see what options there are at the moment, can I remove the urandom
thing or should I use some other lib, don't know...
But you do what you do, if older version suits you, go ahead.
Original comment by samuli.j...@gmail.com
on 30 Oct 2013 at 9:34
I have a windows server, I'm pretty sure i don't have /dev/urandom
Original comment by Logic...@gmail.com
on 30 Oct 2013 at 9:41
Yes I see that, I'm pretty surprised (disappointed) they did not think of that
kind of thing. I'll fix this somehow.
Original comment by samuli.j...@gmail.com
on 30 Oct 2013 at 9:45
I made a new release with attempted error recovery (not sure if it works or not
since my environment does not have this restriction), and as a failsafe option
there is a setting that disables the entire /dev/urandom access:
$CONFIGURATION = array(
"no_udev_random" => TRUE,
...
);
If you haven't given up on this, let me know if you try it.
Original comment by samuli.j...@gmail.com
on 30 Oct 2013 at 11:52
I tried your fix but it doesn't works for me ("no_udev_random" => TRUE is a
part of my cinfiguration)
Error.log contains:
RESPONSE error {0:999, 1:Unexpected server error, 2:500} PHP error #2,
is_readable(): open_basedir restriction in effect. File(/dev/urandom) is not
within the allowed path(s):
Original comment by schnett...@gmail.com
on 30 Oct 2013 at 12:16
Oh crap, made a little typo, the value is used in a negative way.
Could you try with attached class, goes into
"backend/vendor/phpass/PasswordHash.class" (or simply using the configuration
value FALSE)
Original comment by samuli.j...@gmail.com
on 30 Oct 2013 at 12:24
Attachments:
A "False" let me login now! Thanks
Original comment by schnett...@gmail.com
on 30 Oct 2013 at 12:46
Actually he is right, i tried with both TRUE and FALSE, they work both ways
when "user_auth" tables are completely cleared out. I don't think it should
work that way either, even tho it's fine for me, i currently left the
"no_udev_random" to FALSE.
Let's say us, windows users, or whoever else needs to disable the udev_random,
does it make our configuration in some way weaker? or what exactly happens when
the udev_random is disabled?
Original comment by Logic...@gmail.com
on 30 Oct 2013 at 12:56
As it's working now and hopefully disabling/enabling udev random option does
not bring out any security shortcomings then i should mention that, guessing it
is related with this issue: "email_login" => TRUE, does not work, it said
username or password incorrect.
Also, it seems setting Debug in Mollify configuration to false, does not work,
it's still in debug mode and writes all the stuff to PHP Error Log.
Why I'm saying it is that it seems to be related with the thing that no matter
what you put in "no_udev_random", TRUE or FALSE, it still works.
Just seems a bit weird.
Original comment by Logic...@gmail.com
on 30 Oct 2013 at 1:09
Just uploaded a new version 2.2.5 that has the option now turned the other way,
the it was supposed. It also adds some debug logging to verify what it actually
does. So if you update, be sure to turn the value to TRUE.
With this build, I tested following things:
- setting "no_udev_random" to FALSE (or not setting it all), logs verified it
accessed /dev/urandom
- setting "no_udev_random" to TRUE, logs verified that it skipped this and used
the fallback method
- setting "email_login" to FALSE did not let user login with email
- setting "email_login" to TRUE did let user login with email
- setting "debug" to FALSE did not generate debug log
- setting "debug" to TRUE did generate debug log
So if these settings don't work, make sure to check there is no syntax error in
the configuration.php, and that you are not setting the values more than once.
And note that all of these are backend settings (just in case you put some of
these into client init).
For the question about whether not using /dev/urandom is less secure, I don't
think there is much difference. The library itself had the fallback option to
generate random bytes without /dev/urandom, it just did not handle it if the
/dev/urandom was not accessible.
And sorry for all the hassle with this, I try to do my best to fix these
(perhaps too fast), it's just impossible to know how different environments
operate. The PHPass library really is widely suggested solution to be good and
portable, I wonder this did not pop up in any of the discussions.
Original comment by samuli.j...@gmail.com
on 30 Oct 2013 at 1:57
Issue 485 has been merged into this issue.
Original comment by samuli.j...@gmail.com
on 30 Oct 2013 at 1:57
And oh yes, the random generator is not used on regular login, only when new
passwords are hashed and stored. That's why changing the "no_udev_random" value
does not have difference on regular login, only in following cases:
- user resets password
- user changes password
- after updating to 2.2.x and user logs in for the first time (when the hash is
missing and it is generated automatically)
Original comment by samuli.j...@gmail.com
on 30 Oct 2013 at 2:18
I wiped the rows at "user_auth" table just to test it, since with previous
version it added the hashes etc correctly.
With "no_udev_random" TRUE or FALSE, i couldn't log in in both cases. PHP Error
Log only says that there is that open_basedir restriction again. This time tho,
no rows were deleted from the database, just nothing got added there.
Original comment by Logic...@gmail.com
on 30 Oct 2013 at 2:32
I should add that the error originates from:
\backend\vendor\phpass\PasswordHash.php:78 <- at line 78
Original comment by Logic...@gmail.com
on 30 Oct 2013 at 2:38
[deleted comment]
Ok, i replaced the entire PasswordHash.php FROM the OLD Mollify to the newest
version of Mollify and now it DID let me log in and added correct data to
database etc. Everything else was from the new Mollify installation so whatever
is wrong, originates from PasswordHash.php
Original comment by Logic...@gmail.com
on 30 Oct 2013 at 2:53
Could I see your configuration.php, because this really does not make sense.
If you have the latest vendor/phpass/PasswordHash.class and debug => TRUE, you
should have following thing in log every time hash is generated:
/dev/urandom: 0
or
/dev/urandom: 1
Where 0 means /dev/urandom is skipped. And if you have value 1, it is followed
by log entry "Trying /dev/urandom".
And the line 78 you refer to, is exactly the line this setting skips when you
have following line in configuration.php:
"no_udev_random" => TRUE,
note that it is not string but boolean (also in debug setting).
And if you want to "reset" user auth, you must set user_auth table to have "-"
for both hash and salt. This is the indicator for "hash does not exist yet, use
the old pw and create it the hash if the old pw matches".
Original comment by samuli.j...@gmail.com
on 30 Oct 2013 at 3:06
<?php
$CONFIGURATION = array(
"db" => array(
"type" => "mysql",
"host" => "127.0.0.1",
"database" => "DATABASE",
"user" => "USERNAME",
"password" => "PASSWORD",
"table_prefix" => "mollify_",
"charset" => "utf8", // optional
"no_udev_random" => TRUE,
),
"settings" => array(
"timezone" => "Europe/Tallinn",
"debug" => TRUE,
"enable_descriptions" => FALSE,
"enable_folder_actions" => TRUE,
"enable_descriptions" => FALSE,
"enable_retrieve_url" => FALSE,
"url_retriever_class" => "UrlRetriever.class.php",
"convert_filenames" => "UTF-8",
"enable_file_upload_progress" => TRUE,
"host_public_address" => "URL",
"enable_mail_notification" => TRUE,
"mail_notificator_class" => "mail/MailNotificator.class.php",
"mail_notification_from" => "EMAIL",
"enable_zip_download" => TRUE,
"zipper" => "ziparchive",
"email_login" => TRUE,
"enable_thumbnails" => TRUE,
),
"plugins" => array(
"LostPassword" => array(),
"ItemDetails" => array(),
"Archiver" => array(),
"Share" => array(),
"FileViewerEditor" => array(
"viewers" => array(
"Image" => array("gif", "png", "jpg", "jpeg", "bmp"),
"Google" => array("pdf", "tiff", "doc"),
"TextFile" => array("txt", "js", "css", "xml", "html", "xhtml", "py", "c", "cpp", "as3", "sh", "java", "sql", "php"),
"JPlayer" => array("mp3", "ogg"),
"FlowPlayer" => array("mp4", "f4v"),
"Quicktime" => array("mov"),
),
"previewers" => array(
"Image" => array("gif", "png", "jpg", "jpeg"),
),
"editors" => array(
"TextFile" => array("txt", "js", "css", "xml", "html", "xhtml", "py", "c", "cpp", "as3", "sh", "java", "sql", "php"),
),
),
),
);
?>
Original comment by Logic...@gmail.com
on 30 Oct 2013 at 3:09
Yes i had the "-" symbols in the database, i actually just used your script you
suggested before @ mysql.
The only thing i have in my PHP Error Log is (Debug is set to TRUE):
MOLLIFY ERROR: PHP error #2, is_readable(): open_basedir restriction in
effect...
But why does it work with the version before PasswordHash.php and not with the
new one?
Original comment by Logic...@gmail.com
on 30 Oct 2013 at 3:13
No wonder, you do have wrong $CONFIGURATION structure.
It should be like this:
$CONFIGURATION = array(
"db" => array(
"type" => "mysql",
"host" => "127.0.0.1",
"database" => "DATABASE",
"user" => "USERNAME",
"password" => "PASSWORD",
"table_prefix" => "mollify_",
"charset" => "utf8", // optional
),
"no_udev_random" => TRUE,
"timezone" => "Europe/Tallinn",
"debug" => TRUE,
"enable_descriptions" => FALSE,
"enable_folder_actions" => TRUE,
"enable_descriptions" => FALSE,
"enable_retrieve_url" => FALSE,
"url_retriever_class" => "UrlRetriever.class.php",
"convert_filenames" => "UTF-8",
"enable_file_upload_progress" => TRUE,
"host_public_address" => "URL",
"enable_mail_notification" => TRUE,
"mail_notificator_class" => "mail/MailNotificator.class.php",
"mail_notification_from" => "EMAIL",
"enable_zip_download" => TRUE,
"zipper" => "ziparchive",
"email_login" => TRUE,
"enable_thumbnails" => TRUE,
"plugins" => array(
"LostPassword" => array(),
"ItemDetails" => array(),
"Archiver" => array(),
and so on.
So there is no key "settings", the all settings are in the array itself. And
you had the "no_udev_random" inside "db".
Original comment by samuli.j...@gmail.com
on 30 Oct 2013 at 3:30
Sorry for the late response, i was at work, but yes, it seems to be working
correctly now. Sorry for causing all the hassle, at least something good came
out of it by getting it compatible with Windows hosts.
Thank you, yet again.
Original comment by Logic...@gmail.com
on 31 Oct 2013 at 6:36
Sure, it was indeed good result, sorry that you had to be the "crash test
dummy" with windows server. Have to add this FAQ etc.
Original comment by samuli.j...@gmail.com
on 1 Nov 2013 at 8:08
[deleted comment]
Actually i don't mind at all, when I'm not working or anything i can do it
freely, the only annoying part is that we have to communicate through this here
and it's slow, some sort of IM would be better. So if you need to test
something and i can avoid my silly mistakes, let me know.
Original comment by Logic...@gmail.com
on 1 Nov 2013 at 2:10
Original issue reported on code.google.com by
Logic...@gmail.com
on 29 Oct 2013 at 7:24