Re: SHA-1 vs. triple-DES for password encryption?

From: Dana Epp (dana@vulscan.com)
Date: 11/09/02 

From: "Dana Epp" <dana@vulscan.com>
To: <CraigSecurity@blazemail.com>, <secprog@securityfocus.com>
Date: Sat, 9 Nov 2002 08:54:10 -0800

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?

> 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?
>
> Is SHA-1 any more suseptible to attack, brute-force or cr ypto-analytic,
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
>
> _____________________________________________________________
> Fight the power!  BlazeMail.com
>
> _____________________________________________________________
> Select your own custom email address for FREE! Get you@yourchoice.com w/No
Ads, 6MB, POP & more! http://www.everyone.net/selectmail?campaign=tag
>

Relevant Pages

  • RES: sha-1 cryptography
    ... SHA-1 is not a criptographic algorithm, it's a hash algorithm, and it is known that SHA-1 just as all others SHA algorithms have a finite number os possibilities for a hash code. ... tenha recebido por engano, por favor, informe o remetente e apague-a de ...
    (Security-Basics)
  • Re: padding scheme
    ... so the program converts the password into a key for the individual algorithm. ... Blowfish Advanced CS uses a key setup in which your password (or key disk ... content) is hashed with SHA-1, ...
    (sci.crypt)
  • Re: Hash MD5, Sha1 and Length
    ... These are standard cryptographic methods for protecting bulk passwords ... algorithm = new MD5CryptoServiceProvider; ... The salt prevents two people using the same password having the same ... hash and also stops an attacker pre-calculating hashes for commonly ...
    (microsoft.public.dotnet.languages.csharp)
  • RE: Password Cracking Challenge...
    ... > with the encrypted password, ... > determine the algorithm used to hash the passwords ... what would the hash for the password: ... You don't mention whether this is an algorithm you constructed just for this ...
    (Vuln-Dev)
  • Re: APACHE/PHP/MYSQL Password Hash
    ... Can anyone tell me what file I would look at to see what hash ... algorithm is being used to store the passwords in the table? ...
    (freebsd-questions)
Quantcast