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

[LordLambda]

Tokens are stored plain-text on the server. Even if they are stolen because of a security flaw, the server admin will delete them from his server because he receives a mail from us telling him so

Why open yourself up to this type of attack, if your host turns on say active directory, or anonymous FTP they can bypass getting the tokens from you, and steal them their-selves. Your relying on the minecraft server host to supply a secure environment, and that’s not something you can always depend on. IMO.

---

Nobody with access to anything of our services can change the tokens stored in the config file. Only the server admin can change them using e.g. FTP.

How are you going to detect a token being changed, and if so warn the user? If you allow the changing of tokens (which you do incase a token gets deleted by a user due to you telling them), how do you check between the “good”, and “bad” changes.

---

Passwords are stored securely salted. Brute force and knowing our code is the only possibility to get the plain passwords from the database.

Your relying on a model of security through obscurity which hasn’t worked for multiple buisnesses, and if you would like I can bring up many sources showing, Security through obscurity is not a secure solution to a problem, someone will always figure it out sooner or later.

---

Only a server with our IP and our HTTPS certificate can send requests to the minecraft server (and the other way around), so if someone got access only to the database and the tokens, he can’t do anything with it.

So how do you keep these certificates secure from outside use? Say you check this on the client side, isn’t it possible to spoof my IP (which is easy to do), and steal your key, again how do you keep your keys secure? How do you keep the checking process secure? It doesn’t show anywhere in your model any hash checking of files, so I could just replace a file, grab your ssl-key (because I have to verify it so at some point I have to have it to check), and then spoof the ip, and control everyone who uses your service.

---

We will not make the platform open source. This would make things more insecure for us and very insecure for people using the self-hosted version without much experience. However, the plugin and its API is open source and you can define the platform server for each token individually. This means anyone can create an app, a different design or a bot for this. Maybe there will also be an API for accessing the community database.

See Above about security through obscurity (Example: WoW’s server software has been entirely remade almost perfectly by just looking at packets, something much more complex than this (heck I’ve done it) it can be done with yours).

---

We are the only ones who have (indirect) access to your permissions. We will not use this possibility as we are nice people and it will spread quickly and nobody would ever use our service again. We put a lot of work into it and all this would be destroyed when we’d break the trust you have in us.

See above.

---

Everything we make more secure from now will open new security flaws. Using existing, proven and easy-to-use standards is definitely more secure than using a custom standard and complicated encryption techniques we don’t know how to use.

Of course there are always new security flaws (you aren’t going to achieve end to end encryption). Using security through obfuscation is a proven way of getting your code broken easily. You have no checking to make sure (that you’ve mentioned) about client side verification. Why re-invent the wheel by implementing custom encryption (btw Encryption is an extremely hard math problem, and creating an encryption scheme entirely from scratch will most likely be littered with bugs (plug the client will have to perform the encryption to send to the server, or decrypt at some time, and bugs can be found there)). I admit most other HTTP API’s are horrid. Instead of only getting a tiny bit better (if even that), lets step leaps and bounds. I also have mentioned just a few bugs off the top of my head, though give me a day, and i’ll think of more. Such as the certificate hijacking, and ip-spoofing, invalid security of certs, etc. Without seeing any code. That’s a problem.

[Dad_Yoshi]

I’d really like the ability to get a ‘permissions list’ so I can apply them to my DB myself. Something along the lines of a file with the contents being:

–Blue plugin
blue.admin false
blue.user true
blue.changecolor true
–Red plugin
red.use true
–Orange plugin
orange.teleport false
orange.godmode false
orange.treechop true

and so on. Also, please do not give permissions as blah.* for ‘all access’ - list all permission nodes separately.

[momar]

So, let me just tear your post to pieces, but this is the last time I’ll do this:

“if your host turns on say active directory, or anonymous FTP” then I’d probably punch him in his face, and not just for those dumb Absorbant keys. It’s an argument like “If you’ve got someone in the team gives his password to everybody, everybody has access.”, and abolutely hilarious (but right, of course)…

“How are you going to detect a token being changed, and if so warn the user?” The token can only be changed in the config. How the admin secures his plugin folder is his thing, but I wouldn’t suggest putting such a folder with plain-text MySQL passwords into /var/www… Tokens can be regenerated, and then the admin has to change them via his access to the plugins folder.

“Your relying on a model of security through obscurity” Since when is hashing and salting a password “security through obscurity”? Nobody can lookup the passwords in a rainbow table and if he doesn’t know our code, brute-forcing would take ages, that’s the only reason…

“So how do you keep these certificates secure from outside use?” Really man? It’s a HTTPS certificate - we’re doing it the same way every blog in the whole internet does it? How would you change a request, especially if the plugin checks the certificate fingerprint?

“See Above about security through obscurity” - if we use a salted password hash, the only reason why we make it obscure is to make it harder to brute-force it when the database is hacked. Salted hashes are commonly used and as far as I can see considered secure.

“Such as the certificate hijacking, and ip-spoofing, invalid security of certs, etc.”
You are just telling me that basically every HTTPS page is completely insecure, independent of the hosting company, the certificate authority, the server itself and the users. Could you then please tell me why you are not a billionaire yet?

---

I’m sorry, but (without wanting to offend you) your answers seem to be based mostly on opinions and seem to contain examples made up of thin air (the first example is just hilarious). Also, I highly doubt that someone with your knowledge needs to be a griefer.

BTW: I learned so much about security today by googling everything you and Hidendra
posted, really - thank you very much for that.

---

@Dad_Yoshi
I don’t know exactly what you mean, but you can create a virtual server (flat-file instead of server connection) and export the permissions to a plain text file containing comments of your choice. There is a node blah.* (and even *) in the list, but it will warn you that it could lead to strange behaviour if it contains many permissions.

[LordLambda]

then I’d probably punch him in his face, and not just for those dumb Absorbant keys. It’s an argument like “If you’ve got someone in the team gives his password to everybody, everybody has access.”, and abolutely hilarious (but right, of course)…

Wait where are the tokens kept, how are they retrived. Techinically a modified plugin jar since you don’t do any verification on the plugin can leak this token decrypted value, also I’ve seen no talk about a custom SecurityManager through java so therefore I can just access tha Value. You have to understand the way your own system works.

---

The token can only be changed in the config. How the admin secures his plugin folder is his thing, but I wouldn’t suggest putting such a folder with plain-text MySQL passwords into /var/www… Tokens can be regenerated, and then the admin has to change them via his access to the plugins folder.

Is there any auth on the token change, or can I simply create a rogue plugin hijack the key, hijack the token/generate my own, and change all the config options. Because again no authentication on the client.

---

Since when is hashing and salting a password “security through obscurity”? Nobody can lookup the passwords in a rainbow table and if he doesn’t know our code, brute-forcing would take ages, that’s the only reason…

I Think I’m confused here where are the salted password hashes kept? I think I got confused there.

---

Really man? It’s a HTTPS certificate - we’re doing it the same way every blog in the whole internet does it? How would you change a request, especially if the plugin checks the certificate fingerprint?

Your not working with a standard HTTP client web interface here (which is written in C++ and can have secure values). Because your server will have a private key in which to recieve values correct? How do you keep this private key secure? Without your private key insecure i hope you realize the security vulnerabilities here.

---

You are just telling me that basically every HTTPS page is completely insecure, independent of the hosting company, the certificate authority, the server itself and the users. Could you then please tell me why you are not a billionaire yet?

No I’m saying you dont show any security of a private key. Your connection from Client-> Server is completley fine, I’ve never contested that (though I do feel I’m confused on which values are where, so i’m going to reread this). Your Server->Client I feel is insecure because the private key I’ve seen almost no protection client side of it’s private key for the server to send data to the client.

---

Most of my examples I feel where based off of some values where I thought were on the MC server not on your end. (Example the Active Directories now seeing that isn’t true i admit you shouldn’t worry about that). My opinions are based off of these false values though most of them still hold true. Such as the insecure private key kept client side, I feel there is a miscommunication between us, and That is both our faults though i feel is more mine. Of course anytime you need to learn anything about security lemme know (It’s what I do for a living afterall).

[Hidendra]

Mineplex is not an extraordinary one as it happened on multiple servers, and force everyone to regenerate they got their fame and moved on.

I’m not very familiar with exactly what happened to Mineplex, and have only read a little bit, but from what I’ve gathered a developer’s private key was somehow obtained and so they got access to the github repo along with access to the servers themselves (SSH?)?

Is that correct?

If so, that does still sound quite extraordinary to me. If someone was able to steal my private key (which requires both the key’s password and access to my PC), then I would be partly to blame myself for allowing someone to access my PC. There is no way I would expect any services I use the key for to then make it incredibly inconvenient to use those services.

Github itself is a nice example actually: after the Rails exploit in 2012 they did the following:

- Adding a new SSH key will now prompt for your password
- We will now email you any time a new SSH key is added to your account
- You now have access to a log of account changes in your Account Settings page

Note the 2nd & 3rd lines. Any changes security related now immediately sends you an email. They didn’t instead make authentication incredibly inconvenient. They do offer 2FA, which to me is even better if I’m physically holding the only device that can authenticate the second part.

With PKI you have to force smart users. Let’s be honest in any setting there will always be an overwhelming amount of people doing utterly stupid shit. It’s just human nature, with only using PKI we cannot protect the stupid people who give developers good ratings.

We’re only talking about a token, key, whatever being stored alongside the MC server. Attempting to make it so stupid-proof that users must enter their credentials every time their server starts will only greatly annoy people who can’t do that e.g. GSP customers that don’t have that kind of console access, scripted restarts, and so on.

On startup the plugin reads these, asks the user for a username/password. It then attempts SRP-6a if the attempt is successful it than securely asks for the token.

Mentioned a bit above, but I did consider this as well, but admittedly did not really consider it much more than thinking it over as it’s asking a lot from certain users. IMO no plugin should ever expect to be able to use System.in because (as mentioned above) not everyone that would benefit from this would even be able to access System.in. Should we blame GSPs for not providing that, and also blame server admins who want to automate things? Personally, I think not.

(btw, would you attempt to prevent access or modifications to System.in too so that a rogue plugin can’t lift it from there?)

SRP-6a has a built in verification scheme. Both sides generate a session key without ever sending the password, and then these session keys are checked both server side, and client side.

Sorry, that was a bad quote on my part, and now that I re-read it I was more pulling at straws for that sentence (by verification, I meant there would still be some DB IO, but of course it would likely not be as much depending on what the alternative is.)

Your right it isn’t the fault of the cert, but the cert relies on a trust relationship that the person using the cert is only people who are supposed too.

Indeed! If I had to choose between a website that showed me a verified green lock symbol versus one that claims that they use secure authentication on top of regular HTTP, I would choose the verified green lock symbol.

and you shouldn’t entirely discount HWID, it could be a semi-decent (although there are better alternatives I admit)

As long as it’s not the only thing being used, then I can agree on it being semi-decent, considering multiple servers on the same machine could resolve to the same HWID.

The thread is getting a little theoretical, so if you tell us any specific possible attack that […]

I agree, I’m certainly not helping by dragging out the above discussion, so I’ll stop it here as my opinion should be fairly clear by now.

[momar]

First of all, I also really think there’s a huge communication issue, mainly caused by the word “server” which has two meanings here. Let’s just say, the Minecraft server is called “the Sponge”, and our server is called “the Absorbant”

So, if you can make a malicious/modified plugin and get it on the Sponge, why would you need Absorbant? You have access to setOp then, you can disable NoCheat, you can even stop the Sponge and delete all backups! I think that’s not the topic here…
If you got a hijacked key, you’d have to get our HTTPS cert, spoof our IP successfully and make sure the Sponge connects to your server instead of Absorbantto make it work. You can’t import existing keys into the Absorbant account.

The password hash is stored in the Absorbant database, for authentication purpose only.

If you refer to “client” as the Sponge, we’ll probably handle it with WebSockets over HTTPS to get around that. When routing everything through MC, encryption would be a problem of course…
If you refer to “client” as the User, then he just requests our HTTPS site, which I think is also encrypted both ways…
So, the private key for SSL is (of course) only stored on Absorbant, and nowhere else.

If I understood anything wrong, I’m sorry

[LordLambda]

True I feel we just need to get a set of communication issue.
First @Hidendra

[quote]- We will now email you any time a new SSH key is added to your account

• You now have access to a log of account changes in your Account Settings page
  [/quote]
  If you implement a full blown SMTP through a Java that would be interesting.

---

Yes they did gain access to the private keys, and the problem is users don’t keep their data secure. While you may be completely secure many users are not, and it’s good to study them.

---

We’re only talking about a token, key, whatever being stored alongside the MC server. Attempting to make it so stupid-proof that users must enter their credentials every time their server starts will only greatly annoy people who can’t do that e.g. GSP customers that don’t have that kind of console access, scripted restarts, and so on.

Why not allow authentication through commands, or an auto password type authentication implemented inside a forge client? Admit it might be a bit limited, but theoretically it could happen, and you could take a infrastructure where you put data on the user, I just personally prefer keeping the users be able to do whatever they want.

---

Mentioned a bit above, but I did consider this as well, but admittedly did not really consider it much more than thinking it over as it’s asking a lot from certain users. IMO no plugin should ever expect to be able to use System.in because (as mentioned above) not everyone that would benefit from this would even be able to access System.in. Should we blame GSPs for not providing that, and also blame server admins who want to automate things? Personally, I think not.

(btw, would you attempt to prevent access or modifications to System.in too so that a rogue plugin can’t lift it from there?)

Again as formentioned you could do this through a custom Security Manager, and could theoretically be built into Absorbant itself.

---

Sorry, that was a bad quote on my part, and now that I re-read it I was more pulling at straws for that sentence (by verification, I meant there would still be some DB IO, but of course it would likely not be as much depending on what the alternative is.)

Well with SRP-6a data you can pull DB data securely in memory, and then check a list resulting in much less DB IO which is always nice.

---

Indeed! If I had to choose between a website that showed me a verified green lock symbol versus one that claims that they use secure authentication on top of regular HTTP, I would choose the verified green lock symbol.

Indeed of course! Yea It was just more of an idea to securely get that key. Nothing more, like I said I’m not trying to trash or anything like that just give ideas and formulate based on what I understand.

---

[quote]
As long as it’s not the only thing being used, then I can agree on it being semi-decent, considering multiple servers on the same machine could resolve to the same HWID.[/quote]
Agreed HWID is not the best method, and some other method should be put in place. Again just ideas.

---

---

@momar Now for you!
Alright glad we calmed down, and alright sounds good. Well the attempt is to not get a modified plugin on sponge, but the idea I was thinking of the attack could be this. Set up a local server -> Add in Absorbant, have it generate keys, and such -> Modify the plugin through ASM, or something to pull some public keys, and slow down other services which could have other conflicted ideas. Of course more, and more it again comes down to your server. I’m still re-reading the conversation so I’m not going to blatantly state anything. Though ProtocolLib doesn’t support SSL does it, and I thought you were implementing a custom packet structure, not just connecting as through a webclient and posting/getting. So I’ll reread a bit, and edit this accordingly.

[LordLambda]

So after taking more than adequate time, I feel like I’ve finally got a full understanding of what I didn’t before (which server is which, and exactly what you want to do). My suggestion now is OAuth. With OAuth you could create a nifty little API for other plugins, and have it be secure.

[MatthewEnderle]

So Im led to believe that the devs like my site and wanted to make their own for profit. Permissions Manager App

[momar]

Well, if you think so, let me clear that up. The thing is that our idea and even a lot of the design was there long (more than a month) before you even announced your page, if you look at our old thread. But I’m okay with competition, and I’m pretty sure there are many people who like your app, and there are many people who like Absorbant, so hopefully we can co-exist nicely
If you think we’re going to make profit with this, you are probably wrong; we’d be glad if we could even finance the server with the ad revenue. We’re doing it for fun, to help us and other server admins, and we hope to learn many things by creating this.

[MatthewEnderle]

I dont mean to start an argument but I started on August 12th. It just that being that I’m on a deployment for the air force seeing someone else with the same agenda kinda kicked NY while I am unable to finish mine. No hard feelings.

[Dannyps]

I haven’t read the whole thread so I don’t know what has been suggested by now, but I used to use a plugin called JSONAPI back in Bukkit’s times. It creates the possibility of connecting pretty much anything to the MC server. I believe it was secure enough. We used a combination of a username, a password, a salt and a hash of the command beign ran for authenticating. You can have a look at the source here. The command itself wasn’t encrypted though (at least back then anyway). Hope it helps nevertheless.

[Dad_Yoshi]

Sorry, I got bored with all the pointless certificate, hijacking, wall of text style replies. My point was I would want to be able to look at the potential permission changes and then decide which I want to import on a node by node basis.

[momar]

@Dannyps It’s complicated to use JSONAPI directly as it seems as you can’t change permissions if the permissions plugin does not support it. Our plugin is only an API for permissions. This means it is compatible with many permission plugins without having to do anything server-side for different plugins.
The authentication method looks good and seems to work well even with unencrypted requests - we’ll probably use something like this instead of sending a plain-text key directly.

@LordLambda I think OAuth is not ideal for this kind of authentication, as the admin already has direct access to the API’s configuration - however, I did not understand exactly how it works, so please explain to me as a security idiot how we should use it in our situation.

@Dad_Yoshi I think I don’t really understand your idea - do you want a system like the git pull requests, so others can suggest changes, or would you like to import an existing permissions file to a server? For the latter one, you will be able to do this, and although you can’t select every node individually, you can select between “import everything”, “import unset” and “import for plugins not yet set up”. Then you can change wrong nodes and if everything is okay, you can push the draft to the server.

[LordLambda]

Sure I’d be more than happy too. For OAuth it’s similar to what it seemed like you were going to. You were planning on SSL (don’t know if you still are). The benefit here is just some extra proof that who your talking to is correct. The major benefit is allowing API access, and different levels of access. So it becomes a secure way to allow people to very easily add/modify things in your framework without compromising security. I know you were considering an API so I suggest OAuth as a way to manage things easier.

[Dannyps]

I was referring only to the authentication part. Anyway, I hope it helps! Good luck

[The_Doctors_Life]

Any update on this?

[momar]

Hey guys, here’s a quick update on the status of this project:

I currently got many things to do for school, and I got no idea what @jdf2 does, but he also did not work on this for some time…
But here’s a snapshot of the current work

The design and everything the user will see is currently pretty much finished. Some things are improved, many added.

The interface between server and database is also completely planned now (the minecraft server pulls all the information from the database with one https request, triggered by an admin or a bot entering “/absorbent pull [token]” into the chat)

The database is planned and currently under construction.

The server side scripting which does the magic is not done yet.

The client side scripting which does the magic is not done yet.

The plugin is not done yet but @Phase has anything he needs to get started.

There will probably be a custom stylesheet for Absorbent to be embedded as a SpaceCP module!

You can see, the most important things still have to be done, but we expect the first alpha to be released as soon as the first Sponge version comes out (I heard it will take approximately a month).
After that there’s still much work to be done (API, make the plugin Open Source-ready, add more features, …), but that’s the point when Absorbent can be used.

[jdf2]

I’ve had school and my own tech fair project.
But have done a couple things with this…

[Phase]

“Anything he needs to get started” my butt.

I still say use a MySQL server, as it would be the easiest to implement on the server.

-gg conan 2012