Can i set a global hook on the wind proc in .NET. I am willing to write the
hook procedure in unmanaged dll. I want to capture the window messages of
another application (.NET) from my host application (again .NET).
Thanks in advance
Regards
Arun
===
This list is
Subject: Re: [ADVANCED-DOTNET] Storing shared secrets
> > > If you used encryption, etc so the app could access these
> > > protected items, then if the wrong person got access to the app -
> > > they would
> be
> > > able to gain access to the protected items
ubject: Re: [ADVANCED-DOTNET] Storing shared secrets
>> What you don't want: the key used for signing is available to anyone
who
>> installs your client, so Bans Frouma can get at it and use it in his
Pi
>> Komputing Klient.
>
>I hear this Bans Frouma guy is pretty smar
> > > If you used encryption, etc so the app could access these protected
> > > items, then if the wrong person got access to the app - they would
> be
> > > able to gain access to the protected items through the app.
> >
> > Though running as admin, add yourself to the group and you've
> >
> > If you used encryption, etc so the app could access these protected
> > items, then if the wrong person got access to the app - they would
be
> > able to gain access to the protected items through the app.
>
> Though running as admin, add yourself to the group and you've
> access.
If
> > The scenario is actually fairly simple. An application where a given
> > company will run multiple copies. Each instance the app needs to
> login
> > to
> > the same account (could be a share, a web service, etc.).
> >
> > There are too many users to reasonably grant each individual access to
> The scenario is actually fairly simple. An application where a given
> company will run multiple copies. Each instance the app needs to
login
> to
> the same account (could be a share, a web service, etc.).
>
> There are too many users to reasonably grant each individual access to
> protected
For those that are curious I'll try to shed a little more light on the why
of this.
The scenario is actually fairly simple. An application where a given
company will run multiple copies. Each instance the app needs to login to
the same account (could be a share, a web service, etc.).
There are
> On Fri, 28 Mar 2008 19:09:52 +0100, Frans Bouma <[EMAIL PROTECTED]> wrote:
>
> >> What you don't want: the key used for signing is available to anyone who
> >> installs your client, so Bans Frouma can get at it and use it in his Pi
> >> Komputing Klient.
> >
> > So that's a typical client-side ce
orithm.
Phil Wilson
-Original Message-
From: Discussion of advanced .NET topics. [mailto:[EMAIL PROTECTED] On Behalf
Of Per Bolmstedt
Sent: Friday, March 28, 2008 11:11 AM
To: ADVANCED-DOTNET@DISCUSS.DEVELOP.COM
Subject: Re: [ADVANCED-DOTNET] Storing shared secrets
On Fri, 28 Mar 2008 1
> would be to get a good IL obfuscator and leave it at that.
Speaking of which, what's the current best of breed?
We have to turn some sites over to a motivated third-party (who is
also a competitor) and would like to make the cost of reverse
engineering higher than the benefit.
--
"Your lack of
On Fri, 28 Mar 2008 19:09:52 +0100, Frans Bouma <[EMAIL PROTECTED]> wrote:
>> What you don't want: the key used for signing is available to anyone who
>> installs your client, so Bans Frouma can get at it and use it in his Pi
>> Komputing Klient.
>
> So that's a typical client-side certificate SSL
> On Fri, 28 Mar 2008 17:39:45 +0100, Frans Bouma <[EMAIL PROTECTED]> wrote:
>
> > THis isn't a lame attempt to be funny, but what is this 'shared secret'
> > exactly? A license key?
> >
> > Because as mentioned before, a secret that's shared isn't really a secret.
> > Could you explain some more d
A few observations/thoughts in no particular order:
If you make it secure by being obscure, all you really do is fool yourself
into thinking it is secure and have no way to work out when it has been
broken.
If you use one secret for all instances/installs, then they are all broken
the moment one
OTNET] Storing shared secrets
On Fri, Mar 28, 2008 at 9:32 AM, Per Bolmstedt
<[EMAIL PROTECTED]> wrote:
>
> What you don't want: the key used for signing is available to anyone
> who installs your client, so Bans Frouma can get at it and use it in
> his Pi Komputing Klient.
Surely if the 'secret' is available to your client app, then by definition
it's also available to anyone who is able to reverse engineer your client
app. Whatever your client app does to retrieve the secret, someone able to
reverse engineer the app can mimic in order to also obtain the secret.
What
On Fri, Mar 28, 2008 at 9:32 AM, Per Bolmstedt
<[EMAIL PROTECTED]> wrote:
>
> What you don't want: the key used for signing is available to anyone who
> installs your client, so Bans Frouma can get at it and use it in his Pi
> Komputing Klient.
I hear this Bans Frouma guy is pretty smart. If he h
On Fri, 28 Mar 2008 17:39:45 +0100, Frans Bouma <[EMAIL PROTECTED]> wrote:
> THis isn't a lame attempt to be funny, but what is this 'shared secret'
> exactly? A license key?
>
> Because as mentioned before, a secret that's shared isn't really a secret.
> Could you explain some more details about
THis isn't a lame attempt to be funny, but what is this 'shared secret'
exactly? A license key?
Because as mentioned before, a secret that's shared isn't really a secret.
Could you explain some more details about what this secret is all about?
FB
> I can't use a network sub-fold
Chay and Per, thanks for the ideas.
I can't use a network sub-folder but running a service as a specific user
would at least let me use DPAPI to securely store data.
Even if I have to have the service pass that data to my app it would still
be better than hard coding it in the assembly.
I'm not
On Thu, 27 Mar 2008 17:24:31 -0700, Mont Rothstein
<[EMAIL PROTECTED]> wrote:
> I consider in-the-assembly to be readily available.
What you want is for your application to have access to a secret but not the
users of your application, right? As in, the application can retrieve the
password, but
Mont Rothstein
Sent: Friday, March 28, 2008 9:25 AM
To: ADVANCED-DOTNET@DISCUSS.DEVELOP.COM
Subject: Re: [ADVANCED-DOTNET] Storing shared secrets
Chris and Erik, thank you for the additional thoughts.
The problem with impersonating a specific user, is that you then have to
have the password for
Chris and Erik, thank you for the additional thoughts.
The problem with impersonating a specific user, is that you then have to
have the password for that user.
Storing a salt or other key value in my assembly is what I am trying to
avoid.
Unless I am missing something there just doesn't seem to
The DotNet face of DPAPI is these two classes (they have decent code
examples):
http://msdn2.microsoft.com/en-us/library/system.security.cryptography.pr
otecteddata.aspx
http://msdn2.microsoft.com/en-us/library/system.security.cryptography.pr
otectedmemory.aspx
They allow the DataProtectionScope
> Unfortunately it is user specific and I need something that will work
> for
> all users.
>
The whole point of DPAPI is that it stores secrets, not "shared secrets"
(which is a bit of a contradiction when you think about it)
You can still use DPAPI in an app used by many people on the same
mach
Thanks guys. I wasn't aware of DPAPI.
Unfortunately it is user specific and I need something that will work for
all users.
What I think is needed (and apparently does not exist) is the .NET
equivalent of DPAPI. Something that has a secure path from the specific
version of an application to a hi
On Thu, 27 Mar 2008 12:29:47 -0700, Mont Rothstein
<[EMAIL PROTECTED]> wrote:
> I am looking for a way to securely store a shared secret.
There was a related thread last week; subject "Key storage". If that doesn't
help you, maybe the Data Protection API is good enough?
http://msdn2.microsoft.com
-
From: Discussion of advanced .NET topics.
[mailto:[EMAIL PROTECTED] On Behalf Of Mont Rothstein
Sent: Thursday, March 27, 2008 3:30 PM
To: ADVANCED-DOTNET@DISCUSS.DEVELOP.COM
Subject: [ADVANCED-DOTNET] Storing shared secrets
I am looking for a way to securely store a shared secret. This
I am looking for a way to securely store a shared secret. This shared
secret is going to be used my multiple machines and so can't be generated
for each machine independently. It can of course be encrypted but then the
key has to be securely stored.
Ideally there would be a way to store data tha
29 matches
Mail list logo
