[Coquelicot] Patchset: add multiuser/pass auth module, add missing i18n tags, add Greek .po

[Rowan Thorpe]

Hi,

On 16 December 2016 at 14:00, Lunar <lunar at 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.

-- 
Rowan Thorpe
PGP fingerprint:
 BB0A 0787 C0EE BDD8 7F97  3D30 49F2 13A5 265D CCBD
----
"A riot is the language of the unheard." - Dr. Martin Luther King