FYI: Windows XP Pro - Encryption - AVOID

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Well, I had a big scare yesterday, and found out why Windows XP Pro
folder/object encryption is a BAD THING.

Reason - it doesn't work right.

Heres what happened:
1) I have two accounts define on my system, both for me. One is play, the
other work. Work account has many things specific to my company.
2) Passwords are set to expire 60 days following a password change (same as
company policy)
3) Encrypted two folders (w/content) and about 7 independent objects under
work profile. All due to the fact that it contains sensitive information.
4) Password was ready to expire in one day. At the prompt reading "Do you
want to change your password now?", I responded by pushing the button "YES".
5) All appeared to work well, not immediately identifyable issues.
6) Attempted to launch a business application (one that happens to use one
of the encrypted objects.)
7) PROGRAM FAILURE: Due to inability to access the object.
8) Further examination revealed that all encrypted folders/objects were
inaccessable.

Well, I've learned my lesson: NEVER, BUT NEVER, USE MICROSOFT WINDOWS XP PRO
TO ENCRYPT FOLDERS (w/content) OR OBJECTS. It'll COST BIG TIME.

So, just a bit of info to share, based on my experience over the last two
days.

All is recovered and working - without encryption. The real hard stuff is in
a separate encrypted volume based on PMC Ciphers TurboCrypt Polymorphic
encryption engine (at a 208 bit strength too.) What Windows was used for were
those folders/objects where the application HAD to have the content in a
certain folder location.
 
Jim said:
Well, I had a big scare yesterday, and found out why Windows XP Pro
folder/object encryption is a BAD THING.

Reason - it doesn't work right.

Heres what happened:
1) I have two accounts define on my system, both for me. One is
play, the other work. Work account has many things specific to my
company. 2) Passwords are set to expire 60 days following a
password change (same as company policy)
3) Encrypted two folders (w/content) and about 7 independent
objects under work profile. All due to the fact that it contains
sensitive information. 4) Password was ready to expire in one day.
At the prompt reading "Do you want to change your password now?", I
responded by pushing the button "YES". 5) All appeared to work
well, not immediately identifyable issues. 6) Attempted to launch a
business application (one that happens to use one of the encrypted
objects.) 7) PROGRAM FAILURE: Due to inability to access the object.
8) Further examination revealed that all encrypted folders/objects
were inaccessable.

Well, I've learned my lesson: NEVER, BUT NEVER, USE MICROSOFT
WINDOWS XP PRO TO ENCRYPT FOLDERS (w/content) OR OBJECTS. It'll
COST BIG TIME.

So, just a bit of info to share, based on my experience over the
last two days.

All is recovered and working - without encryption. The real hard
stuff is in a separate encrypted volume based on PMC Ciphers
TurboCrypt Polymorphic encryption engine (at a 208 bit strength
too.) What Windows was used for were those folders/objects where
the application HAD to have the content in a certain folder
location.
Click to expand...

Wouldn't it be better to say, "Never, but never, use things without
following the 'best practices' laid out for them and understanding them
fully"?
 
Well, given that I'd read what I could, researched by talking with MS Windows
experts at my organization, attempted to locate any material that would
identify the risks of using the option - I think I fairly understood how it
worked and understood the risks - up to and including protecting myself with
recover disks (as was indicated in the post).

Being an IT professional, and knowing not to step off the cliff without
checking for a safety net, I believed that I'd examined the risks. There
just wasn't one listed indicating that somthing as simple as changing the
password would render encrypted data useless. Yes, I know that the
encryption is based on the profile/password combination (along with the
system encryption key values); but most environments that support
profile/password usage understand that passwords - to remain effective - must
be changed/updated on a regular basis.

The use of the EFS was contemplated and implemented following research and
understanding (certainly not at "expert level"; but much higher than novice).

It has nothing to do with "understanding" the options. It has everything to
do with the implementation of the option on a secure system.

For example, at MS web site
http://www.microsoft.com/technet/prodtechnol/winxppro/deploy/cryptfs.mspx,
the statement by MS is as follows: changing of a local user password by an
administrator, or through a method other than by the user, will block all
access to previously encrypted files by the user.

The operative clause is "other than by the user". In this case, it was BY
THE USER.

So, to implement such a usage, and to expect normal activity to be
accommodated by the OS, is not really to much to ask. However, MS Windows XP
Pro evidently doesn't expect the EFS to be used, and if it is, then to be
used in a practice that is non-standard by most security publications and
administrators (which I am a systems security engineer for my company.)
 
Jim said:
Well, given that I'd read what I could, researched by talking with
MS Windows experts at my organization, attempted to locate any
material that would identify the risks of using the option - I
think I fairly understood how it worked and understood the risks -
up to and including protecting myself with recover disks (as was
indicated in the post).

Being an IT professional, and knowing not to step off the cliff
without checking for a safety net, I believed that I'd examined the
risks. There just wasn't one listed indicating that somthing as
simple as changing the password would render encrypted data
useless. Yes, I know that the encryption is based on the
profile/password combination (along with the system encryption key
values); but most environments that support profile/password usage
understand that passwords - to remain effective - must be
changed/updated on a regular basis.

The use of the EFS was contemplated and implemented following
research and understanding (certainly not at "expert level"; but
much higher than novice).

It has nothing to do with "understanding" the options. It has
everything to do with the implementation of the option on a secure
system.

For example, at MS web site
http://www.microsoft.com/technet/prodtechnol/winxppro/deploy/cryptfs.mspx,
the statement by MS is as follows: changing of a local user
password by an administrator, or through a method other than by the
user, will block all access to previously encrypted files by the
user.

The operative clause is "other than by the user". In this case, it
was BY THE USER.

So, to implement such a usage, and to expect normal activity to be
accommodated by the OS, is not really to much to ask. However, MS
Windows XP Pro evidently doesn't expect the EFS to be used, and if
it is, then to be used in a practice that is non-standard by most
security publications and administrators (which I am a systems
security engineer for my company.)
Click to expand...

So you had the key backed up and nothing came of all this, right?
 
Jim said:
For example, at MS web site
http://www.microsoft.com/technet/prodtechnol/winxppro/deploy/cryptfs.mspx,
the statement by MS is as follows: changing of a local user password by an
administrator, or through a method other than by the user, will block all
access to previously encrypted files by the user.

The operative clause is "other than by the user". In this case, it was BY
THE USER.
Click to expand...

If you changed your password using the standard methods provided by the
operating system, you shouldn't have lost access to your encrypted files. If
you did, that's a bug.

I'm wondering if the "do you want to change your password now" prompt was coming
from some third-party software? If so, it might not be implementing the
password change procedure in a way that is compatible with file encryption.

... on the other hand I'm wondering how this is supposed to work in a domain
context. Unless your encryption keys are stored centrally (which I don't think
is the case) then changing your password from any one computer would lose any
encrypted files you have on any other computers. Does anybody know the answer
to this one?

Harry.
 
Thank you Mr. Johnston for your insight.

My configuration, for this specific aspect, is pure MS Windows XP Pro - no
3rd party products to handle log in/setup/encryption.

There is one independent product installed, but it is a product that
establishs virtual encrypted drive, and has its own internal password
use/encryption engine (specifically PMC Ciphers product TurboCrypt). This
product is where all the CSI/NPPI (Customer Sensitive Information/Non Public
- Private Information) is retained, using a 208 bit encryption key, based on
Polymorphic encryption technology.)

However, you bring up an interesting point- specifically related to domain
access.

In the case of my system, I work from home connected to my Corporate network
via a product call iPass. Embedded in this product is the Nortel Contivity
product.

As with any tightly controlled domain, I have both a managed image lap top
(as my travel/in-off unit) while I use my person PC (installed with the
corporation's deployed offce/mail/development/mainframe access products.)
Use of the Nortel tunnelling technology allows me to encrypt and access
systems thru the firewall on those systems that reside on non-public facing
systems (I am a iSeries Security Engineer for a large financial organization.)

Your observation brings up the idea, that the Corporation is feeding back
configuration data to systems accessing their network, that is unknown to the
remote user. While it generally is passive, it may have affected the
processes that retain the balance between current profile/password settings,
and newly changed passwords. However, this seems very unlikely - as I am
part of the group that also deploys the managed images, and there have been
no deployments of this type that I'm aware of.

Once again, thank you for the review and insight in which you've provided.
 
Back
Top