{WIP} [Feedback wanted] Absorbant | Absorbs all the worries of making permissions

General Discussion
1

[size=150]Features and differences[/size][size=90]
The main difference from our web app to basically every other permission manager (including even the flat file of PermissionsEx) is that you don’t have a group and then make the permissions for it, but rather have a list of permissions and then choose which group is allowed to use it. In our opinion this is more natural and probably easier to understand so you don’t risk to miss setting a permission.

Another feature we add is a community database. This means you can import the permissions as other server admins made them so your server is ready in under 5 minutes of “permissioning”. You can also view the history of permission edits and revert changes someone shouldn’t have done.

Absorbant needs to have the Absorbant plugin installed on your server. This is great because it will also work without an SQL connection and you don’t have to share your MySQL password to a third party. All you need is a free, forwarded port on the server. Absorbant will put security on a high priority. Nobody should be able to hack and/or grief your server! The plugin will even read the permissions from your plugins so you have less work with entering every single node. You will get a mail notification whenever you install a new plugin, so you won’t forget to set up the permissions for it [/size]

[size=150]Who are we?[/size]
[size=90]We are @jdf2, @Phase and @momar. It’s a great team and we will get this released as soon as possible. Momar and jdf2 have both created a permissions editor before, but with this one they hope to create the better one out of all![/size]

[size=150]When will it be finished?[/size]
[size=90]The design and user interface is already looking great in our opinion, the next step is to create the backend and the plugin, and of course the security parts. This will take a long time, but we will hopefully release this before christmas.[/size]

[size=150]What will it look like?[/size]
[size=90]To give you a few impressions about what the interface will look like, have a look at some screenshots:





More info will be released over time, but Momar, Phase, and I plan to get more done before we go posting a lot of info about it.[/size]

6 Likes
2

So it is an external site, and you get direct access to the server? I don’t like that.

What I usually do is:

Design some basic permission sets using Bukkit’s permissions.yml:

colony.creative.guest:
  description: Basic guest permissions.
  default: false
  children:
    pc.portal.use.*: true
    coreextras.flyspeed: true
    coreteleport.tpa: true
    ...

colony.creative.builder:
  description: Basic creative permissions.
  default: false
  children:
    permissions.build: true
    colony.creative.guest: true
    ...

colony.worldedit.simple:
  description: Basic worldedit permissions.
  default: false
  children:
    worldedit.help: true
    worldedit.biome.list: true
    ..

    
colony.worldedit.full:
  description: Full worldedit permissions.
  default: false
  children:
    colony.worldedit.simple: true
    worldedit.limit.unrestricted: true
    worldedit.butcher: true
    ...

Then I create a rank (e.g. Builder) using my permission plugin, and assign the permission sets per world
(Builder has colony.worldedit.simple and colony.creative.builder in world BuilderCreativeWorld, and colony.creative.guest in all other worlds)

3

The problem is that if we lead the requests directly to the minecraft server, we can only use self-signed SSL certificates which lead to a warning, so the request has to go through our server to hide the warning from the user. If we’d use end-to-end encryption instead (which is btw much harder to code than setting up a HTTPS connection), the page would be slow as every request has to be sent twice to feed our database.
If the security standards of the finished app are how I want them to be, only people who know your password can change the permissions - not even someone who hacks our database or has access to our files.

4

Well if someone hacked into your db - no encryption will ever help you, then if he can hack he also can decrypt or steal your password.

(Not that i am saying it is a bad idea to do it, though)

And i like the idea if an homepage

5

It depends on the hashing algorithm how long they need to “decrypt” the password… Most algorithms only can be cracked by brute force which takes long enough to notify everyone to change the password and the token, even if he lives on the moon… :wink:

6

This idea is really intriguing to me, and I think that it has some big potential! I do have one question though; will the plugin and/or website be open source? I think the coders of the Sponge community (my self included), would enjoy being able to see how this works. Being able to see commits would also be a nice way for us to see progress.

7

and security of this, makes paranoids like my sleep at night

8

I would say we will have as much of it open source as possible.
Momar may have something else in mind though, but I think he feels the same way.

I will ask him tomorrow. (It’s about 6 in the morning for him I think.)
The plugin’s open source-ness is up to the plugin dev. He has a lot of his stuff open source right now so I bet he will keep this open source to.

EDIT:
Yes the plugin will be open source:

1 Like
9

Sweet, thanks for the info! I understand that some of the backend code may need to remain closed-source for security reasons, but that is something I am willing to overlook if at least some if available :smile:

1 Like
10

Yeah glad you understand that! I couldn’t figure out how to word it so I just wrote “I would say we will have as much of it open source as possible.”

11

keep as much as you think you can open source, as long as I can see all of the plugins source and some of the websites I’m fine, just don’t make me get my decompiler out. :wink:

12

All of the plugin will be open source.
Unless we change how we will be doing connection we have no need to hide any of the plugin’s code.

1 Like
13

Yes, we get “direct access” to the server, but only through the plugin which you install. And the only thing it will do is modify your permissions’ plugin’s permission file.

14

It will be hosted on GitHub, once Sponge comes out. There won’t be anything revolutionary in there, just normal MySQL stuff.

15

I really like the system. It is natural and looks like easy.

Question 1: Is it an entire permission system or just an addon for an existing permission system?

Question 2: For Bukkit, I know only one permission system (zPermissions) supporting permissions per cuboid/land/region (WorldGuard, Residence, Factoid, …). The problem, the developer of zPermissions is not longer in Bukkit, I can convert it to Sponge, but I have already other plugins to convert. Can you implement this feature?

1 Like
16

I think that this could be great as a slick UI wins over manually editing configs wins in my books, but:

If they have access to the server files then they could just modify it to spit out the user’s password or some form of it the next time they log in, no?

so the request has to go through our server to hide the warning from the user

personally, I don’t think that’s 100% justification for a central system when you can get free certs from StartSSL (yes, need your own domain of course) or just run with self-signed.

A good justification to me(!) would be to default to the centrally-hosted service to make setup really easy for most people, but allow the self-hosted option for those that either A. just want that, or B. firewall outbound requests, and want to host it on their LAN (I’ve seen a few servers that do B.)

If the security standards of the finished app are how I want them to be, only people who know your password can change the permissions

I admit that while I’ve got a decent background in security, I’m not really sure how you would do this considering it seems like the configs can be accessed with both the user’s account password and the server token. How do you plan on doing this?

Personally, I think it’s fine to instead focus on making sure that the only way someone could get into your server is through an exploit (e.g. that bash sploit) along with backups/snapshots that users can easily use. With just that, if you consider if your database was stolen, of course passwords should already be safe, but in your sample images the server token says Click to show which sounds like it’s stored either in plaintext or in decryptable form. I would go closer to what Amazon/others do, and only let you generate it once. If you need a new server token, then you have to generate a brand new one. Just like a password, you could just hash the API key.

lastly,

All you need is a free, forwarded port on the server

I’m not sure what other options you’ve considered (if any), but have you considered having the MC server instead pull (and/or be pushed, e.g. websocket) periodically for updates? In my head, it has plenty of trade offs but would avoid the issues with convincing certain people to open inbound ports, perhaps may make it easier for an owner to be clever and use 1 permissions config on multiple MC servers, and can make initial config stupid simple – edit in the server token from website into the plugin’s config and then it’s good to go – no need to give the service your exact IP:port setup.

Of course, all options have their own pros/cons so I’m just curious if you’ve considered all options.

So, my ‘flak’ is just in some of the hand wavy explanations. The service sounds like it could work out well in the end. Not trying to bash, just curious and trying to see some of the decisions from your guys’ view or perhaps create new discussion.

1 Like
17

Now this is the kind of reply I like! Thought out and well said.

Gonna try to answer this the best I can:

If they have access to the server files then they could just modify it to spit out the user’s password or some form of it the next time they log in, no?

Not sure how to answer this as I don’t understand

I admit that while I’ve got a decent background in security, I’m not really sure how you would do this considering it seems like the configs can be accessed with both the user’s account password and the server token. How do you plan on doing this?

The interface can only be accessed by the user’s password. The key is used for the connection between the website and the server. (This might change. See last answer) The plugin will also check to see if the request’s IP is what the webserver’s IP should be. (For added security.) As for your question: Gonna be honest, I don’t know how Momar plans on doing that. I haven’t heard of that. But I bet he does have a plan, gonna ask him as soon as I can. I’m sure he will post here before I can ask though…

I would go closer to what Amazon/others do, and only let you generate it once. If you need a new server token, then you have to generate a brand new one.

That is a great idea! We will more than likely switch to that. (Once again I will run it by Momar as soon as I can)

have you considered having the MC server instead pull (and/or be pushed, e.g. websocket) periodically for updates?

We actually thought about that about an hour ago. We haven’t decided yet as Momar was not in that conversation. (Big time difference) But we will more than likely also do this.

Sorry if this didn’t answer all your questions completely.

18

Instead of using SSL, and bringing up certs why not bypass that step alltogether? For example take some insider info from other games that use different auth schemes. I recommend you look at SRP-6a. It is a secure authentication scheme that works with a username/password, while never sending the password. (For example WoW uses this to generate a session value). You can create a SHA3 (or SHA1 though thats technically insecure) of that session key, and use that as an AES256/AES512 key, and generate a 32 bit IV based on some value (for example an IP). Thus creating a secure AES Encryption system to encrypt the data of all your packets without having to even step into the realm of PKI infrastructure which could cause problems on it’s own. Other than that it seems like a good idea, (shameful self plugin follows) if you need a secure implementation of SHA3/AES My plugin Splash (which will soon support SRP-6a generation) has some examples. (End shameful self plugin). Anyway Good luck if you need any help with the security side let me know! (I do security for a living so although coding isn’t my best trait, security I got). Anyway good luck!

19

I hate timezones… :tired_face:

@Tabinol

  1. It’s an addon for most of the big permission systems
  2. As you are able to add permissions for a specific world, you will also be able to add permissions for a specific cuboid, if the permission system allows.

@Hidendra

  1. That’s the problem… With my knowledge it’s pretty hard to fully encrypt the server so it can’t acccess itself while keeping it easy for the users… :wink:

  2. Not every server owner wants to go through all the steps needed for a certificate and installing it, and not every server owner got a domain.
    Of course it should be “really easy” - if not, you could just go and edit your permission files yourself :smiley:
    We will maybe add a self-hosted option later on, but it’s more work as the database still has to be centralized…

  3. The problem is that the Absorbant server needs the token for requests to the minecraft server. If it’s not stored in plain-text, the user has to enter it every time he logs in…

  4. An idea I got myself is that we could just use ProtocolLib and build upon the minecraft server protocol. This means we can route everything through port 25565.

@LordLambda
We’re all not experts in security… SRP-6a looks good, but as I read, it’s pretty hard to implement it securely, so we probably will stick to an old-school hashing/salting algorithm for storing passwords…
Of course having an SSL connection with a properly signed certificate to the Absorbant server is obligatory, the problem is the connection to the servers. :wink:
When using the minecraft protocol, we’d need some proper encryption here to ensure that the request is immune against (theoretically) possible MITM attacks - we have to think about how to do that properly…

1 Like
20

I’d be willing to help with implementing it securely (it actually isn’t that tough, maybe i’ve just done it a lot, or you can check out this implementation in bouncy castle which you could use as a library). (Also again I’ll probably insert something similar in Splash). And your right your not going to achieve End-To-End encryption. Very few software pieces do, and they are all written in C or similar languages, and the day mc servers implement allowing you to run binaries is a day we will never probably see. Agreed, and honestly I believe using only PKI, or some simple hashing will not be secure against MITM attacks. Take example the leaks that happened on Mineplex. This attack was done through leakage of private developer keys, it can be a problem you can’t always trust a user to keep his keys secret. Because let’s be honest they don’t keep it secret very well (an example of a PGP private key posted openly on pastebin). The truth is the hardest part is considering the stupidest user, and making them the most secure.

2 Likes