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 a73d9ce

[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 ecb956f

[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 00e2845

[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).