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

Minhaz A V minhazav at gmail.com
Thu Sep 5 21:07:36 UTC 2013


Shivam, you have pointed out some nice points!!
Rahul, I would like to know how are you planning to implement a feature to
change hashing algo ? Also would you implement *a function* *to change
their password to suit new hashing algo?*
Also feeding *complete hash + salt *to same column seems a better method to
slow down reverse lookup by attacker
*
*
*
*



On Thu, Sep 5, 2013 at 5:08 PM, Shivam Dixit <shivamd001 at gmail.com> wrote:

> 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
>>
>
>
>
> --
> *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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.owasp.org/pipermail/owasp_php_security_project/attachments/20130906/fc87d60d/attachment-0001.html>


More information about the OWASP_PHP_Security_Project mailing list