As your queries are related to Growl for Window, it would probably be best to send them to the Growl for Windows Group: Email: [email protected] Online: http://groups.google.com/group/growl-for-windows
In theory, the purpose of the salt of is to prevent replay attacks, so I believe that the Growl for Windows application should reject messages that use the same salt, but I know from experience that it currently does not. Carey On Thu, Apr 15, 2010 at 4:10 PM, Patrick Stein <[email protected]> wrote: > > In the binary Growl Talk protocol, authentication was done by > computing a hash value for the whole message + a secret password > and appending this hash to the message. If someone could eavesdrop > on the Growl Talk communication, they could replay messages at > a later date without having to know the secret password. However, > they could not craft new messages for an application without knowing > the secret password. > > I'm reading the GNTP spec here: > http://www.growlforwindows.com/gfw/help/gntp.aspx > > and looking at this sample implementation here: > http://github.com/mattn/perl-Growl-GNTP/blob/master/lib/Growl/GNTP.pm > > (which looks reasonably to spec except that it doesn't support > the x-growl-resource:// referencing) > > And, it looks to me like the authentication got thrown out > inadvertently (in both the protocol spec and the sample Perl > code there). It looks like now anyone who can eavesdrop on > an encrypted or authenticated channel can both resend messages > at later times *and* craft new authenticated messages from scratch > without having to know the secret password. > > Here's all that I have to do: > 1. intercept a message > 2. copy out the keyHashAlgorithm, keyHash, and salt. > 3. craft any unencrypted message that I want using the same > keyHashAlgorithm, keyHash, and salt > > GNTP/1.0 NOTIFY NONE keyHashAlgorithm:keyHash.salt > <any message that I desire> > > This new message will have a valid keyHash since the keyHash > did not depend on the message contents in any way. The only > way this might still be okay is if the server side keeps track > of every keyHash/salt it has ever received and only lets each > get used once. This would be a nightmare on both ends of the > socket. > > The situation looks to be even worse in the sample Perl code > that I was looking at because it appears (and, maybe I am reading > it incorrectly, but it appears) step #5 is omitted from the > Key Generation described in the protocol document and the actual > key itself is sent in place of the keyHash. This means that I > can even send encrypted (and authenticated) messages without > ever needing to know the password since I already have the > encryption key in my hand. I hope the server side is not skipping > step #5 and will reject all of the encrypted messages generated > by that Perl code. > > Can somebody please clarify? > > Even if we don't bother correcting the protocol to prevent > replays, we should at least make sure you cannot send arbitrary > authenticated (or encrypted!!) messages without the secret > password. > > Thanks, > Patrick > > -- > You received this message because you are subscribed to the Google Groups > "Growl Discuss" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]<growldiscuss%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/growldiscuss?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Growl Discuss" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/growldiscuss?hl=en.
