On Thu, 16 Aug 2007 19:49:27 +0100, Julien TOUCHE
<[EMAIL PROTECTED]> wrote:
Unfortunately this will not secure browsing session, because once user
is authenticated, server will have to use cookies which could be stolen
and used to impersonate the user.
cookies are another part of the problem which needs to be secured too
(httpOnly, secure, limited to one IP, and so on ... but could be
overcome too)
Limiting cookies to one IP is problematic with proxies (may block users
behind proxy farms, protection is weakened for users of ISP's proxies).
Still need to standardize other algorithm than in rfc2617 which
specifies only md5 (better to add sha1/sha256/sha512)
Fortunately RFC 2617 allows addition of new algorithms (I haven't checked
if that doesn't break popular clients though).
rfc2617 also defines a salt-like with nonce, which is a very good point,
but it seems to give the same problem said in first mail: it need
server to have passwd in clear to be able to compare against a changing
hash (if nonce is used) ...
Maybe I'm missing something, but AFAIK server only needs to store H(A1),
which may be generated without nonce if 'MD5' (rather than 'MD5-sess')
algorithm is used, and this does not eliminate nonce from the algorithm,
because it's used in computation of 'request-digest'.
another problem is you can't block brute attacks. banks account are, in
general, blocked if you miss them 3 times and after you need to call the
bank.
Digest makes it difficult to count exact number of invalid login attemts
(as legitimate requests may get rejected because of stale nonce or nonce
count), but generally it is possible to implement and when client exceeds
allowed number of attempts, server may start responding with 401 or 403 to
every request from that user/IP.
--
regards, Kornel Lesiński
