Jump to content
[MUST READ] Forum Rules ×

MOFHY Lite || MOFHY Feature Request


Recommended Posts

  • Replies 347
  • Created
  • Last Reply

Top Posters In This Topic

Hello, you guys can use the following code to hide the user domain part in the vewssl.php. most face errors due to that, because they copy the whole thing, instead for the domain they have to use the dropdown in the cname section of control panel. Hope it helps ?!

<?php 
$dot = '.';
$find = $dot.$SSLInfo['domain'];
$replace = '';
$from = $Record['0'];
?>

Then use the following code to echo the above variables :-

<?php print_r(str_replace($find,$replace,$from))?>

 

Link to comment
Share on other sites

  • 3 weeks later...

Dear Friends,

Major critical security vulnerabilities has been discovered on MOFHY, including Project HUTSAL, and any other project that expands on them. Please monitor the issues on https://github.com/NXTS-Developers/MOFHY-Lite/issues for more details. (SEE CLOSED ISSUES AS WELL, SOME ARE INCORRECTLY COSED).

image.png

It is not a good idea to use the project until the issues have been fixed.

Thank you, and have a nice day!

Edited by PlanetCloud
Link to comment
Share on other sites

Currently, anyone can access anybody's account on MOPHY-lite by knowing the end-user's "hosting_client_key", which can be easily done by brute forcing numbers 0 through 999,999: https://github.com/NXTS-Developers/MOFHY-Lite/issues/53

However, what if you change the code, so that when the end-user signs up, the "hosting_client_key" doesn't generate numbers 0 through 999,999, but instead uses a combination of numbers and letters? This makes it much harder to brute force.

Or will doing this break something? (My apologies if this is the stupidest idea ever)

While this is probably not the most ideal solution, it is at least a somewhat efficient way of dealing with the problem, until an actual fix is made.

 

Link to comment
Share on other sites

5 hours ago, User51 said:

Currently, anyone can access anybody's account on MOPHY-lite by knowing the end-user's "hosting_client_key", which can be easily done by brute forcing numbers 0 through 999,999: https://github.com/NXTS-Developers/MOFHY-Lite/issues/53

However, what if you change the code, so that when the end-user signs up, the "hosting_client_key" doesn't generate numbers 0 through 999,999, but instead uses a combination of numbers and letters? This makes it much harder to brute force.

Or will doing this break something? (My apologies if this is the stupidest idea ever)

While this is probably not the most ideal solution, it is at least a somewhat efficient way of dealing with the problem, until an actual fix is made.

 

Well it is good idea but there it will need to change database structure 

Link to comment
Share on other sites

5 hours ago, User51 said:

Currently, anyone can access anybody's account on MOPHY-lite by knowing the end-user's "hosting_client_key", which can be easily done by brute forcing numbers 0 through 999,999: https://github.com/NXTS-Developers/MOFHY-Lite/issues/53

However, what if you change the code, so that when the end-user signs up, the "hosting_client_key" doesn't generate numbers 0 through 999,999, but instead uses a combination of numbers and letters? This makes it much harder to brute force.

Or will doing this break something? (My apologies if this is the stupidest idea ever)

While this is probably not the most ideal solution, it is at least a somewhat efficient way of dealing with the problem, until an actual fix is made.

 

Issue fixed according to your guidelines

Link to comment
Share on other sites

Just in case it is missed, I've filed another issue on the original repository:
https://github.com/NXTS-Developers/MOFHY-Lite/issues/60

48 minutes ago, Shen Wei said:

Well it is good idea but there it will need to change database structure 

Not much needed to be changed but this is also a bad idea. Using a fixed/same string/token as a "remember me" token is a super duper bad idea because not only is the string short, it is fixed. That means unchanging for a long time (or even forever) and brute force can still be performed.

The correct way is to use a longer token that expires after a certain time. This way even though a brute-force is launched, it will be useless because the token would've changed after said time. Some site allow 7 days, while others 60 days. It depends on the strength of the token itself.

 

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...