Security through obscurity being bad, we aim to provide full disclosure about what Prasi does behind the scenes, and how it performs the various operations. You are invited to browse the CVS code prior to testing or using Prasi, so you can check to your satisfaction that it is indeed as secure as you require. Comments on any aspect of the code or protocol are of course extremely welcome (please send these to the mailing list so the public may later read these exchanges). There are two fundamental security/privacy-related operations in Prasi: authentication and identification. Authentication is concerned with making sure the user is really who he claims to be. Identification is concerned with making sure that the user is the same as the previously authenticated user. The identification operation should be as fast as possible, authentication may be significantly slower. The user must be re-authenticated on a regular basis, and also if there is any suspicious activity. In Prasi, we further add salt to the mixture by defining services which are local (have a direct filesystem access to Prasi) and which can therefore communicate securely with Prasi, and those which are remote (for example residing on a different server), which can't. Below we diagrammatically attempt to show what goes on inside Prasi during the various stages.  Local authentication starts with the user sending his username and password, possibly after a service requests the user be logged in. This is sent over plain text unless Prasi is configured to use SSL (and this is fairly straightforward), in which case no-one is able to intercept the data. A unique identifying number is sent to the user in a cookie; this together with the IP address and an expiry date/time forms the basis of the later identification. No user stays logged in for more than 2 weeks, and this expiry can be set by the user to lower values still.  Remote authentication proceeds as the local one; but a separate cookie is set for each remote service (with the cookie domain set to match the remote service domain, ie. third party). This contains the username in plain text, along with an MD5 hash of: a code known only to the remote service and Prasi AND the user's IP AND the expiry date/time.  Local identification is straightforward and simply consists of checking the ID code and user IP against those in the sessions file. Expiry and access to service are also evaluated at this step.  The remote service can verify that the user is legitimate by reconstructing the hash and comparing it to the one supplied by the user. To do this, the username (given in cookie), IP address (broadcasted), expiry date/time (supplied from Prasi response, no private data exchanged in this step) and code (known only to remote service and Prasi) are required. Note that over the remote-service-to-prasi-server exchange, only "public" data is exchanged, which means that if SSL is enabled between the user and Prasi/service, man-in-the-middle attacks are foiled, and replay-type attacks are only effective for however long the session remains valid. Therefore the following information can be available publically and are not considered secret: username, user IP, and user session expiry date/time. These informations can be so easily obtained by various methods that no secure system should rely on their secrecy! Prasi uses these data as part of authentication and identification but at no stage is any authentication or identification performed solely on the basis of such "public" information. |