MOFHY Lite || MOFHY Feature Request

[User51]

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 January 21, 2022 by User51

[User51]

5 hours ago, PlanetCloud said:

this is also a bad idea

Yeah I know, that's why I said "temporarily" hopefully this can be fixed, if not by Shen Wei then by the community.

 

Edited January 21, 2022 by User51

[PlanetCloud]

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.

[PlanetCloud]

54 minutes ago, User51 said:

Yeah I know, that's why I said "temporarily" hopefully this can be fixed, if not by Shen Wei then by the community.

 

Well, I've proposed a solution. It requires another database tables though but it's not that hard to create one.

[User51]

How would I change all the "keys" in the databases from INT to VARCHAR ? Do I have to reinstall the whole thing?

[TinkerMan]

I would just reinstall. Your customers will have to reset their passwords anyway. 

[User51]

Yes but, wouldn't their whole accounts be reset? The database will be completely cleared...

[PlanetCloud]

5 hours ago, User51 said:

How would I change all the "keys" in the databases from INT to VARCHAR ? Do I have to reinstall the whole thing?

Go to phpMyAdmin -> Select the database and table you want -> Go to Structures -> Change the type -> Save

[User51]

6 minutes ago, PlanetCloud said:

Go to phpMyAdmin -> Select the database and table you want -> Go to Structures -> Change the type -> Save

Oh wow, it's as easy as that ? 

Thanks PlanetCloud!

[PlanetCloud]

2 hours ago, User51 said:

Oh wow, it's as easy as that ? 

Thanks PlanetCloud!

You're welcome!

[User51]

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?

[PlanetCloud]

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.

[PlanetCloud]

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.

[User51]

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.

[Mahtab Hassan]

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 

[PlanetCloud]

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.

[PlanetCloud]

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. 

[TinkerMan]

6 hours ago, PlanetCloud said:

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

Could this just be a PHP function that checks the “expires” time and deletes anything after it?

[PlanetCloud]

9 hours ago, TinkerMan said:

Could this just be a PHP function that checks the “expires” time and deletes anything after it?

Yes. A function, service, script, or cron job. Any that would do an SQL query for all the tokens that have expired and delete them.

[User51]

Some features I find to be missing in MOPHY-lite:

• Suspension reason
• A support system with iFastNet
• Token system

Glad to see development again with MOPHY-lite!

[JaiktDev]

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.

[TinkerMan]

1 hour ago, RoyalityFree said:

Just know all api responses!

That would just be making it way more comply then it needs to be. You only need to parse them, not save them!

[User51]

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 February 13, 2022 by User51

[User51]

Also, SitePro integration would be nice.

[Mahtab Hassan]

MOFHY Lite UI fixes and reactivate account feature comming tomorrow