storing hashed passwords
just need some advice on whether this is a good or pointless
method of helping to secure stored, hashed, passwords:
instead of just hashing the password to get 256bit result, we:
say:maximum password length = 15
say:max length of generated string length = 256 (for example)
we:pad password to 15 with nulls (0x0)
we:generate K which will be a 32bit integer
we:store K in bytes 16 and 17
we:use K to seed a rng to generated 256-17
random bytes.
we:put random bytes on the end,
then we: hash result
and: store result.
is this pointless, i appreciate your advice.
[679 byte] By [
silkma] at [2007-9-29 6:04:18]
my opinion is yes, because instead of now the attackeronly having to iterate 15 positions of 26 chars, he mustiterate 256 positions of 26 chars.. no? and it doesn'tmatter so much if he knows our algorithm....
silkma at 2007-7-14 20:13:02 >
oh how i wish i could delete this thread.
silkma at 2007-7-14 20:13:02 >
perhaps it is not so dumb if we assume "K" is privateand the same for each hashing, then it is not so stupid... right?
silkma at 2007-7-14 20:13:02 >
there are tested algorithms available in JCE (Java Cryptography Extension)
for this kind of thing.
Search the docs for Message Digest
Don't try your own cryptographic algorithms, except you
are doing it just for fun or are realy experienced in the
it. Otherwise you will most likely introduce major security
holes in your app.
regards
Spieler
i'm not writing my own custom hashing algorithm, i'm no
fool, i'll leave that to the experts :)
my question was about how to make brute-force attacks
against my login interface more difficult by introducing
random characters into the hashed result.
i posted to see:
1) how to do it
2) if its worth it
3) if we do do it, does our algorithm need to be secure?
i assume 3 as we must know the value of the extra data to include
in the result before hashing it each time, so we must keep this
extra data somewhere, and that would be in the file (or db, whateveR)
so that defeats the point (in my case)
anyway, i suppose the point is that hashing will not help at
all in my attempts at brute-force protection, hence the reason
i was embarassed for posting this question.
silkma at 2007-7-14 20:13:02 >
If your threat model is that someone hashes all the words in the Oxford English Dictionary and then looks for matches, "salting" is useful. You generate a random "salt" for each password entry, and store the salt and the hash of (salt.append(password)). Then the attacker needs to do his hashing once per entry rather than once full stop.
my attacker will have access to the code ....
salting cannot help here right, because i must
store it somewhere to use when i rehash and check
passwords as the users sign in?
anyway, i think the best protection against brute
force is much simplier: set a timeout on failed logins.
unless they get access to the hashed passwords
and try and recover them, then another plan would
be required... but i think that is not such a great
risk given our setup
thanks for your thoughts, but i don't think salting can
help me too much if the attacker has access to the code...
i could be wrong, however.
silkma at 2007-7-14 20:13:02 >
You store the salt with the hashed password, not in the code - so if you're not worried about them getting access to the hashed password, you don't need to salt.
There are three usefull effects you can gain by salting the password like this.
Number one, and most important is that if an attacker gains access to the password database he will not have access to the true password, meaning that if the user used the same password for other services the attacker would not have access to those services.
Number two is that because the attacker does not have the real password he cannot use the hashed password in an unmodified binary. To attack the system using the hashed password the attacker would need to write or modify a binary that would bypass the hashing of the input password.
Number three is that it would not be more difficult to brute force submit passwords because there are more steps and time involved in each attempt. This is relatively minor however because it would be just as effective to enforce some type of delay in the login process.
