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

General Discussion
21

By “has access to our files”, I assumed you meant access to the server running your frontend (web server, whatever.) In that scenario, can they not just send themselves whatever a user sends when they log in? I’m assuming you don’t keep the password completely secret, and that a would-be person with access to the web server files could use some form of it (whatever is sent) to then log in as them later on.

As long as you use SSL, the webserver’s identity can already be considered verified if it’s not self-signed. If you only checked the webserver’s IP, then I could just get around that by setting up a VM with your webserver’s IP and added a static route for it.

Indeed, hence why I would default to centrally-hosted, with the option for those that don’t trust it/whatever other reasons :slight_smile:

Indeed. I usually prefer options that are the easiest for an end-user, so not storing an API key in plaintext was tied in with the idea of the MC server pulling from the Absorbant server instead.

Not a bad idea if it works well :smiley:

If the plugin is the one to contact the Absorbant server, then you have no worries.

But yes, the other way around certainly does throw a wrench into it. Perhaps using something such as RSA? Hardcode the Absorbant server public key into the plugin (or maybe downloaded over SSL, if wanting to support self-hosted later on), and have the user provide their public key to the service.

22

Your pushing PKI very much, and I think you need to take a look at the situation from a full view. I think yes some form of PKI could be very useful, but only with other sorts of encryption to make sure those keys don’t get leaked. Because we cannot trust users to keep their Key secure (See mineplex, or the key posted above).

The same problem can be gained through leaking a key, and can cause it’s own vulnerabilities. Because we cannot trust keys we need other sorts of verification in place so if you can access to for example the server you cannot gain the keys, or change enough to gain arbitrary access to users accounts.

Although certain IP traces can be faked and perhaps an HWID system or something should be set up instead. We cannot inherently trust certificates as they can be leaked, and have been shown to be leaked in our community today.

Even with centralized communications the point is to have as close to End-To-End encryption which in no way shape or form can be achieved ONLY using PKI. Even If I only have your Public Key I can still send false data, and cause a bunch of Database IO, or other such nefarious things such as an SQLi injection, and have validly encrypted data. To “Blend” in better with normal traffic.

23

I am pushing PKI yes because it’s pretty simple and works, and I think that the Mineplex example is a fairly extraordinary one. With Mineplex, having their content (private plugins) stolen and leaked is arguably more harmful than having permissions changed/read (when said service should have backups and a modification log anyway.)

I’m not convinced we should just not trust certs entirely when poor security or internal leaks are the reason for private keys being leaked, not a fault of the certs themselves at all. If you just meant not trusting them when used as the sole security measure, then yes I agree there.

What do you suggest instead? If the server can leak a private key, can they not also leak whatever token(s) it needs to authenticate with stored in the config file? We’re talking about a Java plugin here, so relying on obfuscation for HWID generation is in my opinion moot. I suppose one could use their IP address attached to a token, but that’s really inconvenient for the user when the plugin suddenly stops working because their IP changed.

Sure, but I think you could do that to any service. Maybe I misunderstood, but if you generated a session key (e.g. SRP in your other post) the server still has to verify it.

such as an SQLi injection

If they aren’t using prepared statements or an ORM, I would be more interested in their reasons for opening themselves up to potential injection much more easily.

Really, I’m mostly just interested in how you would make the MC server itself secure against “leaks”. Making the website secure with SRP6 or whatever else is perfectly fine and it certainly would work, but the MC server still has to store something so that it can do everything without user input.

If the plugin isn’t allowed the make permission changes by itself with commands, then explaining it with a read-only API key is perfectly fine too.

24

It’s not simple to implement on a large scale which Absorbant is wanting to be. There are multiple cases were you can have conflict of instrests through hosts, people who don’t use secure certs, who don’t publish certs, or publish them to the world to see. Mineplex is not an extraordinary one as it happened on multiple servers, and force everyone to regenerate they got their fame and moved on. 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. (The people who understand it will give us the recognition if we do it right anyway.)

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. The goal is to keep those certs secret. The idea being the token is never saved, but instead generated on data that can be sent securely such as an HWID, or whatever you wish to implement (perhaps a mix), and can only be generated on a single server instance. Before we start talk over certs we need to make sure we get that cert securely, and that only the people who are supposed to are the ones using it. Agreed you should not use IP verification as it can be faked, and you shouldn’t entirely discount HWID, it could be a semi-decent (although there are better alternatives I admit), to generating a token.

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. Specifically referenced as M1, and M2:

The verification is built into the scheme so the worry isn’t needed.

This was just an example. Theoretically your server should only accept the encrypted data. So if I have your encrypted data, and that allows me access to some form, or something that I can exploit. I can now exploit it because I have the correct key to encrypt. If I didn’t have the correct key my connection would be dropped. It lowers the attack surface to not just give keys out.

The MC server would have an encrypted public key, as well as possible private key if the server needed to send data back to the MC. This encrypted values are stored flat-file. 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. The token is kept in a private field, and access is prevented through a custom security manager to trace calls, to this variable, and deny any not generated from the class itself. Thus meaning you would have to have a rogue plugin (and you could throw in some hash checking server side to make sure the plugin was a valid non-modified copy), or a rogue JVM to access. Then through smart code design you can essentially block other plugins from accessing encrypt/decrypt functions, or letting them preform it themselves. Meaning only the plugin knows what it knows, and it can operate fine, but it would take more work than is conceivable to break the plugin.

25

Okay, here are the things we can do to provide most security without excessive planning and coding:

  • 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.
  • 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.
  • Passwords are stored securely salted. Brute force and knowing our code is the only possibility to get the plain passwords from the database.
  • 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.
  • We use SFTP with public keys to access our server. We trust each other that noone from the team ever becomes a griefer.
  • Of course we use prepared statements and let nobody do an SQL injection. The MySQL server is only directly accessible from localhost.
  • 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.
  • 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.

Reason: 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.
BTW: When comparing our security approach to most of the other HTTP APIs for Bukkit (which btw often offer more access to the server), I’m pretty sure that we are one of the most secure ones, which can destroy the fewest things even if hacked.

The thread is getting a little theoretical, so if you tell us any specific possible attack that a) does not involve us as humans, b) does not result in a DoS, c) does not involve any theft of anything on the server admin’s side, d) is possible when our code does not contain security issues and e) is not an exploit of a program used by us or the server owner, we will of course find a solution for that. :wink:
Attacks to points a) to e) exist in every service that provides something while being secure (and not the other way), and we can’t do anything about it by using encryption, and we do everything possible to make such attacks as hard as possible.
However, feel free to inform us about attacks for points d) and e) when the open beta is out. :smiley:

@Hidendra’s last point: Permissions can normally be changed with the permission plugin’s commands, however their permissions are locked to deny for everyone by default. Every connection between the server and Absorbant involves the token, which basically is the API key for a specific user and server. (will maybe rename it to that as it makes more clear what it does)

Disclaimer: These are my personal opinions and ideas; I did not speak to the rest of the team about it yet due to time zone problems. If you have a reasonable problem with my opinion, feel free to inform me about it in a nice manner. :wink:

26

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.

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.

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.

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.

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).

See above.

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.

27

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.

28

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

“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? :smiley:

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. :wink:

@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.

29

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.

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.

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

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.

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).

30

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.

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.

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?)

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.)

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.

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.

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.

31

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” :wink:

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… :wink:
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 :smiley:

32

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.

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.

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

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 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.

33

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.

34

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

35

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 :wink:
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.

36

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.

37

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.

38

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.

39

@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. :smiley:

@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.

40

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.