>From the M side, you'll have access to all the hashes.  So yes, you can
send in the "correct hash" and complete the transaction.  The purpose of
the SigCode hashing is to restrict access from outside the system and
those using the system without Programmer Access.

In terms of EVE access to hashes and documents, technically you can
bypass the entire sub-routine and alter FILEs yourself.  You're
protecting the system not from yourself but from others.

Let's take an OS for an example (*nix or Windows).  Both store password
hashes (*nix has the passwd/shadow file and Windows has the SAM).  If
you could pick out a hash from there and submit it, you'd be in.
However those systems don't allow you to easily give it the hash itself
- it wants the password to convert into a hash and submit itself.  Also
getting access to the hashes is restricted to anyone but the system (yes
- I know, there's ways into both - but generally access is denied).

In the case of M, I'm not sure you can restrict information in the way
file systems and SQL databases do.  For instance, in SQL - I can
restrict access to a column on a row in a table.  And on the file
system, I can restrict the type of access to any given file on the
system.  I'm sure the M implementation is vendor specific but you could
combine the CAL of the server to disallow user-level access to the Hash
File and only allow the system to read it.  Then disallow access to the
routine that checks the hashes and force all routines to check hashes
thru there.  Keep your programmers in check and you should have a solid
system.

/David.


-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Kevin
Toppenberg
Sent: Friday, December 17, 2004 12:40 PM
To: [EMAIL PROTECTED]
Subject: RE: Fw: [Hardhats-members] How to set up electronic signature.

OK, so say we use MD5 to change "MyBadSigCode" into
34486852F05CCA326640F061A2D819BA.  This is then saved
in the database   A programmer would be able to create
a spoofed document and save this same signature code,
making it appear that it had been created in a valid
way.

So I'm not convinced that the conversion has increased
our security all that much.

Kevin



--- David Sommers <[EMAIL PROTECTED]> wrote:

> Here's what typically happens in a password
> validation scenario.
> 
> Server has your password as "MyBadSigCode" which
> MD5s out to
> 34486852F05CCA326640F061A2D819BA
> 
> You're at the client and type in
> "IForgotMyBadPassword" which MD5s out
> to FB4869D6EEB1F3B8360398D292EEA904
> 
> The client sends that MD5 (FB4...904) to the server.
>  Server compares it
> and the values don't match.  Access denied.  If they
> did match, you're
> in.
> 
> I usually build all my systems with both MD5 and SHA
> support since you
> don't know what the client might be sending.  I also
> allow you to
> disable each hashing type in case they want to
> restrict what can be
> sent.
> 
> 
> Hashing is best described as pigs and bacon.  You
> can take a pig
> (password) and turn it into bacon (hash).  You can't
> turn bacon (hash)
> into a pig (password).
> 
> This is where the terms "brute force" and
> "dictionary attacks" come into
> play.  Since you can't take a hash and make a
> password, you have to make
> guesses and test each hash against the server.
> 
> Dictionary is where you guess words, like
> "password", "god", and
> "computer".  Brute force is where you just go down
> the possible key
> space with "000", "001", "aaa", "aab", etc.
> 
> This is why a good password is important and why
> most systems have
> lockout features.  If you guess incorrectly 5 times
> in 30 minutes, your
> account is locked for 30 more minutes.  This
> prevents network based
> attacks where remote computers just keep trying to
> get into your system.
> 
> 
> And here's some hash outputs from a program I have. 
> (Longer = Better,
> in a very loose interpretation.  All algorithms have
> trade-offs.  Never
> use CRC).
> 
> 
> 
> Calculating hash of 12 bytes string
> `MyBadSigCode`...
> 
> SHA-160     :
> 6C288A3141BC442E1D3ECEE8C094364EFE77528E
> SHA-256     :
>
7ABC81E45BEE64BFF569DDE4D87DFB994118FEB7135A3E9495089F4FE4E0B8A4
> SHA-384     :
>
4948DECE72241F4C74F372D299C20EF2BBD7FF3D264BA5BA50551433E2513C4C8BDB615F
> 66E7C93E7277CA94AEB8C332
> SHA-512     :
>
25DEC5A873AD8B5B188741B749C7CD7E33707E36BD1B88162756274797C7299D421EFF97
>
F00ED41BCDA267B2A8A9AFE7AF2A01B5654E99F9FBE5B71A23C0A96F
> MD5         : 34486852F05CCA326640F061A2D819BA
> RIPEMD-160  :
> 0AC7B6B9D01FEDE7C6D7755EFEB494BA7ACA5AFB
> HAVAL-3-128 : B183553EE3B25A0D7312156C31B9552D
> HAVAL-3-160 :
> 4C484BFC35981D0BB785D870F3152F5DF2678711
> HAVAL-3-192 :
> 50FFA5FDF4FB0A8C3428ABAED2FD09682F416E57FACA192A
> HAVAL-3-224 :
>
A035D6801218131C0B69D8C4F26BE9B458A30062326548070658AE03
> HAVAL-3-256 :
>
E344C2FB86115C73099094CF3E12654C87480187548FE3715D75937AF588CEE1
> HAVAL-4-128 : EC406DC85FEBCB80DFB4E1341A65D941
> HAVAL-4-160 :
> E4B379913ABA6E549F1B6AD355B4E38F2FD5F62F
> HAVAL-4-192 :
> 7FF2C59CCBD144A8D56F2F944ECC5669975488ED271A16F7
> HAVAL-4-224 :
>
4924A3E148448172381A1101FEAA698FF3564FBD1176BF012C1AB988
> HAVAL-4-256 :
>
AB3B548D1D2F3E9756A7EAB8BC76C6B30D8DE5C281D78F22423DBD0BD78D9707
> HAVAL-5-128 : 76CD9BEA3313B4A67B0FDD83B8347B5B
> HAVAL-5-160 :
> 764427D8DCF1432D8B1478EC8BC82F18EF8361B7
> HAVAL-5-192 :
> 1977E8437F17583B459E5DC4931C8160D004D4A29937B6F3
> HAVAL-5-224 :
>
B7455AF71FCF863BE6586D1A95D3BB9A793FB455D6E1B8253397A6A3
> HAVAL-5-256 :
>
D79B397B013AB3EE552A8EB65729E80EC2E6C2B4E0270CAFE61EEEE4599C0AA7
> CRC-32      : 3537B663
> 
> /David.
> 
> -----Original Message-----
> From: [EMAIL PROTECTED]
>
[mailto:[EMAIL PROTECTED]
> On Behalf Of Nancy
> E. Anthracite
> Sent: Friday, December 17, 2004 11:38 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Fw: [Hardhats-members] How to set up
> electronic signature.
> 
> Now if I understand correctly, dictionary attacks
> are for people with
> bad 
> passwords, right? ;-)
> 
> In a hospital setting with a bunch of programmers
> and a narcotic
> prescription 
> writing physician on staff signing scripts
> electronically,  that doctor
> would 
> sure want there to be tight encryption, especially
> if that doctor were
> me, 
> and likely the programmers would want it to for
> their protection. If you
> 
> haven't had a narcotic prescription written in your
> name yet, give it
> time.  
> 
> On Friday 17 December 2004 10:01 am, Kevin
> Toppenberg wrote:
> > Can someone explain to me why this is needed? 
> General
> > users don't have access to the stored electronic
> > signiture.  So wouldn't a code stored in plain
> text be
> > reasonably secure?  And for programmers who have
> > access to the stored, encrypted string, they could
> use
> > the encryption formula to run a dictionary attack
> and
> > likely crack it.
> >
> > So what is wrong with the simple hash formula we
> have?
> >
> > Kevin
> >
> > --- Lloyd Milligan <[EMAIL PROTECTED]> wrote:
> > > It would be possible to perform the electronic
> > > signature encryption using a
> > > program written in another language and called
> from
> > > within VistA.  However,
> > > it wouldn't be like PGP, which is a public-key
> > > system.  The MD5 message
> > > digest algorithm (RFC 1321) was intended for
> digital
> > > signature applications.
> > >
> > > Lloyd
> > >
> > > ----- Original Message -----
> > > From: "Nancy E. Anthracite"
> > > <[EMAIL PROTECTED]>
> > > To: <[EMAIL PROTECTED]>
> > > Sent: Friday, December 17, 2004 7:57 AM
> > > Subject: Re: Fw: [Hardhats-members] How to set
> up
> > > electronic signature.
> > >
> > > > If C code can be put into M code with GTM,
> could
> > >
> > > we use open source PGP
> > >
> > > > type
> > > > encryption for this wtihout having to rewrite
> it
> > >
> > > in M?  On the other hand,
> > >
> > > > we
> > > > have to put it into the Delphi end as well. 
> Can
> > >
> > > you shove C code into
> > >
> > > > Delphi
> > > > somehow?
> 
=== message truncated ===



                
__________________________________ 
Do you Yahoo!? 
Jazz up your holiday email with celebrity designs. Learn more. 
http://celebrity.mail.yahoo.com


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/
_______________________________________________
Hardhats-members mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/hardhats-members


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/
_______________________________________________
Hardhats-members mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/hardhats-members

Reply via email to