On Jan 20, 2010, at 1:13 PM, Daniel Carrera wrote:
> Hello,
>
> I was just reading this page:
>
> http://www.fossil-scm.org/index.html/doc/tip/www/password.wiki
>
> Under the section "Web Interface Authentication" it says:
>
> "The user password is sent over the wire as cleartext on the initial
> login attempt. The plan moving forward is to compute the SHA1 hash of
> the password on the client using javascript and then send only the
> hash
> over the wire, but that plan has not yet been set in code."
>
>
> This idea will do absolutely nothing for security. Anybody who would
> intercept the password could just as easily intercept the password
> hash.
> Then he can login by sending the hash, without having to know the
> password.
No, it does add to the security. The idea is that many users will
have the same password for multiple accounts. (It is widely known
that this is a bad practice, but people still do it.) So while a
snooper could intercept the hash and log into your Fossil account,
they wouldn't be able to log into different Fossil repositories, or
your gmail account, or your Bank of America account.
>
> The CORRECT way to handle web authentication is to use HTTPS. This
> is a
> well-designed standard that actually does provide a reasonable
> amount of
> privacy between client and server.
>
>
> Elsewhere in the documentation I read about the move from clear text
> passwords to SHA1 hashes. Although this is no doubt an improvements,
> please know that SHA1 hashes are not a good way to secure passwords.
> Anybody can make a large database of common passwords, calculate the
> SHA1 hash of each password, and compare the hashes.
If you read more closely, you will see that the SHA1 hash is of the
Fossil project ID, the user name, and the password. This means that
the dictionary attack you describe won't work. It also means that if
a single user has the same password on multiple Fossil projects,
nobody (but that user) will know because the hash is different each
time. It also means that if two users on the same project happen by
chance to select the same password, nobody will know because, again,
the hashes will be different.
>
> The CORRECT way to store passwords securely is using the PBKDF2
> standard
> (Password-Based Key Derivation Function version 2) found in RFC
> 2898. To
> save you the trouble, I'll show you a simple implementation using
> SHA1.
>
> Basically, you want every user to have a unique (or nearly unique)
> salt.
> Just generate a random number (it doesn't matter if it's random). Then
> put the salt and password through the following function:
>
> // PBKDF2 function from RFC 2898
> // Using HMAC(SHA1) as the Pseudo-Random function.
> function pbkdf2( $pass, $salt, $count = 1000, $kl = 32) {
> $hl = 40; # SHA1 hash length
> $kb = ceil($kl / $hl); # Key blocks to compute
> $dk = ''; # Derived key
>
> # Create key
> for ( $block = 1; $block <= $kb; $block ++ ) {
>
> # Initial hash for this block
> $ib = $b = hash_hmac("sha1", $salt.pack('N', $block),$pass,
> true);
>
> # Perform block iterations
> for ( $i = 1; $i < $count; $i ++ )
>
> # XOR each iterate
> $ib ^= ($b = hash_hmac($algo, $b, $pass, true));
>
> $dk .= $ib; # Append iterated block
> }
>
> # Return derived key of correct length
> return substr($dk, 0, $kl);
> }
>
>
> Cheers,
> Daniel.
> _______________________________________________
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
D. Richard Hipp
d...@hwaci.com
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
