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

Shivam Dixit shivamd001 at gmail.com
Thu Sep 5 11:38:10 UTC 2013

Thanks Rahul. *I am glad that you liked my suggestions *!! :)

Regarding your second point, I am sorry but I din't get you as I am not
totally aware of the functionality, what exactly you mean by "*a function* *to
change their password to suit new hashing algo?"* Can you bit elaborate on
this ? And can you make more clear what is term "user", by users you mean
to say actual users of the application which is developed using these
libraries or users are the developers of application ?

Regarding last point, we definitely need opinions of other people to guide
us on this. However I was thinking that we can store *complete hash* *(not
just part) + salt combined into one column*. By storing complete hash we
can get rid of extra COLLISIONS which might occur if we just use part of
hash. I am not sure if it is really helpful.

On Thu, Sep 5, 2013 at 11:07 AM, rahul chaudhary <
rahul300chaudhary400 at gmail.com> wrote:

> Wow Shivam...long email ... ^_^...but very detailed and
> informative....nice!!! :)
> So your point is valid and now I see the picture more clearly...definitely
> the static salt must not be stored...I will make the necessary changes for
> that...
> About storing hashing algo, I am not sure....because when we were
> implementing the libraries, we thought that users must have the choice of
> using different algo and they must have the power to change the algo at any
> moment....*so what we can do is we can remove the algo from the DB, and
> then we can  provide a function that forces all the users to change their
> password to suit the new hashing algo...*
> The last point of storing hash and salt in same column is a good point and
> I am considering it...but we have to ensure that *HASHING COLLISION* does
> not occur as we are essentially storing some part of hash....but as you
> pointed out, the benefits of doing so is great!!....*lets call Abbas and
> others into this as he can enlighten us on this better...*
> On Wed, Sep 4, 2013 at 5:01 AM, Shivam Dixit <shivamd001 at gmail.com> wrote:
>> 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.
>> 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 database.
>> 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* !
> --
> 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/a104b44e/attachment.html>

More information about the OWASP_PHP_Security_Project mailing list