MCGalaxy
MCGalaxy copied to clipboard
UnknownShadow200
IP Ban bypass
Joining with an admin's name blocks the ability to IP Ban the user as the server thinks that that is their name even if they dont log in You can also join with multiple accounts of the same name by changing the case (like Hedwig7s and hedwig7s can join at the same time)
Are you running with name verification disabled? I am unable to reproduce when running when name verification enabled
Furthermore, you should follow this guide so that verify names can be turned on, as it is an essential part of running a server: https://f.classicube.net/topic/1590-how-to-set-up-authentication-for-players-on-betacraft/?tab=comments#comment-8582
Are you running with name verification disabled? I am unable to reproduce when running when name verification enabled
No but it is still an issue Dunno why but xDeathCon wont turn it on
Also I mean same rank OFC a higher rank can ban em
But it makes moderation as an operator annoying as hell I think impersonating somebody with SuperOP and Nobody also does it
my server does have name verification but if there is the option for name verification to be disabled it should be unexploitable (thats what passwords and blocking a 2nd person with the same name are for)
to trigger the glitch 2 people with different ips must connect on the same admin account (same caps or not) Then if someone tries to ban em if they have the same rank or lower it blocks it because "Admin has the same IP" even if its the impostors ip
In the above example, operator UnknownShadow is trying to ban the IP that superop UnknownShadow200 failed to login from, so it's behaving as expected (with name verification enabled)
I have made clone detection case insensitive with c5913ad8dd0e5da4de3db953e624518c5e78f625
To properly implement this when name verification is disabled would require some changes (just delaying 'last ip' update until after /pass verification is insufficient, would require adding and tracking a separate 'last authenticated IP' for players)
And I'm not really a fan of spending time implementing that, when it's already made clear to a server owner that running with name verification off is a bad idea as it is insecure and dangerous
In the above example, operator UnknownShadow is trying to ban the IP that superop UnknownShadow200 failed to login from, so it's behaving as expected (with name verification enabled)
I have made clone detection case insensitive with c5913ad
To properly implement this when name verification is disabled would require some changes (just delaying 'last ip' update until after /pass verification is insufficient, would require adding and tracking a separate 'last authenticated IP' for players)
And I'm not really a fan of spending time implementing that, when it's already made clear to a server owner that running with name verification off is a bad idea as it is insecure and dangerous
How would just delaying the last ip change until after /pass be insufficient? If it is because it would make non-admin accounts not update couldn't you do something like this?
(gonna write it in roblox lua)
Added it as an image cause github was messing up my formatting
Dunno why but xDeathCon wont turn it on
Probably it's so they can allow piracy on their server.
bruh
On Tue, 21 Dec 2021 at 15:10, forkiesassds @.***> wrote:
Dunno why but xDeathCon wont turn it on
Probably it's so they can allow piracy on their server.
— Reply to this email directly, view it on GitHub https://github.com/UnknownShadow200/MCGalaxy/issues/673#issuecomment-998810263, or unsubscribe https://github.com/notifications/unsubscribe-auth/AW7NM36W2JQ47ABNNMVFBZLUSCDGJANCNFSM5KPVQCDA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you authored the thread.Message ID: @.***>
How would just delaying the last ip change until after /pass be insufficient?
If a suspicious login attempt was reported for a /pass protected account, staff wouldn't be able to use /info to see the IP that the suspicious login attempt occurred from anymore (last IP)
Couldn't you have a secondary ip stored and when you do /info it gives: "Last IP: 111.222.333" "Last Verified IP: 222.333.444" and instead of blocking an ip ban because the ip matches the last known ip of an admin block it because it matches the last verified ip?
On Wed, 29 Dec 2021, 13:41 UnknownShadow200, @.***> wrote:
How would just delaying the last ip change until after /pass be insufficient?
If a suspicious login attempt was reported for a /pass protected account, staff wouldn't be able to use /info to see the IP that the suspicious login attempt occurred from anymore (last IP)
— Reply to this email directly, view it on GitHub https://github.com/UnknownShadow200/MCGalaxy/issues/673#issuecomment-1002575822, or unsubscribe https://github.com/notifications/unsubscribe-auth/AW7NM3YGGWUX6XEZWGI2LZTUTL6YDANCNFSM5KPVQCDA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you authored the thread.Message ID: @.***>
right, that's what I meant before about would also need a separate 'last authenticated IP'