Re: [Coquelicot] Patchset: add multiuser/pass auth module, add missing i18n tags, add Greek .po
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.
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.
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.
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...
Rowan Thorpe via Coquelicot:
..[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...
The threat model of Coquelicot assumes that if the server is compromised, it can send the Javascript code it wants. To follow its current model where the file is encrypted upon reception file the server, I think it's fine to go for the easy way for the upload password as well.
I'm working on a new release. I've used the bcrypt gem for the userpass authentication mechanism in the end.
-
Lunar -
Rowan Thorpe