On 19 December 2016 at 00:51, Rowan Thorpe rowan@rowanthorpe.com wrote:
Hi, ..[snip]..
...just adding a couple of explanatory details I missed in my last email. I'm sure you already know this so I just add it for reference, to preempt clarifying my processes by dialogue later.
..[snip].. either way. Regarding algo, the go-to scheme I am using for various things at the moment is bcrypting server-side (with crypto-grade random salt and tuning the rounds for the server) for the obvious reasons, and for web-interface code doing bcrypt of the password client-side in javascript where possible too - so the server will only be hashing the received hash-with-salt, and the client can know they are not even trusting the server with their password. Considering the philosophical basis of Coquelicot that seems a particularly relevant approach...
...of course client-side hashing needs reproducability so it needs a static or repeatable salt within the javascript...
..[snip].. If you think bcrypt/random-salt/etc is overkill (server- and/or client-side), then in addition to agreeing that at least SHA256 is a good idea, using HMAC-SHA256 with static salt specified in the config-file would be useful to mitigate potential rainbow-attacks.
...or a randomly generated salt, but prepending/appending it to the stored hash for reuse, in the style of bcrypt...