note 87692 added to function.sha1
| From: | ranko84 at gmail dot com | Date: | Wed, 17 Dec 2008 04:11:11 +0000 |
| Subject: | note 87692 added to function.sha1 | ||
| Groups: | php.notes | ||
| Request: | Send a blank email to php-notes+get-148240@lists.php.net to get a copy of this message | ||
Small update..., well more like fix to the obscure function, replace
<?php
if ($keepLength != NULL)
{
if ($hSLength != 0)
{
$hPassHash = substr($hPassHash, $hLPosition, -$hRPosition);
}
}
?>
with
<?php
if ($keepLength != NULL)
{
if ($hSLength != 0)
{
if ($hRPosition == 0)
{
$hPassHash = substr($hPassHash, $hLPosition);
}
else
{
$hPassHash = substr($hPassHash, $hLPosition, -$hRPosition);
}
}
}
?>
I've been getting few requests to explain how it's used so, this might be little long.
Problems:
1. In most solutions with hash and salt, you were bound to have one extra row in your database that
would state, preferably random, salt for that hashed data. If attacker would manage to get drop of
your database he would get hashed data and salt that is used with plain data to make it obscure, and
then cracking that hashed data would be same as if you didn't add any salt to it.
2. I stumbled upon some functions that would hash data, then input salt into random places in hash
and store it in database, but they would still have to write down random parameter used to scramble
salt so they could reuse it when validating data. Getting simple database drop wouldn't help
much here, but if they would manage to get their hands on obscuring function too, they could easily
see what is salt and what hash.
Solutions:
1. Why use extra row to store salt when you can input it in hash. I'm not sure how attackers
determine what type of hash are they facing, but I guess it has connection to hash length. In that
case, why make attackers job easier and store in database data_hash+salt where they could assume
just by it's length it has salt in there.
Reason behind $keepLength. If it's set to 1, strlen of hashed data plus salt would be equal to
strlen of hashed data leading attacker to believe there is no salt.
If you leave $keepLength on NULL, strlen of final result would be
strlen(used_hash_algorithm)+$hSLength.
$minhPass is there to reserve enough place for string that has to be hashed, so someone using this
function wouldn't accidentally delete it by setting too high salt length ($hSLength), for
example... if you set it 30000 it will keep working normal.
2. If you think about it, constant, but variable value when making input would be same data that is
being input.
In case we're trying to hash password, and have user A with password "notme",
password strlen equals to 5, and if we use default parameters of the function, with $keepLength set
to 1, process would be:
random salt, hash it, add first 5 characters of hashed_salt at beginning of plain password, add last
5 characters of hashed_salt at end of plain password, hash it. Replace first 5 characters of
hashed_password with first 5 character of hashed_salt, do same with last 5 characters of
hashed_password, return hashed_password.
In case that string is longer than 10 characters function would use simple mathematics to reduce it
to numbers lower than 10, well... lower than number that is stated in $hSLength.
And good thing is that every time user enters correct password it has same length so it's not
necessary to write it anywhere.
So what is achieved in the end?
1. Attacker might not know that hash is salted, and you don't have that extra row in your
database stating THIS IS SALT FOR THIS HASH.
2. If he does find out that it is, he wouldn't know what is hashed password and what is salt.
3. If he manages to get access to obscure function, only thing that might help him is value of
$hSLength, where if $hSLength is set to 10 he would have to crack 10 variations of hashed string
since he doesn't know how long password of user he's trying to crack is.
For example first variation would be hashed_password without last 10 characters, second variation
would be hashed_password without first character and last 9 characters...
4. Even in case he has enough power to crack all 10 variations, resulting string that he might get
doesn't necessarily has to be exactly long as password of original user in which case, attacker
fails again.
----
Server IP: 69.147.83.197
Probable Submitter: 78.134.129.201
----
Manual Page -- http://www.php.net/manual/en/function.sha1.php
Edit -- https://master.php.net/note/edit/87692
Del: integrated -- https://master.php.net/note/delete/87692/integrated
Del: useless -- https://master.php.net/note/delete/87692/useless
Del: bad code -- https://master.php.net/note/delete/87692/bad+code
Del: spam -- https://master.php.net/note/delete/87692/spam
Del: non-english -- https://master.php.net/note/delete/87692/non-english
Del: in docs -- https://master.php.net/note/delete/87692/in+docs
Del: other reasons-- https://master.php.net/note/delete/87692
Reject -- https://master.php.net/note/reject/87692
Search -- https://master.php.net/manage/user-notes.php