Jump to content
[MUST READ] Forum Rules ×

MOFHY Lite || MOFHY Feature Request


Recommended Posts

6 hours ago, Shen Wei said:

Issue fixed according to your guidelines

Good to here.

I noticed the having was changed from SHA-1 to SHA-256 (which is a good thing!)

However this means that if you already have clients that signed up with your MOPHY-lite, their password would no longer work, correct?

 

5 hours ago, PlanetCloud said:

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

While the issue gets fixed, do you think it would be a good idea to use directory privacy to just prevent access to /admin in general?

Edited by User51
Link to comment
Share on other sites

  • Replies 347
  • Created
  • Last Reply

Top Posters In This Topic

57 minutes ago, User51 said:

Good to here.

I noticed the having was changed from SHA-1 to SHA-256 (which is a good thing!)

However this means that if you already have clients that signed up with your MOPHY-lite, their password would no longer work, correct!

Yep, it would no longer work.

Quote

While the issue gets fixed, do you think it would be a good idea to use directory privacy to just prevent access to /admin in general?

This is also a good idea.

Link to comment
Share on other sites

  • 2 weeks later...
On 1/21/2022 at 2:51 AM, PlanetCloud said:

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.

Correct me if I am wrong (and I probably am), but what would be the difference between brute forcing this and brute forcing a password?

Link to comment
Share on other sites

On 2/4/2022 at 8:05 AM, User51 said:

Correct me if I am wrong (and I probably am), but what would be the difference between brute forcing this and brute forcing a password?

Firstly if the user uses an easy to guess password, well that's the user's fault and nothing we can do about it I guess...

BUT the problem is that most passwords now are longer than 8 characters thanks to more awareness, and many uses password manager nowadays so it's much more secure. But.. Have you seen the fix implemented? Instead of numbers from 0 to 999 999, we now use this:

substr(str_shuffle('qwertyuioplkjhgfdsazxcvbnm012345789QWERTYUIOPLKJHGFDSAZXCVBNM'),0,8)

If you still don't see the problem, it's the shortness of the string (8 characters only) which can easily be brute forced.

As you can see, fixed string, combined with only 8 characters long, shuffled using non-cryptographically secure [2] function (see reference below, you can crack this by only observing around 600 iterations of it [1]), won't change over time. This means brute forcing the password MIGHT BE HARDER and more based on luck than to just brute force the token itself.

Reference:
[1] https://security.stackexchange.com/questions/235238/security-of-phps-str-shuffle
[2] https://www.php.net/manual/en/function.str-shuffle.php#:~:text=Description ¶&text=This function does not generate,be used for cryptographic purposes.

Link to comment
Share on other sites

This is also an issue that should be filed in the repo I think... 

It's just too much... ?

Also in reference 2, you can see a solution to the problem (though only partial solution, as the full solution is mentioned below):

On 1/21/2022 at 2:51 PM, PlanetCloud said:

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.

With the addition of using cryptographically secure function.

Link to comment
Share on other sites

54 minutes ago, PlanetCloud said:

If you still don't see the problem, it's the shortness of the string (8 characters only) which can easily be brute forced.

This I'm aware of, which is why I personally set the length to 30.

56 minutes ago, PlanetCloud said:

shuffled using non-cryptographically secure [2] function

Ah. That's the major problem I wasn't aware of.

So, let's say that you actually did have a fully random generator. And you had more than 8 characters. This would be more secure, right?

54 minutes ago, PlanetCloud said:

Also in reference 2, you can see a solution to the problem (though only partial solution, as the full solution is mentioned below):

Yes I agree that having an expiring token is a much better idea. I'll wait until a stable release with this is implemented, I'd rather not go messing with the code and the database for now in case a change is actually made.

For now, after making it fully random and making it much longer, this should provide a more-secure alternative to what we previously had (although it is still not a perfect system). This is also fairly easy to implement and remove later, so I don't see any drawbacks to doing this for now.

--

Anyway, thanks alot for the support! My apologies if these questions are stupid, still new(ish) to PHP.

--

Also, thanks to @Shen Weiand everyone else who helped with the client area, for actually developing an open source client area. I've seen some older posts from InfinityFree, who mentions he/she/they would not give away their client area,  as it's their main competitive edge (and I fully understand this.) Shen Wei did this anyway, and made it open souce. Respect for that.

--

Also (again) how come the original topics for Hustal and Mophy-Lite were removed by moderators? I didnt see anything wrong with them.

Link to comment
Share on other sites

2 hours ago, User51 said:

This I'm aware of, which is why I personally set the length to 30.

Ah. That's the major problem I wasn't aware of.

So, let's say that you actually did have a fully random generator. And you had more than 8 characters. This would be more secure, right?

Yes I agree that having an expiring token is a much better idea. I'll wait until a stable release with this is implemented, I'd rather not go messing with the code and the database for now in case a change is actually made.

For now, after making it fully random and making it much longer, this should provide a more-secure alternative to what we previously had (although it is still not a perfect system). This is also fairly easy to implement and remove later, so I don't see any drawbacks to doing this for now.

--

Anyway, thanks alot for the support! My apologies if these questions are stupid, still new(ish) to PHP.

--

Also, thanks to @Shen Weiand everyone else who helped with the client area, for actually developing an open source client area. I've seen some older posts from InfinityFree, who mentions he/she/they would not give away their client area,  as it's their main competitive edge (and I fully understand this.) Shen Wei did this anyway, and made it open souce. Respect for that.

--

Also (again) how come the original topics for Hustal and Mophy-Lite were removed by moderators? I didnt see anything wrong with them.

Well I don't know either why they deleted those topics 

Link to comment
Share on other sites

3 hours ago, User51 said:

Anyway, thanks alot for the support! My apologies if these questions are stupid, still new(ish) to PHP

You're welcome and don't worry. Continue learning and improve.

Quote

So, let's say that you actually did have a fully random generator. And you had more than 8 characters. This would be more secure, right?

Yes, it would be more secure than the current one.

Do note that str_shuffle only SHUFFLES the order of the character. That means it only has a max of n! (where n = number of original characters) possible combinations instead of the ones where the same character is allowed to repeat. I recommend not only do you use 30 characters, but also use cryptographically secure function to generate the key (see reference 2).

3 hours ago, User51 said:

Also, thanks to @Shen Weiand everyone else who helped with the client area, for actually developing an open source client area. I've seen some older posts from InfinityFree, who mentions he/she/they would not give away their client area,  as it's their main competitive edge (and I fully understand this.) Shen Wei did this anyway, and made it open souce. Respect for that.

It is HE, and yes it's the main competitive edge. It's not that easy to make one as nice as his.

Link to comment
Share on other sites

Actually In my project, I have implemented a similar token system. Maybe this would be useful.

Creating and inserting token (64 characters long, and expires in 15 days):

$token = bin2hex(random_bytes(32));
$db->insert('tokens', [
    'user_id' => $user['id'],
    'token' => $token,
    'expires' => time() + config('system.auth.token_expire')
]);

Checking the token:

$token = $db->get('tokens', ['user_id'], [
    'token' => $request['token'],
    'expires[>]' => time(),
]);
if (!$token) {
    throw new AuthError('Token is invalid or expired.');
}

This shows that implementing this is easy and not hard. Just a few lines of code and a fully functional and secure tokening system is implemented.

Do note you may need to write a script that clears the expired tokens. 

Link to comment
Share on other sites

52 minutes ago, User51 said:

Suspension reason

So easy to fix! Just know all api responses!

 

52 minutes ago, User51 said:

Token system

I removed it for royalityfree, basic php knowledge is needed!

 

52 minutes ago, User51 said:

A support system with iFastNet

Is not important, but worth. Check the chat for iFastNet' reply.

Link to comment
Share on other sites

3 hours ago, RoyalityFree said:

Is not important, but worth. Check the chat for iFastNet' reply

I'd say it is worth it, if you run a fairly large host you can't answer a lot of tickets by yourself.

Also, here's the link https://prnt.sc/26v30cl Chat clears often that's why I'm posting it here.

3 hours ago, RoyalityFree said:

I removed it for royalityfree, basic php knowledge is needed!

I mean expiring tokens for log in

Edited by User51
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...