[OWASP_PHPSEC] Is storing static salt in database a good idea ?
rahul300chaudhary400 at gmail.com
Thu Sep 5 05:37:53 UTC 2013
Wow Shivam...long email ... ^_^...but very detailed and
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
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* !
Ph - 412-519-9634
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OWASP_PHP_Security_Project