Codimd: Support local signin

[jackycute]

There might be some users not using any services we used to do a third-party auth.
So we need a local signin solution, currently we're using passport as the auth middleware.
Then using passport-local to support this will be the best.

[ccoenen]

I would like to request putting this back onto an agenda (i.e. assign a milestone to it). I believe this to be of major importance for a self-hosted tool.

[jackycute]

OK, I would like to add this back in track, but only for self-hosted usage.

Because holding password is a high risky and complex behavior, official service won't enable this feature.

[ccoenen]

"self hosted only" is fine with me, that's exactly my use-case :)

Can I somehow help? Ideally you'd store not the password but a bcrypt (more widely known) or scrypt (more recent, supposed to be stronger) hash. That way, If anything _did_ happen to the database, there's very little value in the password hashes themselves.

[jackycute]

We use passport.js to auth our users.
So this package will be needed to register and login https://github.com/jaredhanson/passport-local
Also need some UI for login and config to enable/disable this feature.

[ccoenen]

I'm trying to find documentation on how they store passwords, their bcrypt examples seem to have vanished. At the moment it _looks_ to me as if they'd actually store them in plain text which would be extremely bad. But I might well be wrong, given that I've never used their code before.

[jackycute]

I found that too, plaintext won't be acceptable.
But I also find few examples using bcrypt or scrypt to store password (expected using salt too).
Seems like we need to build our own way to save them safely.

http://blog.robertonodi.me/node-authentication-series-email-and-password/
https://github.com/saintedlama/passport-local-mongoose
https://gist.github.com/debrouwere/a46dec73629c71706809

[ccoenen]

Aah! Looking at them now!

One of the nice things about the two functions is, that they implement salting along the way! No need to add this yourself. You get a long twisted thing back, that also contains information on how strong it has been hashed and its salt value. There's a more detailed answer.

Example 1 uses pbkdf2 which is a little bit dated, but better than nothing.

Example 3 hashes passwords here: https://gist.github.com/debrouwere/a46dec73629c71706809#file-passport-js-L44
and verifies passwords here: https://gist.github.com/debrouwere/a46dec73629c71706809#file-passport-js-L53-L59

This looks like the way to go, to me.

[timonsku]

I would also like to express my support for this feature. An absolute necessity for locally hosted instances.

[jackycute]

Supported in a73d9ce39e2107b2a9628003f05900d4a641bee5

[Joe136]

I have removed all social-auth methods and set "email": true. Then there was no Sign in-button anymore.

[jackycute]

Hi @Joe136,
Oops, missed that, thanks for heads up.
Fixed in ecb956f515a4a9fc661e0724d694fc1ed093dcaa

[Joe136]

Thanks

[Joe136]

Hi,
when I type my email and password and press enter while the focus is in the password field, he tries to 'Register' me; normally I expect to 'Sign in'.

[jackycute]

As you wish in 00e284584ecb88d70201f59f677851bd68f1e218

[Joe136]

Thanks, rotating them looks great as well.

[marmistrz]

What's the problem storing a sha256sum (or any other hash function we believe is preimage-resistant) of the password?

[SISheogorath]

@marmistrz The reasoning is simple: You can't steal data we don't have.

So when logins are out sourced to GitHub, Twitter, … the only thing an attacker can steal are session tokens. Not more.

But please notice how old this issue is. CodiMD supports local logins and stored passwords using scrypt. But if you are interested in contributing, local users still need a lot of work especially when it comes to management. So feel free to have a look at #272 and #314. PRs are welcome :)

[ccoenen]

@marmistrz please do not ever store passwords just as a hashed value. This is quite simple to circumvent. Sha256 (and others) are designed to be very fast, so you can also run them in parallel on things like graphics cards. Brute forcing something as short as most passwords will cost you a few hundred bucks on AWS or similar services.

bcrypt and scrypt are intentionally designed to be slower.

Topic you might want to read up on:

• salting / peppering
• rainbow tables

This article here is a good start: https://www.wired.com/2016/06/hacker-lexicon-password-hashing/

[marmistrz]

@ccoenen I thought that the password ought to be salted is so obvious that it needn't be stated :)
If you add 128 bits of nonce as salt, that should be enough to stop even sha256 rainbowing, I think.

[ccoenen]

In my experience, it is very dangerous to rely on obviousness in security. I once opened an issue in a password manager, where the passwords were "encrypted" to the email address (which was stored in the same database).

Please forgive me, if this came off a little strong.

Long story short: why are we even talking about this? This issue has been closed/implemented 18 months ago. With a _better_ solution (scrypt was specifically designed for passwords, and mitigates attacks that would work on sha* hashes).