|
|
You're in the
dotnet security
group:Storing a private key
dotnet security:
I have a server and client program. The client encrypts data being sent to the server using the servers public key before it transmits it to the server over a tcp connection. The question i have though, is where do i store the private key on the server so that it will be safe?! In my mind (at least for the moment ....) there is no place to put it that couldn't be compromised in one way or another. The server also uses the same public key to encrypt other files it has stored containing database usernames and passwords - hence my concerns about storing the private key somewhere safe. I would have liked to just 'keep the key in memory', but we all know what would happen when Windows got bored and decided it was time to blue-screen-of-death :-0 Thanks in advance for your help, James Randle.
In answer to my self!
http://groups.google.com/group/microsoft.public.dotnet.security/browse_thread/thread/f1b6b4240771c8d2/80d4620876fa8b75?lnk=gst&q=storing+private+key&rnum=1#80d4620876fa8b75 unless of course anyone else feel like they should add something specifically pertaining to my exmaple? Cheers, James Randle. [quoted text, click to view] pigeonrandle wrote:
> Hi, > I have a server and client program. The client encrypts data being sent > to the server using the servers public key before it transmits it to > the server over a tcp connection. > > The question i have though, is where do i store the private key on the > server so that it will be safe?! In my mind (at least for the moment > ...) there is no place to put it that couldn't be compromised in one > way or another. > > The server also uses the same public key to encrypt other files it has > stored containing database usernames and passwords - hence my concerns > about storing the private key somewhere safe. > > I would have liked to just 'keep the key in memory', but we all know > what would happen when Windows got bored and decided it was time to > blue-screen-of-death :-0 > > Thanks in advance for your help, > James Randle.
Storing secrets is a hard problem. There is an entire chapter about this
topic in "Writing Secure Code" which is well worth a read if you are serious about understanding this in detail. People typically use things like DPAPI for helping to store secrets, but that doesn't provide a complete solution and also comes with its own issues. Since you have a private key for a certificate, you can also store that in a standard key container and apply extra security to it. However, there might not be an easy way to use the password protection feature on the key and still access it from a server application. Storing encrypted passwords is generally regarded as a bad design that introduces much more risk than storing a salted hash of the password instead. When you encrypt, if your key is compromised, the user's plaintext passwords can be recovereded directly. When you hash, you don't even know the user's plaintext password. Only brute force techniques can be used to try to get the plaintext, and a good design can typically make that effort too expensive to contemplate. Joe K. -- Joe Kaplan-MS MVP Directory Services Programming Co-author of "The .NET Developer's Guide to Directory Services Programming" http://www.directoryprogramming.net -- [quoted text, click to view] "pigeonrandle" <pigeonrandle@hotmail.com> wrote in message news:1153908969.044048.33770@i3g2000cwc.googlegroups.com... > Hi, > I have a server and client program. The client encrypts data being sent > to the server using the servers public key before it transmits it to > the server over a tcp connection. > > The question i have though, is where do i store the private key on the > server so that it will be safe?! In my mind (at least for the moment > ...) there is no place to put it that couldn't be compromised in one > way or another. > > The server also uses the same public key to encrypt other files it has > stored containing database usernames and passwords - hence my concerns > about storing the private key somewhere safe. > > I would have liked to just 'keep the key in memory', but we all know > what would happen when Windows got bored and decided it was time to > blue-screen-of-death :-0 > > Thanks in advance for your help, > James Randle. >
[quoted text, click to view]
"pigeonrandle" <pigeonrandle@hotmail.com> wrote in message news:1153908969.044048.33770@i3g2000cwc.googlegroups.com... > I have a server and client program. The client encrypts data being sent > to the server using the servers public key before it transmits it to > the server over a tcp connection. > > The question i have though, is where do i store the private key on the > server so that it will be safe?! In my mind (at least for the moment > ...) there is no place to put it that couldn't be compromised in one > way or another. Correct. The same is true if you store the certificate in a safe. The person who has access to the safe and its combination could very easily open the safe, pull out the certificate, and use it. [quoted text, click to view] > The server also uses the same public key to encrypt other files it has > stored containing database usernames and passwords - hence my concerns > about storing the private key somewhere safe. How about the certificate store? Seems like a good place to store a certificate and its private key. [quoted text, click to view] > I would have liked to just 'keep the key in memory', but we all know > what would happen when Windows got bored and decided it was time to > blue-screen-of-death :-0 What you're touching on here is the "rouge admin" theory of computer security, exemplified by the question "what software / settings do I use to protect my systems and their data from the system administrators?" The answer is "none". Your administrators are administrators. The people who view the memory dump on your system are administrators. The people who can expose keys from the certificate store are administrators. Administrators are trustworthy individuals who can be entrusted with complete control of all data and operations on the systems that they administer. If you cannot state that about your administrators, demote and / or fire them, replacing them with people that you are willing to trust - or, remove the sensitive data from the systems that they administer. The certificate store is an adequate place to store private keys. Learn how to protect your private keys using NTFS rights on the Crypto\RSA directory. And trust - or remove - your administrators. Alun. ~~~~ [Please don't email posters, if a Usenet response is appropriate.] -- Texas Imperial Software | Find us at http://www.wftpd.com or email 23921 57th Ave SE | alun@wftpd.com. Woodinville WA 98072-8661 | WFTPD, WFTPD Pro are Windows FTP servers. Fax/Voice +1(425)807-1787 | Try our NEW client software, WFTPD Explorer.
Alun,
Thanks for your insight. I guess i can trust them, and i presume (as a precaution) that i can enter a clause in the EULA stating that it is their responsibility to ensure their network is secure..? Cheers, James. [quoted text, click to view] Alun Jones wrote:
> "pigeonrandle" <pigeonrandle@hotmail.com> wrote in message > news:1153908969.044048.33770@i3g2000cwc.googlegroups.com... > > I have a server and client program. The client encrypts data being sent > > to the server using the servers public key before it transmits it to > > the server over a tcp connection. > > > > The question i have though, is where do i store the private key on the > > server so that it will be safe?! In my mind (at least for the moment > > ...) there is no place to put it that couldn't be compromised in one > > way or another. > > Correct. The same is true if you store the certificate in a safe. The > person who has access to the safe and its combination could very easily open > the safe, pull out the certificate, and use it. > > > The server also uses the same public key to encrypt other files it has > > stored containing database usernames and passwords - hence my concerns > > about storing the private key somewhere safe. > > How about the certificate store? Seems like a good place to store a > certificate and its private key. > > > I would have liked to just 'keep the key in memory', but we all know > > what would happen when Windows got bored and decided it was time to > > blue-screen-of-death :-0 > > What you're touching on here is the "rouge admin" theory of computer > security, exemplified by the question "what software / settings do I use to > protect my systems and their data from the system administrators?" > > The answer is "none". Your administrators are administrators. The people > who view the memory dump on your system are administrators. The people who > can expose keys from the certificate store are administrators. > > Administrators are trustworthy individuals who can be entrusted with > complete control of all data and operations on the systems that they > administer. > > If you cannot state that about your administrators, demote and / or fire > them, replacing them with people that you are willing to trust - or, remove > the sensitive data from the systems that they administer. > > The certificate store is an adequate place to store private keys. Learn how > to protect your private keys using NTFS rights on the Crypto\RSA directory. > And trust - or remove - your administrators. > > Alun. > ~~~~ > [Please don't email posters, if a Usenet response is appropriate.] > -- > Texas Imperial Software | Find us at http://www.wftpd.com or email > 23921 57th Ave SE | alun@wftpd.com. > Woodinville WA 98072-8661 | WFTPD, WFTPD Pro are Windows FTP servers. > Fax/Voice +1(425)807-1787 | Try our NEW client software, WFTPD Explorer.
Don't see what you're looking for? Try a search.
|
June 2004
July 2004
August 2004
September 2004
October 2004
November 2004
December 2004
January 2005
February 2005
March 2005
April 2005
May 2005
June 2005
July 2005
August 2005
September 2005
October 2005
November 2005
December 2005
January 2006
February 2006
March 2006
April 2006
May 2006
June 2006
July 2006
August 2006
September 2006
October 2006
November 2006
December 2006
January 2007
February 2007
March 2007
April 2007
May 2007
June 2007
July 2007
August 2007
September 2007
October 2007
November 2007
| home · blog · groups | Questions? Comments? Contact the dn |