On 08/15/2012 08:49 AM, Merlin Moncure wrote: > 1) allow use hmac as you suggest (but this forces user to maintain > additional password or some token)
Not really. You would store a token and the HMAC of the token using the user password on the server side. You would need access to the hash function on the client side as well. On authentication the server sends the token to the client, and the client calculates the HMAC using the user provided password. The result is sent back to the server for comparison. This way the user's password is never actually sent over the wire. Now this is still susceptible to a replay attack, but you can fix that by adding another layer. On authentication the server generates a new nonce (random token) and sends it to the client along with the stored token, as well as calculating the HMAC of the nonce using the stored user HMAC as the key. On the client side the the process is repeated -- HMAC(nonce,HMAC(token,password)). This provides a one time calculation preventing replay and does not expose the user's password or token-HMAC over the wire. The final problem as you stated is weak passwords and some kind of dictionary attack against a stolen set of tokens and HMACs. Didn't we add a hook some time ago for user provided password checker? Joe -- Joe Conway credativ LLC: http://www.credativ.us Linux, PostgreSQL, and general Open Source Training, Service, Consulting, & 24x7 Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
