Matthew wrote:
>I agree - what Janifer is talking about is a user authentication token -
>not a session id. The original objection to Janifer was that a session
>id is much more easily forged than a username as password (as Rob has
>pointed out a session id may be little more that an incremented number).
>For an authentication token to represent a username/password pair
>without opening up spoofing attacks you need something far stronger than
>a session id - or a permanent open socket ala classic Z39.50.
I disagree. It is trivial to make a session ID secure.
a) Let a session id be 64 bits (a bit short for a session id)
b) Let a session manager keep a list of valid session id's
c) Let the session id be generated in a random fashion (a combination of
server id, sequence number and a random part (use any nice cryptographically
correct random generator, or a stupid one))
d) Assume several thousend sessions are active.
To spoof a session ID will be hard work. It will probably generate a century
long total server overload before a session id can be guessed. It is secure.
On top of that guessing the secret will only give access for a limited
amount of time. Passwords are, unless computer generated, mostly very
insecure. I would rather guess passwords than valid session id's.
Sending a user id and password with every transaction is insecure unless
secure channels are used. Using session ids the big secret (which user is
sending and receiving and what is his password) is much safer.
The problem of not having an optional! session id is that some implementers
will be forced to introduce set ids with implicit sessions ids. Some servers
simply need session ids as soon as sets or authorisation are involved.
One purpose of srw/sru is to have a simple to implement protocol. It should
be possible to use as many implementations as possible, servers and clients.
We should impose as little architecture on servers and clients as possible.
Rob Koopman
