password hashing

[Jérôme Pinguet]

Hello!

SHA-1 (used by FMF in /libs/utils/global.cpp to hash password) is a
message digest, not a secure password hashing algorithm.

Back in 2010: "A German hacker has successfully cracked a six-character
implementation of the 160-bit SHA-1 crypto algorithm using a cloud
computing resource. The hack was completed in 49 minutes at a cost of
just $2.10."
http://www.infosecurity-magazine.com/view/14059/sha1-crypto-protocol-cracked-using-amazon-cloud-computing-resources/

A better password hashing algorithm is scrypt:
https://github.com/technion/libscrypt

Is there a plan to use the password to encrypt MySQL or SQLite
databases? :-) Good candidate for sqlite: http://sqlcipher.net/

Best regards,

jerome

[Eric Maeker]

Le 25/07/2014 08:29, Jérôme Pinguet a écrit :
> Hello!
>
> SHA-1 (used by FMF in /libs/utils/global.cpp to hash password) is a
> message digest, not a secure password hashing algorithm.
>
> Back in 2010: "A German hacker has successfully cracked a six-character
> implementation of the 160-bit SHA-1 crypto algorithm using a cloud
> computing resource. The hack was completed in 49 minutes at a cost of
> just $2.10."
> http://www.infosecurity-magazine.com/view/14059/sha1-crypto-protocol-cracked-using-amazon-cloud-computing-resources/

Ok thanks for the hint. I'll check this.

> A better password hashing algorithm is scrypt:
> https://github.com/technion/libscrypt
>
> Is there a plan to use the password to encrypt MySQL or SQLite
> databases? :-) Good candidate for sqlite: http://sqlcipher.net/

Nop, the current option is to encrypt the hard drive or partition
containing the databases (SQLite/MySQL/PostGre) instead of crypting each
entries in the db.

May be someone can write a small doc for such a configuration on the wiki?

--
Eric Maeker
GPG: C217 B1B7 80E8 0381 FD5B C3A5 75D4 AE85 B952 0933

[Jérôme Pinguet]

Encrypting the disk or the partition that contains the SQLite database
is a very good idea indeed, probably far superior in terms of security
to encrypting only the SQLite database itself.

It can easily be done on Linux using either full disk encryption (an
option available during installation of Debian or Ubuntu, using
LUKS/cryptsetup) or transparent home encryption using the login password
(ecryptfs). Both levels can be combined, and set up after installation.

Full disk encryption is quite easy on MacOS X (FileVault) and can be
also be used on Windows (BitLocker), despite recent proofs that every
Microsoft encryption scheme is broken because of US government backdoors.

It can be applied to a MySQL server which would be on the same computer
as FMF.

The problem is different for a separate MySQL server used in a network
setting. Full disk encryption means that any reboot (power failure,
kernel security updates) requires the physical presence of the sysadmin
to type the password on a keyboards directly connected to the server. A
solution like Mandos https://wiki.recompile.se/wiki/Mandos can mitigate
the need for full time sysadmin availability: the rebooting main server
takes the GPG encrypted keys from another small server (could be a
raspberry pi) in the same network through TLS. But it gets complicated
and costly for small networks.

Encryption at the MySQL server (full disk or AES_ENCRYPT inside MySQL)
level only means that connections towards the MySQL server need to be
encrypted too. One can use SSH tunnels to forward MySQL ports over a
network. I've set this up on several networks for medical practices. The
SSH tunnels allow for secure connections even during house calls, or
enable the practitioner to access patient's data and work from home.

So, for the separate MySQL server, encryption of database content could
be a good feature worth adding to the roadmap.

For SQLite, sqlcipher.net announces a loss of speed of only 5% to 15%.

For MySQL, it would be wiser to implement encryption before data is even
sent to the MySQL server. As we've seen with recent requests, lots of
users will be tempted to use externalized MySQL servers rather than
setting one up locally under locked doors. Thus, beginning to think
about encryption is a good idea before FMF spreads to the whole world!
;-) It would also help us get approval by certification agencies.

Eric, in your opinion, what would make it difficult to AES encrypt (with
symmetric 128 bit key) data before it is sent and stored on MySQL (or
SQLite) in the present state of FMF code? Is there a lot of work done at
the database level, such as column ordering or row sorting? I admit it's
a bit difficult to sort encrypted data at MySQL or SQLite level! :-)

I hope I can advance my study of C++ and cryptography quickly enough to
code such improvements myself. Maybe for version 1.1 in 2015? :-)

jérôme

[Eric Maeker]

Le 26/07/2014 02:50, Jérôme Pinguet a écrit :
> On 25/07/2014 22:04, Eric Maeker wrote:
>> > Le 25/07/2014 08:29, Jérôme Pinguet a écrit :
>>> >> Hello!
>>> >>
>>> >> SHA-1 (used by FMF in /libs/utils/global.cpp to hash password) is a
>>> >> message digest, not a secure password hashing algorithm.
>>> >>
>>> >> Back in 2010: "A German hacker has successfully cracked a six-character
>>> >> implementation of the 160-bit SHA-1 crypto algorithm using a cloud
>>> >> computing resource. The hack was completed in 49 minutes at a cost of
>>> >> just $2.10."
>>> >> http://www.infosecurity-magazine.com/view/14059/sha1-crypto-protocol-cracked-using-amazon-cloud-computing-resources/
>> > Ok thanks for the hint. I'll check this.

The main problem was that Qt4.x does only include Md4, Md5 and SHA1
hashing methods. Qt5 introduces many more (SHA256).

Qt4.8 (default Qt version in wheezy & still in sid)

http://qt-project.org/doc/qt-4.8/qcryptographichash.html

Qt5.3 (available in wheezy and sid)

http://qt-project.org/doc/qt-5/qcryptographichash.html

The password hash are stored in the FMF user database.
We can store password in a prefixed string like this:

<sha1-hash> // for old compatibility
<method>:<method-hash> // updated password hash

Eg:
sha256:<sha256-hash> // updated sha256
sha512:<sha512-hash> // updated sha512

I open a google code issue for the discussion with some "tags" in the code:

https://code.google.com/p/freemedforms/issues/detail?id=366