[DragonFlyBSD - Bug #2430] Alternate Password Hash method

[Robin Carey via Redmine <bugtracker-admin@xxxxxxxxxxxxxxxxxxxxx>]

Issue #2430 has been reported by Robin Carey.

----------------------------------------
Bug #2430: Alternate Password Hash method
http://bugs.dragonflybsd.org/issues/2430

Author: Robin Carey
Status: New
Priority: Normal
Assignee: 
Category: 
Target version: 


Dear DragonFlyBSD-bugs,

I submitted a bug-report recently with regard to using SHA3 as a Password
Hash method (replacing
the current SHA2 method used in DragonFlyBSD). I don't want to create
noise, but I thought I should
clarify some points, and propose an alternate method.


The reasons I suggested replacing DragonFlyBSDs' SHA2 method with SHA3 was
because:

1) The SHA3 algorithm has only just recently been approved and publicly
released by NIST after
    a lengthy competition etc.
2) I read an article on Slashdot (www.slashdot.org) (search for:
openwall/"John the ripper"; the
    article is called "John the Ripper Cracks Slow Hashes On
GPU<http://linux.slashdot.org/story/12/07/04/1922244/john-the-ripper-cracks-slow-hashes-on-gpu>")
which concluded that
    SHA2/512-bit is not-very-good/obsolete. Here are some relevant excerpts
from the article:


"...Personally, I think that bcrypt and SHA-crypt are quite close to
becoming obsolete in favor of something new, yet right now I would still
recommend moving to bcrypt as the most suitable pre-existing password
hashing method."

"....So far, SHA-crypt at its default rounds=5000 is crackable on a GPU at
more than 10x the speed of bcrypt at comparable settings ...."


Note: I assume the above refernece to "bcrypt" means using the Blowfish
block-cipher to hash passwords (OpenBSD).

------------------------

The main point I wish to clarify is this:

The most important point is not the speed of the algorithm (e.g.
SHA2/SHA3/bcrypt),
but the size of the salt. The purpose of the salt is to ensure that on i.e.
two
different DragonFlyBSD systems, the same password will hash to two different
hashes (by virtue of the random salt, which is different for every
DragonFlyBSD
host/installation).

Since in todays world a 128-bit symmetric key is considered to be secure
and safe for the foreseeble future, a 128-bit salt (used for hashing
passwords)
would thwart any brute-force attempt.

If you're feeling a little paranoid you could use a 192-bit or 256-bit
salt/key (this
is what the US Government requires for highly sensitive data (AES)).

------------------------

Now, on to the alternate Password Hashing method I wish to propose.

This method is completely original, not used by Linux or *BSD, and also is
backed up by academic procedures (and international standards), which
can all be referenced on Wikipedia (www.wikipedia.org).

Instead of using SHA2 or SHA3 to hash the password, use a MAC
(Message Authentication Code). A MAC algorithm takes a secret key
and an arbitrary amount of data to create the MAC/code. The MAC/code
will represent the password hash (stored in the password file on the
DragonFlyBSD OS/Host). The MACs' secret key will take a random
(and unique) salt, which is different on every DragonFlyBSD host/
installation. And the data fed into the MAC wil be the (users) password.

Instead of using any existing MAC algorithm, I propose using AES
to make the MAC algorithm (Note that AES is an encryption standard
established by the US NIST).

ISO/IEC 9797-1 <http://en.wikipedia.org/wiki/ISO/IEC_9797-1> *Mechanisms
using a block cipher;* This ISO/IEC
standard is a way to create a MAC using a block-cipher. AES is the
best choice of algorithm/block-cipher to use (due to NIST). I would
propose the use of Specific Algorithm; MAC Algortihm 1 (because
it uses one key).

The only problem I anticipate with the above implementation would
be the limited size of the MAC/Code; 128-bits (the block-size of AES).
But, since AES is based on Rijndael, when implementating the above
system, it would be possible to revert to the original Rijndael block-
cipher and increase the block-size to the maximum of 256-bits.
This is possible because AES is just a variant of Rijndael, and the
original Rijndael allows a key-size and block-size of any multiple of
32-bits up to a maximum of 256-bits.



-- 
Sincerely,

Robin Carey BSc


-- 
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account