1996-01-21 - Re: Idea for “friendly” Windows password hack

Header Data

From: pgut01@cs.auckland.ac.nz
To: llurch@networking.stanford.edu
Message Hash: a4138bd4a818e933b01989c197774ba594b1861dd6f979c11ab71552e401cff3
Message ID: <199601210936.WAA22159@cs26.cs.auckland.ac.nz>
Reply To: N/A
UTC Datetime: 1996-01-21 09:49:30 UTC
Raw Date: Sun, 21 Jan 1996 17:49:30 +0800

Raw message

From: pgut01@cs.auckland.ac.nz
Date: Sun, 21 Jan 1996 17:49:30 +0800
To: llurch@networking.stanford.edu
Subject: Re: Idea for "friendly" Windows password hack
Message-ID: <199601210936.WAA22159@cs26.cs.auckland.ac.nz>
MIME-Version: 1.0
Content-Type: text/plain


>Why not provide a way to grab the passwords cached in RAM, encrypt them
>securely, put them away somewhere, and scramble the original copy of the
>passwords in RAM so that Microsoft's code can't get to them?
 
Ahh, the problem is the "put them away somewhere" part.  There's nowhere to put
them.  The solution I'm using now for an (unreleased) variant of SFS is to
store encryption keys in write-only hardware as per FIPS PUB 140-1, but that's
hardly practical for most systems.  The same standard also allows for key
storage in software, but at the minimum useful level (level 2) you need at
least a C2-certified OS to protect the keys (the standard is good reading when
it comes to protecting encryption subsystems BTW, as are the specs for things
like GSS-API and GCS-API).  This isn't going to happen under Win'95 (for
example, here's how to get to any keys held in memory by the OS: Win'95 allows
for demand-loaded VxD's, so you run a trojan with an embedded VxD which
searches the system VM for the keys and then unloads itself). It would require
a significant reengineering of Win'95 to make it even passably secure (assuming
MS don't screw up the implementation), and I don't think it's practical to do.
Under NT you can do it to some extent because this level of security was
designed in from the start.
 
Peter.





Thread