Page 1 of 5 123 ... LastLast
Results 1 to 10 of 41
  1. #1
    Who?
    Join Date
    Sep 2009
    Location
    Stockholm, Sweden
    Posts
    2,799

    04-04-14 Permissions/Security/Complexity

    Here is what-it-is and notes on upcoming changes.

    The security page is displayed in as simple a way as I could muster.

    The permissions currently shown will be limited so the page is not one massive scroll-fest, but for now it shows most of them.

    Adding players to accounts will be simplified on the player-details page in the not too distant future. For now it's manual work which sucks balls.

    You will not be able to see the Stream group in release. Don't delete the Stream group. Don't edit the stream group. You can see/poke it for my good debugging, not yours. It's best to ignore the Stream group.

    Anyway. Here is the structure of Security in #2

    1 Group has many Accounts
    1 Group has many Permissions
    1 Permission has a Name and Authority level
    1 Account has many Players
    1 Player has a Uid and Protocol Type

    So, you make a Group. Give it a name.

    Now make an account, give that a name.

    If you want the account to login, give it a password.

    Now attach a player the ugly way, with a eaguid and protocol type.

    Easy enough so far?

    Permissions. Permissions are a bitch. They're also pretty fucking cool.

    A plugin can introduce new custom permissions that you can allow/disallow a group on.

    A group is assigned an authority level for a permission.

    Accounts with less authority than other accounts won't be able to take that action against that account. "Scum Admins" group with authority of 1 in Kick, won't be able to kick "Super Amazing Happy Fun Time Admins" with authority of 2.

    So why not just have input boxes with numbers? It's lame. That's such a lame way to do it. Instead you simply select from the drop down list of what group they can bully.

    So when you're setting the permissions of the group, you're just setting the pecking order.
    I started at DICE late Oct. 2014, so ignore every post before that.

  2. #2
    Who?
    Join Date
    Sep 2009
    Location
    Stockholm, Sweden
    Posts
    2,799
    Update from steam chat with Nick so I don't have to repeat myself..

    Phogue: At one point I had it so an account could exist in multiple groups and when a permission check was done it would pick the group with the highest authority. I removed that because I figured people would get themselves into trouble.MorpheusX(AUT): aha
    MorpheusX(AUT): I think I understand
    MorpheusX(AUT): Accounts with less authority than other accounts won't be able to take that action against that account. "Scum Admins" group with authority of 1 in Kick, won't be able to kick "Super Amazing Happy Fun Time Admins" with authority of 2.
    MorpheusX(AUT): so stream
    MorpheusX(AUT): was not allowed to use fetch at all
    Phogue: null or 0
    MorpheusX(AUT): it's logical for the player example you gave
    MorpheusX(AUT): but a bit weird for "system" permissions
    MorpheusX(AUT): like fetch, or variable set, or something
    Phogue: yeah they were supposed to be tick boxes but I can't think of how to achieve that.
    Phogue: Granted, that's a bit strange since you'll never encounter an authority denial from that, just permission denial.
    Phogue: The trouble I have with putting in a checkbox is plugins will set custom permissions and ask for a check box..
    I started at DICE late Oct. 2014, so ignore every post before that.

  3. #3
    Community Contributor
    Join Date
    Nov 2011
    Posts
    2,980
    On this topic, I am curious about Procon 2's other security features. Specifically, what password hashing method is used? bCrypt? Salted? Does a forgotten password reset send a new randomly generated password to the user's email account? Does the interface use SSL? If the hosting site doesn't support SSL, is that an option or are they forced to purchase a SSL certificate? Are there rules for password lengths or required characters or can hosts easily change the password requirements? If a user is idle on the interface for a while, does their stale session get logged out automatically? If the user logs in from a new IP address, do they have to verify their validity through an email or text message notification containing a randomly generated authoring code? Does the site check for multiple active sessions for the same username from different ip addresses? If a user selects 'remember me' does it verify their identity on the next automatic login based on a session table verifying the same ip address or something, or is it only a cookie (which could be stolen) containing a randomly generated string? Are there logs for when users log in or log out and logs for the actions they performed while logged in? Is the site safe against mysql injection or cross-site scripting?

    These are just some questions I have before I have had a chance to even test this interface out.
    Last edited by ty_ger07; 03-04-2014 at 21:34.

  4. #4
    Who?
    Join Date
    Sep 2009
    Location
    Stockholm, Sweden
    Posts
    2,799
    Critical issues right now



    Both of these issues must be resolved prior to Closed Beta.

    Implemented now

    • bCrypt(10) for C# storage
    • Procon C# only works over SSL
    • Procon UI only communicates via SSL to Procon C#
    • https://procon.myrcon.com, https://billing.myrcon.com and https://gsp.myrcon.com will have an EV Certificate much like these forums
    • Procon C# generates a self signed certificate per instance. You can drop in other certificates.
    • Procon C# requires command line argument with password for certificate.
    • Communication between User <-> UI <-> C# is all done on SSL
    • There are no rules on required lengths or characters of passwords but I want to implement something like https://howsecureismypassword.net/ on all password input forms. I feel this gives a better indication of password strength than "weak" and "strong"
    • Sessions are tied to the users IP.
    • Users can be logged in on multiple devices at the same time - multiple sessions (by design)
    • There are events for almost everything that come from Procon C#.
    • The UI uses MongoDB. 0% chance of MySQL injection.
    • Xss - I hope so. I've done everything I can think of?
    • Communication between Plugin UI <-> Plugin UI Sandbox is done with postMessage, so plugins shouldn't be able to access the users cookie and what not. It validates origin and domain.


    Not implemented now (and no plans)

    • 2FA authentication ("If the user logs in from a new IP address, do they have to verify their validity through an email or text message notification containing a randomly generated authoring code?")


    Grey areas

    • When you make an account for some one in the UI we never ask for their email address. There is no method of password recovery because of this. I did think about including a email input which would generate a random password for the user, then send the email to the user with the new account details.. but.. then I have to remember peoples email addresses. I'd prefer not having to do this.


    Marked as a "Todo" in the not too distant future

    • Thumbprint storage and validation. New certificates are not trusted until user confirms thumbprint.
    • Remember me tick box is always checked, regardless of user option.
    • The UI will record login times per account, just so they can be displayed. I might even include ip's that logged in for giggles.
    Last edited by Phogue; 04-04-2014 at 02:06.
    I started at DICE late Oct. 2014, so ignore every post before that.

  5. #5
    Community Contributor
    Join Date
    Nov 2011
    Posts
    2,980
    As far as the grey area is concerned, couldn't an email address be implemented in the sub-account creation dialog and then automated ("automagical") from that point? I don't understand why it would be your responsibility to remember email addresses. Couldn't the forgotten password dialog ask for the user's email address and then compare the entered email address with valid email addresses stored in the database to find a match and automatically email a randomly generated (and server side rehashed based on the automatically randomly generated password) to the user's email address if a valid match was found? If the user enters an email address matching a valid account, the system should be able to handle the rest of the process automatically without you being required to memorize user's email addresses and handle the rest of the request manually. This would transfer the email address management responsibility to the admin who created that user's sub-account (making them responsible for entering a valid email address for the user they add as a sub-account).

    Otherwise, how does the sub-account user retrieve their password in the event they forget their password? Is it the primary account-holder's responsibilty to reset that user's account? I hope that sub-account users' passwords are not stored in plaintext form in a configuration file as they were in Procon 1. It seems to me that Procon 1 had a security issue related to storing users' passwords in plaintext form in a configuration file when the passwords should have instead been hashed and stored in the database. My opinion is that primary and sub-account users credentials should both be stored in the database and not in a configuration file. I don't see the need for a configuration file if a database can accomplish the same task in a more secure method.
    Last edited by ty_ger07; 04-04-2014 at 04:42.

  6. #6
    Who?
    Join Date
    Sep 2009
    Location
    Stockholm, Sweden
    Posts
    2,799
    Language barrier? "Remember" in this context implies the system storing something in the database.

    You also seem to pack a post full of questions. It's a little difficult to answer them all in a concise way.

    The two systems are far more disparate than you think. The UI we run is an entirely separate system to Procon C#. They don't share a database, computer - nothing. This allows people to host the core application/plugins/etc but still use the UI.

    The C# side could have an email address attached to an account, but it couldn't email. It's not a client facing system like this. It also wouldn't ever trust an unauthenticated account for any action. This won't change.

    The UI cannot reset a password if no user is authenticated - it has no method of authenticating with Procon C# to reset the password. The streaming user is setup with minimal permissions, but I have plans on restricting this to a single permission in the not too distant future. This would lock the streaming user out of all but it's current function.

    The UI has identical restrictions placed on it that you, the user, has. It just stores data and makes data look pretty. When you issue a command it *has* to use your credentials to execute these commands. It has no secret-squirrel backdoor to the C# instance because smarter people than me would work that out

    Unauthenticated User



    UI storing email

    • User -> UI "I have forgotten my password [email protected]"
    • UI -> C# "Reset password for Phogue"
    • C# -> UI "The streaming account does not have permission to change passwords, cause that would be bad."


    So we don't store emails at all, in any context for any means within the UI or C#. If you make an account for some one in the UI and they forget their password then they will need to contact you.

    If the 'main' admin, say EBassie, forgot his login details to the UI then he would need to login to his account in WHMCS/GSP-Panel and change his password there (this isn't there yet). This would change his password with his C# instance and he would be able to login again.

    If he hosted Procon himself then he would need to shutdown the C# instance and execute: Procon.Config.exe --Command SecurityAccountSetPassword "EBassie" "password1"

    Your C# instance stores encrypted passwords for the user accounts. I have plans on using the certificate password passed in by command-line argument to encrypt server passwords. This is just so we don't have the problem now where people post configs for help that can contain their plain text passwords passwords.
    I started at DICE late Oct. 2014, so ignore every post before that.

  7. #7
    Community Contributor
    Join Date
    Nov 2011
    Posts
    2,980
    Pardon my missunderstanding of the system and my endless stream of questions. I guess what I was asking is whether sub-accounts could also use the GSP control panel for authentication and have access to the same system that the primary account holder has access to but at a restricted level as determined by the primary account holder's wishes and use that to handle their login credentials instead of using a plain text configuration file.

    If not, could the configuration file be encrypted or otherwise obfuscated for security reasons so that no one with access to the file (hacker, potentially crooked gsp operator/web admin, or account holder [via ftp]) can understand the contents of the file and only gsp control panel innitiated changes by a logged in admin can modify the file from the gsp panel options in a valid (re-encrypted or re-obfuscated) way.

    I do not understand the system or its limitations, so I ask. I have seen hints of an exciting web-based system but do not know where one starts and the other ends.
    Last edited by ty_ger07; 04-04-2014 at 05:17.

  8. #8
    Who?
    Join Date
    Sep 2009
    Location
    Stockholm, Sweden
    Posts
    2,799
    The config files store encrypted user account passwords. They currently store connection passwords in plain text, but I want to change this so a master-key is used for these passwords.

    User account passwords do not need to be bi-directional, but the server passwords do so Procon C# can authenticate with the server.

    [Whmcs/Gsp-Panel] =/= [Procon UI] =/= [Procon C#].

    The best analogy I can give is renting a Teamspeak 3 server that requires user authentication, but imagine you don't download anything and it's hosted on a webpage.

    1. You rent a C# instance (which automatically sets up your Procon UI) via WHMCS/Gsp-Panel. Only the person paying the bills should have access to this.

    OR

    1. You setup the Procon UI for your self-hosted Procon C#. Only the person paying the bills should have access to this.

    2. You login to via the Procon UI and create accounts for other admins. Accounts are stored with the Procon C# instance.

    3. You never really need to interact with Procon C# directly.

    If you follow the analogy for Teamspeak 3..

    1. You rent a Teamspeak 3 Server (which automatically sets up https://teamspeak.com/ty_ger07 for you to login) via WHMCS/Gsp-Panel. Only the person paying the bills should have access to this.

    OR

    1. You setup the https://teamspeak.com/ty_ger07 for your self-hosted Teamspeak 3 server via WHMCS. Only the person paying the bills should have access to this.

    2. You login to via https://teamspeak.com/ty_ger07 and create accounts for other admins. Accounts are stored with the Teamspeak 3 server

    3. You never really need to interact with the Teamspeak 3 server directly.
    I started at DICE late Oct. 2014, so ignore every post before that.

  9. #9
    Who?
    Join Date
    Sep 2009
    Location
    Stockholm, Sweden
    Posts
    2,799
    See the changelog at https://forum.myrcon.com/showthread.php?7721-Change-Log

    There are numerous changes made to the permissions panel to simplify it. You will require a Core/Core.Shared update to get all the benefits.
    I started at DICE late Oct. 2014, so ignore every post before that.

  10. #10
    Community Contributor
    Join Date
    Nov 2011
    Posts
    2,980
    Yesterday was my 30th birthday so perhaps you can understand why I was a little slow on the uptake of some of the information written.

    I think a system diagram would make it easier to understand the system. But I assume that this is already in the works/planned for the user manual which will eventually be released.

    I envisioned that the system was structured something like this diagram below so that the webserver via WHMCS or UI could handle authentication and user account settings and have the burden of maintaining the front-end security totally on its own, but apparently that is not the case. I envisioned that the front end structured in this way would allow for easier and more rapid adaptation and modification of the front end without needing to modify the Procon C# in any way. ...similar to how Battlelog replaced the in-game server browser.


    I envisioned that the Procon C#, plugins, web server, and database would all be on the same machine in this way:


    Code:
                       Game Server             WHMCS          UI
                           |                       \          /
                        Procon C#                   \        /
                         /     \                    Web Server                 
                        /       \                       /
                  Plugins       \                      /
                                 \                    /
    Database containing game server connection details, configuration, plugin settings, user account emails/passwords, events information

    Please understand that this is only how I envisioned the system when I asked the questions I asked and is not a request by me to tell you how I think the system should work. I envisioned that an admin would create a sub-account for a user specifying their username, email address, and permissions and then the system would email a randomly generated password to the sub-account holder's email address. I figured that it would not be the responsibility of the admin to create a password for the user such as in Procon 1 and that the admin probably shouldn't be in possession of a master password list (written down sub-account passwords for multiple sub-account users since the admin is unable to memorize each sub-user's password) which is vulnerable to being viewed by others.

    Procon C# would refer to the database instead of a configuration file whenever it had a question about how it should proceed and therefore the WHMCS and UI would be able to affect Procon C# without directly associating themselves with the Procon C# application or files. Procon C# would connect directly to the game server after the connection details had been provided to it in the database via WHMCS. Procon C# would push all events (players, maps, statistics) to the database and the web server would direct requested information to the UI from the database. I asked questions about associating user email addresses with user accounts and asked about password reset procedures based on my assumption that this would all be handled by the web server on the front end in the form a web page.


    If the user self-hosted, when they wanted to view their own Procon instance, their UI would just connect to their local host internal web server instead of via WWW. And if this self-hosting user also wanted to act like a layer server for their clan members to connect to, as long as their security settings allowed them to function as a web server accessible from the outside world, things would be fine. Clients connecting to the layer would not have any Procon application or plugins on their machine (unlike Procon 1) but would instead only use the UI in their web browser to interract with the layer.


    But, my lack of reading comprehension missed this:
    The UI we run is an entirely separate system to Procon C#. They don't share a database, computer - nothing.
    In the following quote, I don't necessarily understand why "that would be bad" as long as the user's email address is valid and not compromised.
    C# -> UI "The streaming account does not have permission to change passwords, cause that would be bad."
    An invalid password reset would do no more than create a hassle for the user to check their email and login with the new password. This is standard practice on current websites I thought. Perhaps an additional authentication of the user could be added to the UI to prevent annoying password resets by making the person who resets the password not only need to know a valid email address stored in the database but also know a phone number or birthdate or any other identifier of choice.


    With my new (but still fuzzy) understanding of how the system actually works, is it correct to say that the UI will only be available via myrcon.com? You said that you want to maintain control of the UI for monetary reasons and so I have a hunch that my original understanding as depicted in the diagram above is not correct and the necessity to keep the two systems separate prevents the other behavior I asked about from being possible.
    Last edited by ty_ger07; 04-04-2014 at 18:26.

 

 

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •