Ethical Hacking Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package. | Computer Forensics Training at InfoSec Institute Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors. |

| Subject: | RE: secure storage of sensitive data in J2EE |
|---|---|
| Date: | Wed, 9 Feb 2005 22:04:56 -0800 |
Re: Malicious app
Sure, but we're trying to reduce the window of opportunity! There's some commentary here http://msdn.microsoft.com/msdnmag/issues/05/01/SecurityBriefs/default.as px [Writing Secure Code] http://www.microsoft.com/mspress/books/5957.asp [Protect Your PC] http://www.microsoft.com/protect [Blog] http://blogs.msdn.com/michael_howard -----Original Message----- From: Michael Silk [mailto:michaelsilk@gmail.com] Sent: Wednesday, February 09, 2005 9:13 PM To: Michael Howard Cc: webappsec@securityfocus.com Subject: Re: secure storage of sensitive data in J2EE But my point was that if there is a local app trying to look through the memory of the .net runtime for the "secure" string, why doesn't it just instead bypass that and look for where the String _comes in_ to that memory. (i.e. from the user submission, or from something else).
You can encrypt the data by user, by process or by machine. It's all supported through Crypt[Un]ProtectMemory
So you are saying that upon your setting up of a SecureString you can tell it to encrypt the information by process; something like: --- new SecureString(mySecretData, ENCRYPTION_DOMAIN.Process); --- Even so, wouldn't another malicious asp.net app be running in the same process? On Wed, 9 Feb 2005 21:06:33 -0800, Michael Howard <mikehow@microsoft.com> wrote:
It certainly can't help the data on the network - I know of no programming language that can!! The real threat being mitigated here is a local attack trying to
grovel
through an app or pagefile for secret data. You can encrypt the data by user, by process or by machine. It's all supported through Crypt[Un]ProtectMemory [Writing Secure Code] http://www.microsoft.com/mspress/books/5957.asp [Protect Your PC] http://www.microsoft.com/protect [Blog] http://blogs.msdn.com/michael_howard [On-line Security Training] http://mste/training/offerings.asp?TrainingID=53074 -----Original Message----- From: Michael Silk [mailto:michaelsilk@gmail.com] Sent: Wednesday, February 09, 2005 7:12 PM To: webappsec@securityfocus.com; Michael Howard Subject: RE: secure storage of sensitive data in J2EE Michael, What is some example implementations of the usage of SecureString? To store a CC coming from a submission? Surely it could be tracked as it's coming in (browser -> server -> [ here ! ] -> your code), in that case. To store a password? Where does the password initially come from? and where does it get used? do other API's take a SecureString and _never_ realise it into a common string form? It seems the weak link in the chain would break this one, ... or am I missing something :) ? Further, on what basis is it encrypted? Under the user that is running the code? As such, wouldn't any other (malicious) .net code be running under the same privileges and hence be able to decrypt it? -- Michael Silk-----Original Message----- From: Michael Howard [mailto:mikehow@microsoft.com] Sent: Thursday, 10 February 2005 10:15 AM To: Benjamin Livshits; chaim moshe; webappsec@securityfocus.com Subject: RE: secure storage of sensitive data in J2EE I know this is not J2EE, but in .NET Framework, we added a SecureString class that: 1) is automatically encrypted in memory (to mitigate the paged-out-data threat) 2) is cleared when the string is no longer used 3) is GC'd rapidly
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: PCI - Visa / MC / Amex merchant security standards, Andre Ludwig |
|---|---|
| Next by Date: | Re: secure storage of sensitive data in J2EE, Alexander Klimov |
| Previous by Thread: | Re: secure storage of sensitive data in J2EE, exon |
| Next by Thread: | Re: secure storage of sensitive data in J2EE, exon |
| Indexes: | [Date] [Thread] [Top] [All Lists] |