CasperAuth/Security

We take security very seriously, and believe that transparency is an essential part of any secure system, especially when potentially sensitive user data is being handled.

To this end, this document is a technical write-up of our new CasperAuth login system, which is currently being used with CasperVend and this wiki, and will soon be rolled out to the rest of our network via the new control panel.

This document is a technical overview intended for anyone who is interested, and is NOT required reading by any means.

What is CasperAuth?

We're currently working on a new control panel which will bring all of our products together into one place.

As part of this solution, a new user login system has been built and deployed - this is CasperAuth.

OAuth2

CasperAuth is fully OAuth2 compatible, and indeed that's how it's currently integrated into CasperVend and this wiki.

OAuth2 is an industry-standard secure way to authenticate users with an external system. Both CasperVend and this wiki use the Authorization Code Flow. This mechanism is well documented on the web and so it's out of scope of this document.

We intend to allow public access to our OAuth2 system so that external sites are able to securely authenticate avatars via CasperAuth. If you're interested, please contact Casper Warden.

Implementation

Device Code

The first token which is obtained from the server is a device code. This device code is unique for each browser or application which accesses the site. It's a non-expiring cookie which is stored in a secure http-only cookie to prevent it from being intercepted by malicious Javascript or browser extensions.

This device code cookie is signed by the server and later the signature is verified, to ensure that only cookies issued by the server are accepted.

The device code will later be used to facilitate MFA. Currently it's only used for device trust.

Websockets

The new CasperTech control panel uses websockets, utilising an efficient binary protocol for fast and effective communication.

Websockets are great, but come with one significant drawback from a security perspective: session cookies.

A secure session cookie is essential. This means, a cookie which is only sent over HTTPS and, more significantly, must not be readable by Javascript. Websockets can't set these, so we use regular HTTP requests to set cookies in secure/http-only mode - one of these is the Device Code which has already been set.

Once we have the device code, a secure websocket connection is established. The device code signed cookie is then verified by the server, and if it's valid the connection is accepted.

Authentication

We go far beyond current industry standards in order to future-proof our technology and provide the highest level of security for our users.

The user password is never sent to our servers, even in an encrypted form. Instead, we utilise browser SubtleCrypto to derive a completely unique and irreversible key based on a pre-shared public salt.

This derived key is then sent to the server. However, we don't simply store this key as-is. The server then performs a further key-derivation step with with fixed complexity and a new salt, which produces the final key which is then stored.

These key-derivation algorithms, running in both the browser and the server, are designed at making both online and offline brute-force attacks unfeasible. Basically, the time it takes to calculate each password is so costly that it slows any kind of attack to a crawl.

To further inhibit online brute-force attacks, a captcha system is implemented and will activate when a certain number of attempts have been detected either on a single account or from a particular IP address.

As a last line of defence, if a LARGE number of authentication attempts is detected against a particular user account, the user account is locked for a short time. This scenario is highly unlikely, but is in place in case of a successful captcha bypass attack.

Session Resuming

In the event that the websocket gets disconnected, the session can be re-established and re-authenticated with the use of a session token which is issued over the socket when a connection is established.

The session token is a signed JSON Web Token which contains the sessionID and device ID. It's sent to the server when the websocket reconnects, and used to resume an existing session.

While the session token is accessible by Javascript and could technically be stolen by some malicious code or browser extension, it's not possible to use it without the signed Device Code cookie which is not available to Javascript.

The session token also has a short expiry and is renewed on reconnection.

"Remember me"

The "Remember Me" consists of an optional signed cookie which can be requested when initially authenticating.

If the "remember me for 7 days" checkbox is ticked on the login screen, then a flag is set in the login message which requests an Auto Login Token. This token is generated only after authentication is successful, and a "claim code" is sent back to the browser.

The browser then makes a regular HTTPS request to exchange the claim code for the Auto Login Token, which is stored as a secure http-only cookie. Again, the device code cookie is checked here to ensure it matches the request, so the claim code can't be stolen and used by another user.

The claim code is remembered on the server and is validated each time the Auto Login Token is used, which allows the token to be invalidated.

Log Out

Upon logout, the "Remember Me" token is invalidated, and any OAuth2 authorization on the device is invalidated.

The user's Avatar Name is remembered on the login screen, but this can be permanently removed by clicking the "X" next to the avatar name.

Limitations

We ultimately depend on Second Life for Avatar authentication and therefore, unfortunately, we can only ever be as secure as Second Life itself.

However, if the Second Life account is compromised, the attacker has full access to all in-world devices and linden balances anyway. We hope that Second Life will take steps to improve their login security in the future.

We will soon be implementing (optional) MFA to the system via U2F devices or TOTP authenticators or email, but this is not yet implemented. Again, the reason this has taken a backseat is because it would be rendered largely useless due to the lack of MFA support within the Second Life login system.

Other considerations

• Data compression to the API is disabled due to attacks like CRIME. However, all data is exchanged via a well-packed binary message protocol which is very efficient so compression is pretty unnecessary.
• We regularly review and conform to the latest industry standards and recommendations regarding our our server configuration
• HSTS is in force to ensure that TLS is always used to access the authorisation website.