[whatwg] webforms2: new hash attribute for input ?

On Thu, 16 Aug 2007 19:49:27 +0100, Julien TOUCHE  
<julien.touche at lycos.com> 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

Received on Thursday, 16 August 2007 14:01:57 UTC