Re: Storing shared secrets

On Thu, 27 Mar 2008 12:29:47 -0700, Mont Rothstein
<mont.rothsteinGMAIL.COM> 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/en-us/library/ms995355.aspx


===================================
This list is hosted by DevelopMentorŪ  http://www.develop.com

View archives and manage your subscription(s) at http://discuss.develop.com

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 highly secure storage.

This would also address DPAPI's second shortcoming that any
app can access a
given user's data.

I want this did to be non-discoverable.

Ideas?

Thanks,
-Mont

===================================
This list is hosted by DevelopMentorŪ  http://www.develop.com

View archives and manage your subscription(s) at http://discuss.develop.com

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 highly secure storage.

This would also address DPAPI's second shortcoming that any
app can access a
given user's data.

I want this did to be non-discoverable.

Ideas?

Thanks,
-Mont

===================================
This list is hosted by DevelopMentorŪ  http://www.develop.com

View archives and manage your subscription(s) at http://discuss.develop.com

> 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
machine - just use impersonation to impersonate an
"application" user
then access that user's DPAPI store.

In a web app using Forms authentication, the server is
already running
as a single user.
If you use Windows authentication OTOH, then impersonate as
above when
retrieving the secret.

===================================
This list is hosted by DevelopMentorŪ  http://www.develop.com

View archives and manage your subscription(s) at http://discuss.develop.com

> 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
machine - just use impersonation to impersonate an
"application" user
then access that user's DPAPI store.

In a web app using Forms authentication, the server is
already running
as a single user.
If you use Windows authentication OTOH, then impersonate as
above when
retrieving the secret.

===================================
This list is hosted by DevelopMentorŪ  http://www.develop.com

View archives and manage your subscription(s) at http://discuss.develop.com

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 be
a way to create
a secure path between an app and stored data without
something key (salt,
password, etc.) being stored in a readily available format. 
I consider
in-the-assembly to be readily available.

-Mont

===================================
This list is hosted by DevelopMentorŪ  http://www.develop.com

View archives and manage your subscription(s) at http://discuss.develop.com

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 be
a way to create
a secure path between an app and stored data without
something key (salt,
password, etc.) being stored in a readily available format. 
I consider
in-the-assembly to be readily available.

-Mont

===================================
This list is hosted by DevelopMentorŪ  http://www.develop.com

View archives and manage your subscription(s) at http://discuss.develop.com

I'm thinking that, architecturally, you might want to head
in a slightly
different direction.

Storing of common data related to an application might
require a network
sub folder restricted to a security group, rather than going
for an
encryption (and an implementation of isolated storage?)

Domain
  |
  v
Site
  |
  v
Group
  |
  v
User

Also, applications can run under a separate user account
too, if you
want to head down that path, with a network home drive.

HTH,
Chay Harley


-----Original Message-----
From: Discussion of advanced .NET topics.
[mailto:ADVANCED-DOTNETDISCUSS.DEVELOP.COM] On Behalf Of Mont
Rothstein
Sent: Friday, March 28, 2008 9:25 AM
To: ADVANCED-DOTNETDISCUSS.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 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 be
a way to
create
a secure path between an app and stored data without
something key
(salt,
password, etc.) being stored in a readily available format. 
I consider
in-the-assembly to be readily available.

-Mont

===================================
This list is hosted by DevelopMentor(r)  http://www.develop.com

View archives and manage your subscription(s) at
http://discuss.develop.com


-- 
This message may contain confidential, proprietary, or
legally privileged information. No confidentiality or
privilege is waived by any transmission to an unintended
recipient. If you are not an intended recipient, please
notify the sender and delete this message immediately. Any
views expressed in this message are those of the sender, not
those of any entity within the KBC Financial Products group
of companies (together referred to as "KBC FP"). 

This message does not create any obligation, contractual or
otherwise, on the part of KBC FP. It is not an offer (or
solicitation of an offer) of, or a recommendation to buy or
sell, any financial product. Any prices or other values
included in this message are indicative only, and do not
necessarily represent current market prices, prices at which
KBC FP would enter into a transaction, or prices at which
similar transactions may be carried on KBC FP's own books.
The information contained in this message is provided
"as is", without representations or warranties,
express or implied, of any kind. Past performance is not
indicative of future returns.

===================================
This list is hosted by DevelopMentorŪ  http://www.develop.com

View archives and manage your subscription(s) at http://discuss.develop.com

I'm thinking that, architecturally, you might want to head
in a slightly
different direction.

Storing of common data related to an application might
require a network
sub folder restricted to a security group, rather than going
for an
encryption (and an implementation of isolated storage?)

Domain
  |
  v
Site
  |
  v
Group
  |
  v
User

Also, applications can run under a separate user account
too, if you
want to head down that path, with a network home drive.

HTH,
Chay Harley


-----Original Message-----
From: Discussion of advanced .NET topics.
[mailto:ADVANCED-DOTNETDISCUSS.DEVELOP.COM] On Behalf Of Mont
Rothstein
Sent: Friday, March 28, 2008 9:25 AM
To: ADVANCED-DOTNETDISCUSS.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 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 be
a way to
create
a secure path between an app and stored data without
something key
(salt,
password, etc.) being stored in a readily available format. 
I consider
in-the-assembly to be readily available.

-Mont

===================================
This list is hosted by DevelopMentor(r)  http://www.develop.com

View archives and manage your subscription(s) at
http://discuss.develop.com


-- 
This message may contain confidential, proprietary, or
legally privileged information. No confidentiality or
privilege is waived by any transmission to an unintended
recipient. If you are not an intended recipient, please
notify the sender and delete this message immediately. Any
views expressed in this message are those of the sender, not
those of any entity within the KBC Financial Products group
of companies (together referred to as "KBC FP"). 

This message does not create any obligation, contractual or
otherwise, on the part of KBC FP. It is not an offer (or
solicitation of an offer) of, or a recommendation to buy or
sell, any financial product. Any prices or other values
included in this message are indicative only, and do not
necessarily represent current market prices, prices at which
KBC FP would enter into a transaction, or prices at which
similar transactions may be carried on KBC FP's own books.
The information contained in this message is provided
"as is", without representations or warranties,
express or implied, of any kind. Past performance is not
indicative of future returns.

===================================
This list is hosted by DevelopMentorŪ  http://www.develop.com

View archives and manage your subscription(s) at http://discuss.develop.com

A bit long but I am trying to clearly explain what I have
done and the
issue that has arisen...

In working on implementing the Producer/Consumer queue from
comments
earlier this week, I am doing much more (and needed) reading
on threads
and thread safety.

As a test example, I have an IO line that I want to 'blink'
(turn on and
off for 250ms each).  I figured I could easily do this with
a separate
thread.  So in a class instance of my main app, I create a
class
(Blinker)  to do this 'blinking'.  Blinker has a few
properties set
through its constructor.  It also has a 'Go' method (no
parameters) -
which sets up a while loop that continuously blinks the IO
line using
Sleep() statements - and one other property 'Stop' that can
be set to
'true' to get out of the loop.  OK so far.

So I set up a class instance of this 'Blinker' class in my
main app
class (this is so I'll always have a class reference to the
Blinker
object so I can get out of the loop, thus allowing a thread
that is
running the class to exit).  When I want to get the blinking
going, I do
the following.

            Thread blinkerThread = new Thread ( new
ThreadStart (
_blinker.Go ) );
            blinkerThread.Name = "blinkerThread";
            blinkerThread.Start();

This works fine and I can kill the blinkerThread by setting
Blinker.Stop
= true.

Now to my issue...

If I get the blinker going by way of this thread and then
close my app
without 'Stop'ing the blinker, the blinkerThread is still
alive thereby
not allowing my app to shut down correctly.  I can set the
IsBackground
property of the blinkerThread to true - this will make sure
that once
the main thread closes, the blinkerThread (if active) will
close as
well.

If I didn't want to set the 'IsBackgroud' property of the
thread, I
figured I could just implement IDisposable in my class and
set
Blinker.Stop=true in Dispose().  However, that didn't seem
to work.
Should it have worked?  How else might I ensure that the
blinkerThread
is ended correctly?

Sincerely,
Peter

===================================
This list is hosted by DevelopMentorŪ  http://www.develop.com

View archives and manage your subscription(s) at http://discuss.develop.com