This serves to prevent replay attacks; if
this information were not kept and verified, an eavesdropper could simply ???replay??? a
sniffed authentication handshake and convince the server that he is the original user.*
The problem with keeping any application state on the server is that it hinders scalability.
For a pool of 100 application servers to implement HTTPBasic authentication,
they need only share the list of valid login/password combinations. But for the
same pool to implement Digest authentication, the servers should share a list of
issued nonce values to defend against replay attacks.
HTTPauthentication is desirable from a RESTful perspective, because it minimizes
or eliminates session state kept on the server. There are other options for authentication;
perhaps the most common in Rails is to use the session mechanism to store the
ID of the currently logged-in user. Typically, this session is indexed by a key that is
given to the client. Newer versions of Rails store a server-signed copy of the entire
session in a cookie. This is actually more RESTful, but it is vulnerable to some of the
same replay attacks as Digest authentication (other Rails session storage is not vulnerable,
as a direct consequence of its server-side state). It is of course up to the
application developer to draw the boundaries, depending on the application??™s security
needs and the consequences of session replay.
Pages:
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321