AuthenticationAndTrust

From Codawiki

Authentication and Trust

Coda relies on a shared secret encryption for it's connections. The user's password is used to set up a secure connection to the authentication daemon (auth2). If the connection can be established the user knows that the authentication daemon must know his password and as such can be trusted.

Since the user has proven his knowledge of the password, the authentication daemon also trusts the identity of the user and returns a Coda token (over the secure connection) which contains a random session key and an encrypted copy of the session key. The user passes the token to the Coda client who then uses it to establish secured connections on behalf of that user.

The key for the encrypted part of the Coda token is shared between the authentication daemons and the Coda server processes in a realm (the key is stored in /vice/db/auth2.tk). As a result any Coda server who can decrypt the encrypted part of the Coda token and establish a secure connection, proves that they are part of the same realm as the authentication daemon.

So far so good, here is where the current implementation starts to break down. An unauthenticated user does not have a Coda token, and as such cannot establish a secure connection. So anything fetched by an unauthenticated user is possibly untrusted. And since the cache is shared between all users, this means that any object in a directory with System:Anyuser access rights was possiby fetched from an untrusted source.

• Ideally when we try to access such an object we should not have cached rights for the authenticated user and force a refetch of the attributes over a secure connection. Note to self, check implementation I don't believe a System:AnyUser getattr/fetch clears cached rights for authenticated users.

• Ofcourse during a disconnection we cannot revalidate such objects at all, current policy is to allow access to possibly untrusted objects during a disconnection. Note to self, add option to prevent accessing objects that only have System:AnyUser rights with the idea that if any other authenticated user has looked at it, we can have at least some amount of trust in the object's validity.

• Refetching the attributes only checks if this user is allowed to access the object, but does not really validate whether the associated cached data is valid. This is where we could potentially use the SHA1 checksums that server can optionally return in the GetAttr response.

To be continued...