Re: Application Security

• Previous message: Keith Patrick: "Re: Application Security"
• In reply to: Keith Patrick: "Re: Application Security"
• Next in thread: Nathan Bullock: "Re: Application Security"
• Reply: Nathan Bullock: "Re: Application Security"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

Date: Tue, 26 Aug 2003 11:59:14 -0700

DPAPI has quite a few limitations and in Nathan's case (when data are stored
on the end-client's systems), it is not going to help, because - unless I
got it wrong - the problem is not only storing data securely, but not
allowing the end user to see (or be able to decrypt) them. There are several
scenarios in which DPAPI is the best (or the least worst) approach, but not
in this particular situation.

Alek

"Keith Patrick" <richard_keith_patrick@hotmail.com> wrote in message
news:uGw0LCAbDHA.1872@TK2MSFTNGP12.phx.gbl...
> Have you looked into storing your passwords via the Data Protection API?
> I've personally never used it (right now, I am doing a bad thing and
storing
> a key in my web.config), but that was a suggestion in "Writing Secure
Code"
>
> "Nathan Bullock" <nathan_kent_bullock@yahoo.ca> wrote in message
> news:52f8effc.0308260611.4b563b0f@posting.google.com...
> > Thank you very much for the answer.
> >
> > It is a Windows Forms application and the solutions you gave were
> > exactly the sort of ideas I was looking for. I already knew that our
> > solutions was very insecure but sometimes it is tough getting other
> > people to see this.
> >
> > Anyway thanks again. Any continued ideas or comments on this subject
> > from other posters would definetely be appreciated.
> >
> > Nathan Bullock
> >
> > "Alek Davis" <alek_DOT_davis_AT_intel_DOT_com> wrote in message
> news:<OyfpTN2aDHA.300@TK2MSFTNGP12.phx.gbl>...
> > > Nathan,
> > >
> > > It would've helped if you defined what you meant by ".NET (C#)
clients."
> Are
> > > these Windows Forms applications, ASP.NET applications, Windows
> services, or
> > > something else? Do they run on end users' desktops or on the servers?
> Who
> > > are the users of these applications? Are they end users or
> administrators
> > > responsible for installing and configuring these client applications?
> Does
> > > you application run in a Windows domain (Active Directory) environment
> or a
> > > workgroup? You see, depending on how you answer this question, the
> solution
> > > may be easy, not so easy, difficult, or very difficult.
> > >
> > > I assume that your C# clients are not distributed to end users. If
they
> are
> > > and they do connect to the database server directly, you should
probably
> > > rethink your application architecture. It is normally not recommended
to
> > > allow front-end applications (such as Windows Forms or Web Forms) to
> connect
> > > to database servers directly. The recommended approach is: the front
end
> > > (GUI) calls the middle tier implementing the business logic and the
> middle
> > > tier makes the database calls. Calls between the GUI and the business
> layer
> > > are normally done using remoting, Web services, or in cases of ASP.NET
> > > applications class libraries (since in the latter scenario the GUI
> > > generating logic already runs on a remote - i.e. Web - server). In
this
> > > architecture, you are not concerned about end users being able to get
> your
> > > connection string info as much as if you would otherwise, although you
> still
> > > need to implement at least some protection against internal hackers
(or
> risk
> > > of compromised system).
> > >
> > > Under certain conditions, the best option would be to use Integrated
> Windows
> > > authentication, so the C# clients would not have to specify SQL
> credentials
> > > when connecting to the database server (and therefore would not have
to
> > > store them). Unfortunately, in quite a few cases, this is not feasible
> or
> > > efficient approach, so if you need to use SQL authentication, you have
a
> > > challenge. There are certain options available, but in the end, you
will
> > > basically have to pick between bad solutions and very bad solutions.
> > >
> > > You can review Microsoft recommendations related to this issue at
> > >
>
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetsec/html/SecNetch12.asp
> > > (Data Access Security), but all of their suggestions have limitations.
> > > "Writing Secure Code" by Michael Howard and David LeBlanc also has a
> chapter
> > > dedicated to this topic (it is not available online, though, but I
would
> > > recommend this book to every developer). In my humble opinion,
> > > CipherSafe.NET (http://www.obviex.com/ciphersafe/) comes closest to
the
> > > ideal solution, but depending on the type of your application, it may
> not
> > > work for you.
> > >
> > > --
> > > Alek
> > >
>
>

• Previous message: Keith Patrick: "Re: Application Security"
• In reply to: Keith Patrick: "Re: Application Security"
• Next in thread: Nathan Bullock: "Re: Application Security"
• Reply: Nathan Bullock: "Re: Application Security"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]