Difference between revisions of "Talk:Hashing Java"

From OWASP
Jump to: navigation, search
(General Discussion)
Line 9: Line 9:
 
#Iterations of at least 1000 times seemed a bit excessive, but it is in the standard and I'm in no way qualified to critise.
 
#Iterations of at least 1000 times seemed a bit excessive, but it is in the standard and I'm in no way qualified to critise.
 
#Instead of storing salt in it's own field I usually include it amongst the password (i.e characters 2, 4, 7, 13, 17, 19) to make it that bit harder to even find the salt value.  I generally hex encode the hashes as well to make them a bit easier to work with.  Assuming decompiled code is available (as an attacker has gained access to the password hashes) this extra salt hiding may not serve any useless purpose.
 
#Instead of storing salt in it's own field I usually include it amongst the password (i.e characters 2, 4, 7, 13, 17, 19) to make it that bit harder to even find the salt value.  I generally hex encode the hashes as well to make them a bit easier to work with.  Assuming decompiled code is available (as an attacker has gained access to the password hashes) this extra salt hiding may not serve any useless purpose.
 +
:--------------
 +
:I think that the above comment about hiding the bits in the password should just tossed. First, it is basically arguing security by obscurity - never a good practice. Second, it states that the bit hiding isn't helpful when the source code is available. Being that this article is discussing hashing in "Java" specifically and Java decompilation is a well-known and freely available technology, it seems that there is no need to mention hiding of the salt unless it is in reference to other languages. Eg: "In languages other than Java, where obtaining the source code can be difficult and reading the machine code is awkward, hiding the bits of the salt within the hashed password might provide some extra security.(And comments probably should be signed. Four tilde's "~ ~ ~ ~", without the intervening spaces, adds your username and timestamps the comment.)
 +
:[[User:Neil Smithline|Neil Smithline]] 16:46, 13 April 2007 (EDT)

Revision as of 15:46, 13 April 2007

Status

Needs review

Reviewers

  •  ?

General Discussion

I use a very similar scheme in my applications, but 2 points that came to mind whilst reading.

  1. Iterations of at least 1000 times seemed a bit excessive, but it is in the standard and I'm in no way qualified to critise.
  2. Instead of storing salt in it's own field I usually include it amongst the password (i.e characters 2, 4, 7, 13, 17, 19) to make it that bit harder to even find the salt value. I generally hex encode the hashes as well to make them a bit easier to work with. Assuming decompiled code is available (as an attacker has gained access to the password hashes) this extra salt hiding may not serve any useless purpose.
--------------
I think that the above comment about hiding the bits in the password should just tossed. First, it is basically arguing security by obscurity - never a good practice. Second, it states that the bit hiding isn't helpful when the source code is available. Being that this article is discussing hashing in "Java" specifically and Java decompilation is a well-known and freely available technology, it seems that there is no need to mention hiding of the salt unless it is in reference to other languages. Eg: "In languages other than Java, where obtaining the source code can be difficult and reading the machine code is awkward, hiding the bits of the salt within the hashed password might provide some extra security.(And comments probably should be signed. Four tilde's "~ ~ ~ ~", without the intervening spaces, adds your username and timestamps the comment.)
Neil Smithline 16:46, 13 April 2007 (EDT)