If youâre like me and have run a server before, you know that if one of your admins gets hacked, somehow your account gets hacked or similar, your server is basically screwed and there isnât much you can do until the damage is done, since they like to do it when youâre not on. Thatâs not necessarily true, though.
This isnât your traditional login system
Instead of annoyingly requiring admins to enter a password every time they join, we only check to see if theyâre on an IP that seems suspicious to us. Then we require them to log in before they continue. Also, if somehow they get past the login, the plugin wonât let them give anyone else operator or admin permissions without banning them, since they need to still enter a passphrase before managing the server.
Protective Features
â2factor authenticationâ for /op and player upranks
Automatic banning of compromised administration accounts acting suspiciously.
Monitoring of user IPs to watch for sudden changes in location via geoip and flagging users that have strangely different locations.
Accounts that refuse to verify with the server will be banned and server administration will be notified.
How is this 2FA?
2FA simply means authentication with two factors involved. In this version of 2FA, we check against the players location via GeoIP and then watch for malicious activity (running bad commands!)
HuskySecurity is rather basic at the moment, but if the location check fails it will ask for your password.
Upcoming Features
/verify traveltrust - Temporarily trust this location for up to 3 days after itâs stopped being used.
/verify trust - âPermanentlyâ trust this location, adding it to your trusted locations where you wonât be prompted to verify.
/verify revoketrust - Immediately revoke other trusted locations. This action is logged.
Media
Demonstrational video (Up to date!)
Commands & Permissions
/verify - This is for basically everything in this plugin.
/verify < set/password/setpassword > - Updating your password if you donât like / canât remember it.
huskysecurity.verify This permission is for activating the verification check for a specified user. Use this wisely.
Donate
Support my code addiction, my projects and other random stuff I decide to waste money on to keep my sanity! PayPal
While I like this idea initially, I leave a couple comments (note I think the fact you are making a security oriented plugin is awesome! and I mainly am just grumpy about security, basically please don't take anything personally!)
As Shown Here It looks like your "compromise" detection is /op.
Maybe the admin can specify a list of commands to watch for, with a point based system? e.g. running op makes you 50 points more suspicious, and it requires 100 points to ban? Since this is using location on an geominddb, it might not be best to just auto assume people are bad if they're in a different location (People travel sometimes!).
Side note: Nice job having a decently recent maxminddb. I see these things super out of date all the time.
Seen Here, it looks like every time a player executes a command, they're required to have ServerDefender and be verified.
For having the benefits of not always having to enter your password, it'd be nice if this good also be optional in certain situations? E.g. Maybe it's only required if a certain permission is set?
This Whole File, is basically a "good first try, but really is meeting a minimally viable security setup, and even then it's iffy".
Using a hardcoded salt instead of a random salt per-user. There are tons of articles talking about really what a salt should be. This isn't even a salt, this is what's known as a "pepper" which although useful, doesn't nearly come close to providing the same security benefits as a salt based system. I'll leave the follwoing: Article 1, Article 2, Article 3. However really looking at any reputable source for salts recommend the following basic things:
A salt is randomized.
Each salt is unique per "user".
Stored in a seperate plain text source.
Although your using a work based hash (which is a huge step up from using a fast-hash based algorithm MD5/SHA(1/2/256/512)/etc, PBKDF2 is generally considered "the least viable of these". Some better options might be something like BCrypt, or SCrypt. Both are stronger work based hashes which also are more optimized than PBKDF2 for running on modern day hardware.
It certainly is at the moment, and that is pretty disappointing, really.[quote=âSecurityInsanity, post:5, topic:16277â]
Maybe the admin can specify a list of commands to watch for, with a point based system? e.g. running op makes you 50 points more suspicious, and it requires 100 points to ban?
[/quote]
That certainly is a good idea. I didnât think of a points based system at first, but I definitely planned on allowing server owners to appoint their own commands / do some funky stuff with permissions managers that detects what commands are âadmin levelâ commands and restricts them.
That mightâve been an oversight on my part. This system is supposed to only be for Users who have the permission, and nobody else. Additionally, you arenât required to re-enter your password if your location is âtrustedâ (aka similar location)
I was planning on something like /verify traveltrust that would temporarily trust a location for 3 days after the location is no longer being used. /verify trust would be for permanent trust updates.
I will, for sure, update my code to use a better crypt and actual salting. I used a simple hardcoded salt mostly because I was unsure that it was safe to use individual user salt, butâŚ
the salts certainly will be stored somewhere else, so no worries!
But yeah, at least itâs a hash and I wasnât lazy and went âlol plain text passwordsâ
Finally, thanks for the informative post. Iâll make sure to put up an issue on GitHub with a snippet of this so I remember to do it.
Taking a look, looks like it fixed by whole PBKDF2 complaint, as well as the everytime a command is executed. (I assume the list of commands is just down the pipeline).
The last note Iâll leave is:
Seen Here it seems youâre doing new SecureRandom(), which is usually âgood enoughâ. However itâs recommend to do: SecureRandom.getInstanceStrong(). It should note using a different instance may cause different effects (e.g. wait for a full pool of randomness, instead of re-reading the same pool), but in most cases itâll give you a much better instance.
Can I move this plug-in to the MCBBS forum in China?
I will show the original author and the original page.
If you like, I will send you the link of the web page after the successful removal.
I will not provide other download addresses.
HuskySecurity
This isnât your traditional login system
Protective Features
How is this 2FA?
Upcoming Features
Media
Commands & Permissions
Donate
Download
Questions & Suggestions
