SkotOS Keycode security and MD5 hashes

[noahgibbs]

Hey, folks!

As part of some other work I'm doing, I've been auditing SkotOS security. I have some less-than-fantastic news.

As you know, thin-auth switched SkotOS auth from just MD5 hashing (which is bad news: https://www.section.io/engineering-education/what-is-md5/) to using PHP built-in passwords to generate nonces -- large random numbers used for a fairly short time so you'd have to brute-force guess them.

SkotOS calls those nonces "keycodes" and that method of authenticating "keycodeauth". So far, so good.

The keycodes are treated (roughly) as temporary passwords... And are encoded on the wire with MD5. That means that effectively they're barely encoded at all. And they're passed as a cookie with the name "pass", which is likely to draw attackers' attention to it rather than the opposite. We also have no rate-limiting on password attempts. So a serious attacker could bust through this like tissue paper, basically. The only thing that makes it annoying currently is that they'd have to make a lot of login attempts, and the auth server is slow-ish. But that's not significant security.

I have a pretty decent partial solution, and one other recommendation.

The first, simplest part: start using HTTPS and (for websockets) WSS for all connections, always. Thin-auth already does this for the login server. But the Gables and ChatTheatre SkotOS code I inherited didn't do this, and one or two SkotOS games I've checked also don't. See the section below to check if your current setup is correct. The important thing is that there should not be a way to use http for your game client, only https. So if you have both a secure and an insecure section, that's not great. Those nonces are leakable.

(Why do I keep pointing out the "nonce" thing? Is it to show off my vocabulary? Partially. But also so you understand: this is not actually leaking passwords. If somebody could break security 4 hours after their target logged in, they'd have the ability to log in as that person -- for about 44 hours. And then the keycode would expire and they'd have to start over. Though I think their connection would still be logged in as the victim for as long as it was connected.)

My other recommendation is to reduce the time before thin-auth makes you re-log-in from 48 hours to 24. I'll submit a PR for this soon. That won't make anything more secure, but it will limit the window of damage a bit at (I think) a very reasonable cost in inconvenience. You can probably skip this change if you switch everything over to https and wss. The opposite is not true - https is a pretty good fix for this problem. A shorter nonce duration is a band-aid.

I don't know how often folks here pick up the latest changes to thin-auth. But there will be some of those soon which are worth considering. You can also make the changes for yourself locally - it should be just a couple of lines of difference in thin-auth.

I don't think anybody is using the ChatTheatre SkotOS branch "for real" yet. But it uses all-secure connections by default in its linode configuration.

Details of NGinX Config

The first, and simplest check is just to go log into your game. I'm looking at Castle Marrach as a representative example. If I pick Orchil to play, I go to an http URL, not https. So Marrach is vulnerable to this problem. On Orchil there's a connection line immediately after you log in, right at the top:

Starting connection to: ws://game.marrach.com:9080/marrach
CONNECTED

So Marrach is also using "ws:" at the front of the URL, not "wss:". So that's also not being encrypted on the wire. You can check your own game.

You can also check your NGinX and/or Apache configuration. I won't tell you how to check your Apache config, though you can Google it. But for NGinX I have a nice sample that I can show you.

If you're using NGinX for websockets (and I assume you are) then check your game's NGinX config block. Here's what I use for ChatTheatre SkotOS:

server {
    listen *:10810 ssl;
    server_name $FQDN_CLIENT;

    location /gables {
      proxy_pass http://gables-ws;
      proxy_pass_request_headers on;
      proxy_set_header X-Forwarded-For \$proxy_add_x_forwarded_for;
      proxy_set_header X-Real-IP \$remote_addr;
      proxy_set_header X-Forwarded-Proto \$scheme;
      proxy_set_header Host \$host;
      proxy_http_version 1.1;
      proxy_set_header Upgrade \$http_upgrade;
      proxy_set_header Connection \$connection_upgrade;
    }
    ssl_certificate /etc/letsencrypt/live/$FQDN_CLIENT/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/$FQDN_CLIENT/privkey.pem; # managed by Certbot
}

You want to make sure that for any block like that has "ssl" up on the "listen" line near the top. And it should have the two "ssl_certificate" lines. Those are important. That "proxy_pass" block is what passes the request to the websocket. And the port number (here 10810) is the same one in the "CONNECTED" message above for websockets (so 9080 for Marrach.) But you want to also make sure you don't have a block like this with no SSL and no certificates at a different port number. If users have an insecure way around the "right" way, you may not be protecting their passwords.

If you have a non-SSL block elsewhere that is not for the game client or websockets, that's fine. It's not that you can't have any insecure pages, ever. But you want to make sure it's an unbroken chain of HTTPS and WSS that get the password cookies so that those can't be intercepted in transit.