Re: Securing hashing algorithm

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance

From: William Stacey [MVP] (staceywREMOVE_at_mvps.org)
Date: 11/24/04


Date: Wed, 24 Nov 2004 12:39:53 -0500

Well in my mind, when using non-keyed hash, you don't need a password to
create the same the hash using the same data. So anyone can look at your
code and figure out you are just using sha (for example) to create your hash
and do the same. Keyed hash gives you a level of security as you need to
know the "key" to gen the same hash. Its like needing to know the password.
Now you need to secure the "shared" password as both sides need to use the
same one. Unfortunately, this means you need to embed it in your code or in
a resource. So you could "hide" it in multple parts of your app and/or use
obfuscator crypto on the string or strings you will combine to create your
clear password. You could then use something like a combination of DPAPI
and the ISO store to store the encrypted key. So you need to be the user
who stored the key and the assembly (I think using ISO) to retreive the key.
The issue is still the first part - where to store the password so I can get
it, encrypt it, and store it? I keep coming back to string crypto using
obfuscator, but maybe there is a better way? Naturally, you may be able to
avoid the above by using PKI public key method. It would depend on what
your doing I guess. Anyway, hth.

>From MS HMACSHA1 docs:
"...A keyed hash algorithm is a key-dependent, one-way hash function used as
a message authentication code. Only someone who knows the key can verify the
hash. Keyed hash algorithms provide authenticity without secrecy.

Hash functions are commonly used with digital signatures and for data
integrity. HMACSHA1 is an example of a keyed hash algorithm."

-- 
William Stacey, MVP
http://mvp.support.microsoft.com
"Wm. Scott Miller" <Scott.Miller@spam.killer.wvinsurance.gov> wrote in
message news:OmMA7hj0EHA.1652@TK2MSFTNGP11.phx.gbl...
> I've noticed by searching the groups that you are a strong supporter of
the
> "keyed" approach.  So, what are the advantages and disadvantages of using
> keyed vs non-keyed hashes?
>
> Thanks,
> Scott
>
> "William Stacey [MVP]" <staceywREMOVE@mvps.org> wrote in message
> news:%238pbc8e0EHA.3468@TK2MSFTNGP14.phx.gbl...
> > When using one way hashing like this, you always have one issue -
securing
> > the password/key passed to the keyed hash.  I assume your using a
"keyed"
> > hash like HMACSHA1 or a keyed MD5 to hash your secret.  Some options
are:
> > 1) string encrypted in your program using obfuscator (better then
nothing,
> > but probably not great.)
> > 2) Protected via ACLs in registry, file or smartcard (or others).
> > 3) Use DPAPI to set and get your password in the OS. See
> >
>
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/secmod/html/secmod21.asp
> >
> > Of the three, DPAPI is probably the best.  It is still not perfect as a
> user
> > logged in using same user account as app used can decrypt the data.  If
> you
> > use the machine store, any user could decrypt the data unless you use
> > additional entropy.  So possible a slightly better approach may be to
use
> > machine store so any user on local machine could use your program and
keep
> > your "entropy" encrypted in your program (via obfuscator encryption.)
So
> > not a hacker needs to hack your assembly to figure out general idea of
> what
> > your doing, somehow decrypt your entropy (i.e. second pw) and then
figure
> > out how to get data from DPAPI and what store your used, etc.  As you
can
> > see, you could keep jumping through hoops hiding data until your blue
and
> > still not get 100% protection.
> > Possibly a better approach is to use RSA private/public key and client
> only
> > knows public key.  That way, you have nothing you need to hide.  You
still
> > need to protect your client apps public key so it can't be replaced by a
> > hackers public key, etc.
> >
> > Naturally, none of this matters if your code is plain .net as hacker can
> use
> > ildasm and ilasm to round trip your code and do remove your protections
> and
> > public key removing the strong name checking at assembly load time.
Only
> > thing that helps this is obfuscating using a good one (I use and like
> > XenoCode which also prevents ildasm on your assemblies).  Getting to a
> point
> > where the only option for the hacker is to hack your code is probably
the
> > best effort and should be the goal I would think.
> >
> > -- 
> > William Stacey, MVP
> > http://mvp.support.microsoft.com
> >
> > "Wm. Scott Miller" <Scott.Miller@spam.killer.wvinsurance.gov> wrote in
> > message news:OPhhtfa0EHA.3744@TK2MSFTNGP10.phx.gbl...
> > > Hello all!
> > >
> > > We are building applications here and have hashing algorithms to
secure
> > > secrets (e.g passwords) by producing one way hashes.  Now, I've read
> alot
> > > and I've followed most of the advice that made sense.  One comment
I've
> > seen
> > > alot about is "securing the hashing routine" but no-one explains how
to
> > > accomplish this.  So how do I secure my hashing routine?  Do I use
code
> > > access security, role based security, ACLs, etc or combination?  And
if
> > > combination what combination is the best?  The routines will be used
by
> > two
> > > "applications."  A ASP.NET and a Windows application.  It already has
a
> > > strong name and is installed in the GAC.  How do I prevent it from
being
> > run
> > > by any code besides our two applications?  Should it be installed in
the
> > > GAC?  And if not, how to I guarantee the two applications are using
the
> > same
> > > version?
> > >
> > > Thanks for your help,
> > > Scott
> > >
> > >
> >
>
>


Relevant Pages

  • Re: Cryptanalysis to a homemade keyed MD5 MAC
    ... "length extension weakness", IMMO it does apply only to an unkeyed ... hash and here we have a keyed hash. ... the double hash construction ... but not all "keyed hash functions" are. ...
    (sci.crypt)
  • Re: Same Inputs, different output = No searching
    ... I assume you protect the data (that's why you are encrypting) ... but I would still recommend to use either keyed hash or the hash encrypted. ... You don't want to store just the plain hash of the SSN in your database as it ...
    (microsoft.public.platformsdk.security)
  • Re: Hash of Public key
    ... I answered you several times you can hash your public key in many different ... Calculate hash on concatenation of little endian modulus with little ...
    (microsoft.public.platformsdk.security)
  • Re: Hash of Public key
    ... other devices (not mine obviously like PC can be UPnP device too, WiFi, ... >I answered you several times you can hash your public key in many different ... Calculate hash on concatenation of little endian modulus with little ...
    (microsoft.public.platformsdk.security)
  • Re: Hash of Public key
    ... I answered you several times you can hash your public key in many different ... Calculate hash on concatenation of little endian modulus with little ...
    (microsoft.public.security)