Litedb: SHA1 for password verification

[ANBlue]

Hi, i have seen that for password verification LiteDB uses SHA1, but this hashing algorithm is weak...

it would be possible to make that a developer who uses liteDB can specify a hashing algorithm in the constructor of LiteDatabase class? perhaps through a class that implements a specific interface?

Thank you

(sorry for my english)

[mbdavid]

Hi @ANBlue, is SHA1 weak? I didn't know about this. There is any other better? Maybe it's possible create more than 1 implementation about this.

[ANBlue]

https://www.bentasker.co.uk/blog/security/201-why-you-should-be-asking-how-your-passwords-are-stored
https://nakedsecurity.sophos.com/2012/12/09/sha1-brute-force-trimmed-21-percent/

the two links above explain why it is better not to use the sha1 for password storage/verification

better algorithms are:

https://en.wikipedia.org/wiki/Bcrypt
https://en.wikipedia.org/wiki/Scrypt

[kuiperzone]

Yes, SHA1 is obsolete. SHA256 is a better alternative as the default. Having an overload to specify your own hash would be a good option also.

[DeanVanGreunen]

Bcrypt and scrypt should be used instead as it is stronger than sharing
family set for cryptography
On Jan 6, 2017 1:36 AM, "Kuiper" [e-mail] wrote:

Yes, SHA1 is obsolete. SHA256 is a better alternative as the default.
Having an overload to specify your own hash would be a good option also.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/mbdavid/LiteDB/issues/409#issuecomment-270789780, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AVQ2C6TATrMDL17bZsQE9qbftjLKpqoRks5rPX5wgaJpZM4LZRpG
.

[kuiperzone]

Actually, I would agree.

https://rietta.com/blog/2016/02/05/bcrypt-not-sha-for-passwords/

http://security.stackexchange.com/questions/26245/is-bcrypt-better-than-scrypt

[DeanVanGreunen]

I write government software which requires high security and verification.

Which leaves myself to use 4096bit RSA private public key pair encryption
and bcrypt for verification.

This is my security recommendation.
On Jan 6, 2017 2:06 AM, "Kuiper" [e-mail] wrote:

Actually, I would agree.

https://rietta.com/blog/2016/02/05/bcrypt-not-sha-for-passwords/

http://security.stackexchange.com/questions/26245/is-bcrypt-
better-than-scrypt

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/mbdavid/LiteDB/issues/409#issuecomment-270794573, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AVQ2C0dk1VXXqaygteoHAroyzq0JZSbtks5rPYVvgaJpZM4LZRpG
.

[mkosieradzki]

I think it might be a good idea just to use what Microsoft thinks is safe (PBKDF2 with HMAC-SHA256, 128-bit salt, 256-bit subkey, 10000 iterations) and it's FIPS compliant:
This implementation is really easy to port
https://github.com/aspnet/Identity/blob/dev/src/Microsoft.AspNetCore.Identity/PasswordHasher.cs

[mbdavid]

Hi @mkosieradzki, I like this "simple" solution :) I will read more about it, thanks.

[ronnieoverby]

@mbdavid Yes, SHA1 was recently proven weak: https://security.googleblog.com/2017/02/announcing-first-sha1-collision.html

I was curious about your security implementation, so I briefly looked around the code.

I see that you store a SHA1 hash in the header page for verification to quickly feedback to caller that a password is wrong, rather than catching a decryption failure later on when reading/writing data. Correct?

Apart from that it seems you are already using PBKDF2 (Rfc2898DeriveBytes) for deriving the AES key from the password:
https://github.com/mbdavid/LiteDB/blob/944466cd6948e33433e0dc74f2c6a3001333ea4e/LiteDB/Utils/AesEncryption.cs#L25

So, while a malicious user may be able to supply a password that will result in a hash collision, decryption should still fail because you derive the AES key using Rfc2898DeriveBytes. With that, it doesn't _seem to me_ that the SHA1 verification is really hurting anything. (someone double check me!)

However, you should shift your attention to other encryption concerns. I'll create separate issues for them.

[elyoh]

The SHA1 hash of the password is not secure.
Any two data bases with the same password will have the same SHA1 hash. Thus this leads to collisions.

Hashing the key generated by a suitable PBKDF would be slighly better, as the chances of collision is far reduced. However, I would still not recommend that as it still provides an attacker with a short cut to verfiying a key. The only acceptable solution is to switch to authenticated encryption using an EtM approach.

[AntiTcb]

Are there still plans for a secure password encryption algorithm to be used replacing the current SHA1 functionality for the next appropriate version?

[mbdavid]

Hi @AntiTcb , it´s on my plans change this. But to make it possible, I will need change datafile structure, and it's not easy job remove this compatibility. The next major version is likely to change this file structure and I will take advantage of this to fix some old decisions.

[zer0x64]

Hi! Quick note that the SHA1 is also referenced here:
https://github.com/mbdavid/LiteDB/issues/586

Basically, the SHA1 should be completely removed and use only the current PBKDF2 key derivation. However, I DO agree that it would be great to have settings to replace the PBKDF2. The current standard for local data hashing is argon2 (the winner of the Password Hashing Contest, used by Keepass, for example). However, Scrypt and Bcrypt are also pretty valid options(as they are resistant into GPU). PBKDF2 is not "bad", but it's not the greatest either, and people would surely like to have better options.

TL;DR: Linked ticket suggest removing the password validation and replace it with a Mac, which would be a better option cryptographically-wise. The Key Derivation Function(currently PBKF2) could be made a settings for people who would like stronger/customizable options(argon2, scrypt, bcrypt).

Also, I can help with all that stuff if you need it :)

[lbnascimento]

Hi! With the objective of organizing our issues, we are closing old unsolved issues. Please check the latest version of LiteDB and open a new issue if your problem/question/suggestion still applies. Thanks!