GROGGS Shared Secrets

GROGGS registration (at least for people in the University) is quite nearly automatic - you send your registration request to the GROGGS server, and recieve in response a mail message (sent to an address based on your userid) containing a secret number in hexadecimal format. You must keep this number secret - anyone who obtains it can masquerade as you. If anyone steals your secret number, you should report this to the editors at once.

In general, you will be issued with a different secret number for each server, and if you use more than one server regularly, you'll have to use an extended grogsecret file.

In order to prevent people looking over your shoulder when you're viewing your profile, unless the switch /secureterm is on, grogprofile won't display your secret on the screen unless you change it.

By default, your shared secret is kept in the file ~/.groggsecret, which is set up so that it is readable only by you. You should take care not to let this file fall into the wrong hands.

The format of the file is the word 'md5-secret' followed by some spaces and then your secret in hexadecimal format.

greadnew just uses .groggsecret, but WrenGROGGS allows for two secrets files - .groggsecret for level 2 secrets, and .rogroggsecret for level 1 secrets (WrenGROGGS does not support editoral access yet - when it does, there will be a separate file for level 3 secrets). WrenGROGGS can also read the extended grogsecret format, which allows you to specify different secrets for combinations of server and userid. However, if you use this facility, you can no longer use greadnew (greadnew chokes on the files). A future release of WrenGROGGS will circumvent this problem.

For the very interested (or the chronically bored), the protocol used by the GROGGS server goes something like this :

At present, WrenGROGGS (and the server) only support an md5-based authentication mechanism.

A is the client, S is the server, N_X is a nonce, U_A is A's userid, ^(X) is the bitwise inverse of X, S is the shared secret, and MD5() is an md-5 hash of its arguments (MD5 is specified in RFC 1321). All nonces are 16 bytes long, and the userid is truncated to 16 characters or padded to 16 characters with ' '. A fuller description can be found in the protocol spec. here.

S -> A : N_S
A -> S : MD5(N_A, N_S, U_A, ^(S)), N_A
S -> A : MD5(N_S, N_A, U_A,   S)

Some points about the protocol :

• Secrets are currently 64 bits long, so barring a cleverer attack on the protocol, it should take an search on the order of 2^64 MD5 hashes to guess a secret.
• Off-line guessing attacks are possible.
• Attack is trivial if you can persuade the server to give the same nonce twice.
• The server's confidence that the client is genuine arises from its belief that it has not been tricked into repeating a nonce, and the client's belief that the server is genuine arises in the same way. It is therefore imperative that both parties are confident that their nonces have not repeated.
• Nonce predictability is not an issue as long as no nonce is repeated. It is quite in order for either party to use a counter to generate nonces, though any failure in the counter represents an opportunity for attack.
• There is an obvious middle-person attack.
• The swapping of N_S and N_A in the two messages effectively prevent you exploiting anything you might find out about the correlation between MD5(X,A) and MD5(X, ^(A)).
• The inversion of S prevents attacks based on setting N_A and N_S equal, and prevents you exploiting anything you might discover about the correlation between MD5(X,A,Y) and MD5(A,X,Y).

• Key distribution attacks are easy : specifically, one only has to be able to trick the server's mail-resolution code and fake mail to do a middle-person attack on the shared secret.
• Attacks on the secret files themselves via. trojan horses are usually trivial.
• Attacks on bugs in clients (temporary files containing secrets just closed, not overwritten, secret files left world-readable etc.) are likely to be a feature.
• Attacks on bugs in the server editing commands (in which you trick the server into believing you hold an EDLK) may be possible.
• Attacks on terminals (as always) will probably be a major feature (people leaving themselves logged in, etc).
• Attacks via other access mechanisms (password snooping, rlogin spoofing, that sort of thing to get the secret) are possible.
• Attacks on the nonce generators are also possible.
• Fake replies.