Page 2 - Hashing Algorithms

Thread stuck as it's interesting, and useful

Hmm... use a public-key protocol for security key?

Try pitting all the bots and malicious servers in the world against a 1024-bit key. Your security is assured until Shor's algorithm is successfully implemented (read: a very long time).

But the cookies and sessions will have to be huge, and then there's the overhead to talk about. Unless of course you split the load and generously accord some CPU load to the user

One thing I want to point out is that just appending a constant salt to all of your password hashes would cause the attacker to have to regenerate there hole rainbow file with the salt of your choice appended to all of there stuff. That could take a considerable amount of time to regenerate a rainbow file that is 10,000 passwords long.

This really isn't something that would make or break someone that really wanted your passwords however it would stop most people that just doing it for play.

The best one would be to use a unquie salt for each password however it goes back to the point how do you store a bunch of salts and a bunch of passwords so they can't both be stolen? You would have to seperate them from the database and probably would need to put them on seperate servers and such. So basicly it becomes a question of how imporant are your users passwords?

I'm a newbie, and enjoyed the conversation. I must be missing something, but the problem of hiding IDs and passwords is that they are so short. There just isn't much you can do about that. If your algorithm, or enryption scheme is compromised, then there is no way to hide what is going on, and a BF attack is trivial. We must assume your algorithm is compromised!

Perhaps the bedst approach is to examine the login procedure, and see what we can do from there. Usually, a person is asked for an ID, and then a password. This is the description of what we have to work with, and those cannot be 100 character strings (which is obvious). So, what can we do? (We could ask for a 2nd password [enter your mother's maiden name?], but let's deal with just the two inputs...)

If an ID can be 12 characters, and the password 12 characters, that is only 96^24 possible combinations no matter what you do with it! You can seed it, salt it, tinkle on it - that is all a brute force attacker would have to go thru to bust it. That's 10^47.5, 2^158. THAT'S 158 BIT ENCRYPTION!!!

So, the problem would appear to be people using short IDs and passwords. You have to tell them of the problem. Two 12-character entries can be very easy to remember, and if done properly, you cannot store enough tables to allow a quick bust. It would appear that the solution to the problem is to warn people that they must use the full 12 characters for the ID and password, and use numbers, and punctuation - the more stuff they use, the safer they are.

If I know that that you are hashing a 12 character field, and I have your algorithm, then I bust you in about 40^12 tries... (40, because most people don't use the full keyboard character set). And that is 10^19, or 2^33 - a trivial bust, in today's world., and there is nothing you can do to make the bust more complicated...

The solution, again, is to inform the user that he must use 2, 12 character fields that are not his wife's and dog's names....

I don't think the solution to short passwords and IDs is some obtuse use of hashes...

You take the ID, then the password , and you hash 12-char ID + 12-char password (24 char value) to produce the hash (16 char? - 24 would be better) that you have stored for that user's access. 96^24 is not a trivial bust! (10^47, 2^158)....

Perhaps I do not understasnd the problem.....

Additional thoughts - the idea of the ID being something known (email addr) is dealt with by considering that you can "mess" with the data once in your server in ways that are unknown (even if he hacks your server!) This is the idea of putting the intelligence in the keys, and not in the code. In other words, the keys (ID and password) determine something like a key to a PRNG that is used to initialize a shuffle algorithm, where the data is shuffled in some manner prior to hashing, and every id+password causes a different shuffle of the data. This is not hard to do, and I have examples of it.

Another idea is to expand the dynamic range of the ID+password phrase by passing it thru a substitution array such that 7-bit keyboard is expanded to 8-bit keyboard data. This would be a normal application of a substitution array on the data, except the sub-array is rotated 1 position after each use so 3 "e"s would not produce 3 of the same character from the substitution alphabet.

So, here is what we now have - the 24 keyboard characters have had their dynamic range expanded from a subset of 7-bit keyboard to full 8-bit data, and the data has been shuffled (based on a key from somewhere - even the data itself, like I do), and then hashed. The key for the substitution alphabet could be the password, and the key for the shuffle could be password+ID. That firmly places the difficulty to bust at 256^24, or 10^58, or 2^193. I suggest that 193-bit encryption is pretty good...

Or, maybe I am still missing something....

Ron.

"SimonGreenhill"
And I hate MSN because it has only a 12 character password limit. Most of my passwords are 20 characters or more.


People hack Paypal accounts by taking advantage of these little things. A password is private and secret (well at least ideally). Your mother's name is definitely not.

Your main problem is entropy. If there's no entropy in your users' passwords there is nothing much you can do about it, short of requiring them to choose better passwords. The algorithm doesn't help either. Try choosing your RSA modulus to be a perfect square. It all boils down to security vs. convenience. I'd require strong login info for banking clients, not for some kid junky like M*sp*c*.

hey what about using

output1 = h(serversalt1 + firsthalf(password))
output2 = h(output1+serversalt2 + secondhalf(password))

does this increase security at all? and does it make rainbow tables even more useless? or would it just increase the overhead for an attacker slightly if he was attacking it. (I know it wouldn't if he just wanted to get a hash-collision for output2, but if he needed to find password or something...)

There's no point trying to fix a broken hash algorithm using obscure tricks. If you want to know exactly how secure a particular construct is, why not go find out yourself. A reduced-round brute force can give very reliable, interesting results for most conventional cryptographic functions.

You are addressing real problems that have been solved.

read about RFC 2104 - HMAC: Keyed-Hashing for Message Authentication

this is also called "one way passwords". HMACs are just an improvement on the old crypt() salt idea. its really simple, you pick a secret that you keep secret, and when you create a user enters a userid and password, you
take the password and calculate a hmac with it and your secret.
Store the hmac result in you database, lookup table, /etc/passwd, etc.

When the user logs in, recalculate the hmac, and compare.
If the user says "I forget my passwords, what is it?" you can't I dont' know. I can reset it, but no one can tell you what it is.

As a simple implementation (read the RFC first) if your secret is "zaphrod" and the users' password is 'puppy' then you just calculate
sha(zaphodpuppyzaphod);

While you can use MD5, it is old and weak. Better is to use SHA1, but it may not be strong. So use SHA256. Java has it built in, its no harder to use than MD5. I can't spell php, but I bet it has an equivalent.

Not really.
It is equivalent to using a different server salt once.

This is related to a hot research topic in the 1990s: "is DES a group"
even when you don't use DES to do the hash.

In general, unless you really, really, understand the non-trival math, it is easier to weaken the security using hashes, HMACs, ciphers, etc. that it is to improve them.

Ok,

I got something, if you do something like this in PHP, it can't be cracked against a list of encrypted strings

• That will encrypt the encrypted version of the string so here is an easy illustration:

• THE PASSWORD "mysecretpassword" is the encrypted using MD5 which will be "4cab2a2db6a3c31b01d804def28276e6 "

• THEN ENCRYPTING "4cab2a2db6a3c31b01d804def28276e6" using MD5 will be "784e0cf8edc45fc57d20a0b30fd62bc7"

This is a simple idea which will just add a tenth of a millisecond onto the time creating the hash and doing the overall script.

MD5 is a hash, not a cipher. It can not 'encrypt' anything.

Why do you suggest hashing it twice?

And why not use a more modern hash, such as SHA?