[OWASP_PHPSEC] Is storing static salt in database a good idea ?

Shivam Dixit shivamd001 at gmail.com
Thu Sep 5 06:12:16 UTC 2013

Hello Rahul,

Thanks for explaining me the point. I would like to discuss on few key
points. I would take them one by one from start.

We all are clear with the reason that why we need to *hash* passwords
before storing them in database. Next point is that even when we are
storing hashed password if someone get access to our database he will be
able to see the hashed passwords and he can easily lookup in *rainbow
table* corresponding
to that hashing algorithm. As quoted on *Stack Overflow* :

"frameworks such as OpenCL <http://en.wikipedia.org/wiki/OpenCL> and
CUDA<http://en.wikipedia.org/wiki/CUDA> can
be leveraged in order to massively accelerate the operation of hash
algorithms. Run oclHashcat <http://hashcat.net/oclhashcat-lite/> with a
decent graphics card and you can compute an excess of 10,000,000,000 MD5
hashes per second"

As computational power is increasing so is the database of "Rainbow
tables", hence it is*very insecure to just store hash*. So we will add a *salt
to the password*, now if salt is just a static 10-15 digit string and
attacker comes to know about it along with database access, he can generate
a Rainbow Table of his own for that (salt + different_combinations) and can
easily compromise security of thousands of users that are present in that

Hence it is necessary to generate dynamic salts for each user and store
them in database. So even if the attacker has access to database he will
not be able to reverse lookup passwords because even though he knows
dynamic salt but he still does not has static salt which is securely stored
in configuration file and not in database.

*My point is*, even if an *attack takes place* and attacker gains just
database access there is really no need *change the value of static
salt *because
it is still kept secured inside configuration file.  I find no valid reason
for changing static salt *except when* the configuration file is itself
compromised which is worst scenario (if he has file level access then he
can delete them also !!)

Also, I find no good reason for storing the hashing algo in the database
until and unless we are using different hashing algo for different users in
one single application (which is generally not the case).

Imagine a scenario in which attacker has database access but there are *only
two columns*related to passwords in the db, one is the *salt* and other is
the *hash* itself. Firstly, he will have to figure out which hashing
algorithm is used which *might be a tedious task, definitely more tedious
than by just looking at some column *(though I am not sure that if we can
determine hashing algorithm used just by looking at hash generated, if you
know any such method then please share with us), secondly even if attacker
comes to know which hashing algorithm is being used he can practically
fetch nothing out of that database until and unless he comes to know about
the *static salt*, which is inside a secure file. This is the main reason
of using static salt.

I was thinking that can we further thwart the process of reverse look up ?
For example, I have just one column in the database. In that column, first
30 digits will contain the actual hash and last 20 will contain the salt
(just random assumption for illustration purpose). In this case if attacker
gains database access, he will have no clue of hash algorithm , no clue of
hash, no clue of salt (until and unless the attacker is database manager !
). So it will essentially increase one more step for attacker
in determining reverse hashes. I read this method somewhere on the internet
and I am not sure about efficiency / reliability of this method.

I hope I answered all your questions.

NOTE: All the above conclusion are made by me after going through various
articles on OWASP, stack overflow etc. My thinking/assumptions might be
wrong in above explanations. Please correct me if so. *Learning is the main
goal of working with an Open source community* !

On Wed, Sep 4, 2013 at 3:55 AM, rahul chaudhary <
rahul300chaudhary400 at gmail.com> wrote:

> ok...so you must know the reason why I stored static salt in DB in the
> first place.....since static salt was a user defined value and I thought
> that if someone changes the static salt later at some point, the whole
> application will break down....so to save this thing, I also stored static
> salt in the DB, so that even if the developer changes the salt at some
> point (like after some attack) , the application wont fail, it would just
> start storing new hashed with the new salt and would get the old hashes
> with the old salt.
> So, if everyone will vote-up that static salts must not be stored in the
> DB, then I will change that. :)
> However, the point you stated that if DB is compromised. that point is
> perfectly genuine and legit. So, this is definitely a point worth
> discussing. ^_^
> On Tue, Sep 3, 2013 at 7:32 AM, Abbas Naderi <abiusx at owasp.org> wrote:
>> Yes
>>      ______________________________________________________________
>> *Notice:** *This message is *digitally signed*, its *source* and *
>> integrity* are verifiable.
>> If you mail client does not support S/MIME verification, it will display
>> a file (smime.p7s), which includes the X.509 certificate and the signature
>> body.  Read more at Certified E-Mail with Comodo and Thunderbird<http://abiusx.com/certified-e-mail-with-comodo-and-thunderbird/> in
>> AbiusX.com
>> On Sep 3, 2013, at 6:12 AM, Shivam Dixit <shivamd001 at gmail.com> wrote:
>> On Mon, Sep 2, 2013 at 9:47 PM, Abbas Naderi <abiusx at owasp.org> wrote:
>>> Hi Shivam,
>>> Good point.
>>> We need to move the static salt to the library as a static confidential
>>> string object.
>>> Thanks
>>> -Abbas
>> Hello Abbas,
>> Shall I file an issue on github for this problem also ?
>> *Cheers,*
>> *Shivam*
>> _______________________________________________
>> OWASP_PHP_Security_Project mailing list
>> OWASP_PHP_Security_Project at lists.owasp.org
>> https://lists.owasp.org/mailman/listinfo/owasp_php_security_project
> --
> Regards,
> Rahul Chaudhary
> Ph - 412-519-9634

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.owasp.org/pipermail/owasp_php_security_project/attachments/20130905/01a5eeca/attachment.html>

More information about the OWASP_PHP_Security_Project mailing list