|
|
| Applications |
| Mailing Lists |
| Miscellaneous |
| Operating Systems |
| Programming |
Re: SHA-1 vs. triple-DES for password encryption?
Date: Sat Nov 09 2002 - 11:54:10 EST
Hey Craig,
Instead of weighing the pros and cons of the algorithms, lets attack this from a different perspective. Firstly, it is good that understand it would be better to use a standard algorithm rather than a home-grown one. As these have been vetted by the crypto gurus smarter than us there is a better chance that your home-grown one may not be able to stand up to the hostile world of networked users. Then again, maybe it can. But why chance it? Both SHA-1 and 3DES have been reviewed for some time.
With that said, lets look at what you are trying to do. You are wanting to store some secret (a password) to a media potentially accessible by others. The obvious issue off the bat is if someone can read this data, what can they gain from it? The second part to this is that if you use any sort of algorithm that requires the key, how do you control and protect the key itself? This is where a hash comes in nicely. SHA-1 is a hashing algorithm, and one of the only secure hashing algorithm that was FIPS approved. Its whole purpose is to provide a mechanism as a "verifier". This is good as if the application is compromised, less risk is exposed as the "secret" is not accessible, just a hash of it.
Further to this, you could "salt" the hash making it more difficult to brute force it. This is good as if two users happen to have the same secret, you can not tell if each hash has its own unique salt. One limitation in your case is that if you are only wanting to store 8 bytes, you want most of that to be a unique hash, and NOT the open salt. If you do only use 8 bytes, saving 2 for the salt seems to have been common place.
I apologize if you already know all this, but its good to understand what you are trying to go. If at all possible, it is a better technique to NOT store secrets when you don't have to. It minimizes the risk associated with doing so, with protecting of external elements (like keys), and limits the complexity of the application development. The last one some on the list may disagree with, and that is their right. I find that the easier it is to understand and apply correctly, the less likely it will be bug ridden, easier to maintain, and still accomplish the same security goals as set up in the design specification, matched against the threat model.
To answer your question about truncation, I really don't know how to answer this without understanding what the risks are you are exposed to. Also, I am always one for the larger (while still being reasonable) the hash, the better. Assume that an attacker can read the code and know your offset. If you are only using 8 bytes (64 bits) you shorten the time it takes to brute force it if they ever were able to retrieve the stored hash. This is one of many of the reasons shadow passwords were introduced in Unix environments. Longer passwords and hashes aid in making the hash much harder to work with. To the point of "hurting the algorithm" with truncation, this won't happen, since its one-way and you are segmenting it off AFTER it has already been hashed. You never have to jam the truncated hash back into the algorithm, you just need to compare it against what the user entered. Apply the same technique to the user's hash as you did to the stored verifier, and you should be fine.
Although SHA-1 is still very strong, NIST has released SHA-256, SHA-384 and SHA-512. (Check out http://csrc.ncsl.nist.gov/cryptval/shs.html for more info). Perhaps these could be made available to your mainframe. I would check. I would also check to see if you can take advantage of any OS security functionality that may assist you. Part of the K.I.S.S. principle is taking advantage of what you got, instead of having to build something from scratch.
Whatever you decide, good luck. Hopefully my meandering bellowing is useful to you in some context.
Again, good luck.
--- Regards, Dana M. Epp ----- Original Message ----- From: "Craig Minton" <CraigSecurity@blazemail.com> To: <secprog@securityfocus.com> Sent: Tuesday, November 05, 2002 1:01 PM Subject: SHA-1 vs. triple-DES for password encryption?Received on Sat Nov 9 21:58:28 2002
> We are considering changing our password storage from a home-grown
algorithm to a standard. We are mainframe based and only have triple-DES and SHA-1 algorithms available. However, we many questions about the best way to proceed. We are leaning towards using SHA-1 for a few of reasons. The password being "encrypted" using SHA-1 never need be retrieved, just verified. Indeed, the password should not be retrievable. By not using triple-DES there is no need to secure a key used to encrypt them. Also, with triple-DES, if someone was to obtain the key, by whatever means, retrieving all of the passwords would be trivial. The downside to SHA-1 is that we would have to increase our storage requirements for the encrypted portion from 8 bytes to 20 bytes.
>
> Is there anything inherently wrong with using SHA-1 to hash passwords for
verification?
>
> Is there a benefit to using triple-DES instead?
than triple-DES? My 2nd edition copy of Applied Cryptography states that there is no known crypto-analytic attack known for SHA-1, but that book is now several years old.
>
> It was suggested to use SHA-1 and then remove all of the bytes from the
hash except for 8 bytes (truncated from the beginning, end ,or somewhere in between) and store this, thus not increasing storage requirements. Would this compromise the algorithm? How much would it increase the chance that two passwords then had the same truncated hash?
>
> I look forward to any insights you can provide and will be glad to answer
additional questions where possible.
>
> Craig
Ads, 6MB, POP & more! http://www.everyone.net/selectmail?campaign=tag
>
This archive was generated by hypermail 2.1.8 : Wed Aug 23 2006 - 14:02:43 EDT
|
Contact Us Legal Notices Order Services Online Pantek Home Privacy Policy IT news Site Map Pantek Library |