Hi,
On 16 December 2016 at 14:00, Lunar lunar@anargeek.net wrote:
Hi Rowan,
Months have passed since your patch. Seems life keep getting in the way. Please accept my apologies, and thanks again for your contributions.
Anyway, I like your new authentication method but I felt a bit uneasy when I read:
+++ b/conf/settings-userpass.yml
- abdul: "0873d391e987982fbbd3a94a8fe5ccb19ba61c4c"
- # SHA1 of the pre-shared password
I think the SHA1 pre-shared password was good enough for “simplepass” because an attacker would not learn much. But once access starts to be tied to specific users, I'd rather have something that would resist a bit more if credentials were stolen.
Yes, I agree. I thought similarly when I hacked the simplepass method into the userpass one, but I decided to err on the side of cloning simplepass as much as possible for doing a simple POC, with minimal diff for quick readability (I can see you are busy with many other projects...), and to see what you think before worrying about making it more production-friendly.
Would you be ok if I'd rework the patch to use String#crypt? The code could eventually fall back on the unix-crypt gem to support more platforms if required.
Of course if you want to rework the patch go for it - I expect that for at least the next month I wouldn't have time to try it myself 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... FWIW: I briefly investigated scrypt for another project recently but it seems for small inputs (like passwords) bcrypt is still a better choice, in addition to being more mature. 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. If you also don't find time to do this, when I get a chance after a month or two I will try to give it a go myself.