Does any encrypted password in a text file expire?

I know this sounds crazy, but I have an encrypted password in a file that works for a while then suddenly stops and I have to recreate the file.  And no, the account password itself has not changed.  Is the encrypted PW  based on some timer, for example like when the machine password in the domain changes?

Here is my code to create the file:

$SecurePassword = Read-Host -Prompt "Enter password for PowerShell account" -AsSecureString
$SecureStringAsPlainText = $SecurePassword | ConvertFrom-SecureString
$SecureStringAsPlainText | Out-File ".\PW.txt" -Encoding ASCII

I can then use the that password file (for an account I specify in another script) for weeks without problem.  Then suddenly it fails to work.  I get this error:

ConvertTo-SecureString : Key not valid for use in specified state.

I am using the same account to run the script that I used to create the PW file - so that is not the problem.  The only way to fix this is to recreate the PW file, using the same exact password I used to create it the previous time.  In other words - nothing has changed that I know of.  Same password, same account name, etc.  So I am wondering, is there something on the machine I run the script from that is used to encrypt the PW with, and that "something" changes every couple of months?

My guess is the machine domain account password changes and this breaks the encrypted PW file. Am I right?

Thanks

NK

December 6th, 2013 10:16am

Have you compared the encrypted contents of the file when you recreate it, or converting the the encrypted pword back to human readable string to test your theory?

$UnsecurePW = [System.Runtime.InteropServices.Marshal]::PtrToStringAuto([System.Runtime.InteropServices.Marshal]::SecureStringToBSTR($(ConvertTo-SecureString $(gc .\pw.txt))))

If your UnsecurePW doesn't match what you think it hsould, you'll know it's definitely changed, and to what.  I did a very brief search to try to find what the -AsSecureString uses for a key but was unsuccessful because I just woke up and am a bit hungover.  Hope this helps!

Free Windows Admin Tool Kit Click here and download it now
December 7th, 2013 8:39am

Those cmdlets use DPAPI ( http://msdn.microsoft.com/en-us/library/ms995355.aspx .)  DPAPI does generate new Master Keys from time to time, but they're all stored in the user's profile, and you should not lose the ability to decrypt old data.  Few questions:

  • Is this script running as a domain account, or as a local user?
  • Does anyone mess with the account's user profile, deleting all or parts of it and allowing them to be recreated?

Your DPAPI master keys are stored in <Profile Dir>\AppData\Roaming\Microsoft\Protect\<Account SID>\ .  They're marked as Hidden and System, so you'll need to make sure you're viewing those files to be able to see them.

The master key files in that directory are encrypted using a hash of the user's password; if anyone resets the password, you lose access to those keys (unless you're either in Active Directory, which has a backup mechanism in place on the domain controllers, or you have made a Password Recovery Disk for a local account.)  You mentioned that the account's password hasn't changed, so that's probably not an issue here, but I figured I'd mention it so you know how DPAPI works.

If the account's password has not changed at all, my best guess is that someone has managed to delete the old master key(s) from the user profile, one of which was used to encrypt the SecureString originally.

December 7th, 2013 9:26am

After re-reading your post, I think maybe you meant that the password that you're saving hasn't changed.  It's the password of the user who is running the script and performing the encryption / decryption that is important to DPAPI, though.  If you do a "Change Password" operation from this workstation, DPAPI automatically decrypts your master keys and re-encrypts them with your new password.  If you do "Set Password" or change the password from a different computer, though, you lose access to your old master keys on this machine (unless you're in Active Directory, which keeps its own copies of the keys that will be restored for you behind the scenes.)

That's what this warning message is all about when you choose Set Password or Reset Password on an account:

"Resetting this password might cause irreversible loss of information for this user account.  For security reasons, Windows protects certain information by making it impossible to access if the user's password is reset.

This data loss will occur the next time the user logs off.

You should use this command only if a user has forgotten his or her password and does not have a password reset disk.  If this user has created a password reset disk, then he or she should use that disk to set the password.

If the user knows the password and wants to change it, he or she should log in, then press CTRL+ALT+DELETE and click Change Password."

Free Windows Admin Tool Kit Click here and download it now
December 7th, 2013 9:41am

Hello,

Thank you for the response.  Neither the domain account password or the password stored in the encrypted file to match that account's password have changed (yet).  Eventually the domain account password will change, and at that time I will re-run my encryption script to create the new encrypted text file.  But at this point, the domain account has not changed yet so that encrypted password in the file should still match it.  And the account used to RUN the other script which makes use of the encrypted password file has not changed either.

Additionally the profile of the account used to run the script that uses the encrypted password file has not changed (deleted) either.  It only runs on one machine and I am pretty much the other one that ever uses it.  And I have my desktop for that account set a specific way so I would know right away if the profile got deleted and recreated using the default profile.

So yeah - this is why I am so confused.  I know once the domain password changes I will have to create a new file - but that has not happened yet.  This is the second time this has happened - both times the passwords have not changed but I had to recreate the text file (using the same password as before, since the password had not changed) to get things rolling again.  I have not kept track of the times (yet) so at this point I do not yet know the freqency of the break point.

NK

December 7th, 2013 12:18pm

I'm not sure what else could cause that error.  In your place, I'd try making a backup of the Protect folder in my user profile, and then the next time the error occurs, compare the contents of the backup folder to what's in the live profile.  If you haven't changed your password, then all of the master key files from the backup should still exist, with identical contents.  (Even if you have changed your passwords, all the same key files should exist, but their contents will have been re-encrypted with a new password.)   The live profile may also have new master keys that didn't exist at the time of the backup, but that's normal and can be ignored.
Free Windows Admin Tool Kit Click here and download it now
December 7th, 2013 8:45pm

I'm not sure what else could cause that error.  In your place, I'd try making a backup of the Protect folder in my user profile, and then the next time the error occurs, compare the contents of the backup folder to what's in the live profile.  If you haven't changed your password, then all of the master key files from the backup should still exist, with identical contents.  (Even if you have changed your passwords, all the same key files should exist, but their contents will have been re-encrypted with a new password.)   The live profile may also have new master keys that didn't exist at the time of the backup, but that's normal and can be ignored.
December 8th, 2013 4:38am

I'm not sure what else could cause that error.  In your place, I'd try making a backup of the Protect folder in my user profile, and then the next time the error occurs, compare the contents of the backup folder to what's in the live profile.  If you haven't changed your password, then all of the master key files from the backup should still exist, with identical contents.  (Even if you have changed your passwords, all the same key files should exist, but their contents will have been re-encrypted with a new password.)   The live profile may also have new master keys that didn't exist at the time of the backup, but that's normal and can be ignored.
Free Windows Admin Tool Kit Click here and download it now
December 8th, 2013 4:38am

I'm not sure what else could cause that error.  In your place, I'd try making a backup of the Protect folder in my user profile, and then the next time the error occurs, compare the contents of the backup folder to what's in the live profile.  If you haven't changed your password, then all of the master key files from the backup should still exist, with identical contents.  (Even if you have changed your passwords, all the same key files should exist, but their contents will have been re-encrypted with a new password.)   The live profile may also have new master keys that didn't exist at the time of the backup, but that's normal and can be ignored.
December 8th, 2013 4:38am

Thanks - I will go ahead and give that a try.

NK

Free Windows Admin Tool Kit Click here and download it now
December 9th, 2013 9:12am

Did you ever have a resolution on this?   I am seeing the same behavior, it appears that the user loses ability to reread password from file post reboot.
April 23rd, 2014 12:26pm

We never did hear back from Nelson, but the same information I gave him applies here.  DPAPI relies on encryption keys that are stored in a user's profile (and those key files are themselves encrypted by the user's logon credentials.)

If anything is interfering with the user's ability to save and later retrieve these DPAPI keys, you won't be able to decrypt the data.

Free Windows Admin Tool Kit Click here and download it now
April 23rd, 2014 12:43pm

I am unable to recreate the problem on my own - it happens randomly.  So I don't know if the problem is fixed or not.  It has happened at least once since my last post, but it has also not happened in a long time since then as well.  As far as I know, it could break tomorrow and I would still have no clue as to what cause's it to break or what the permanent solution is to prevent it.

Sorry I am not more help.  At this point I just live with it and fix it when it breaks....just luckily it has not broken in a while.

Nelson

April 23rd, 2014 1:12pm

I have a similar issue. I am calling the script(similar code to Nelson) from a Website(App Pool for the Website uses the same Service Account as when the password file was made). Both the website and the location of the script are on the same server. This will work for a while and then stop working for the website to call this script and will error stating "ConvertTo-SecureString : The system cannot find the file specified". I then run the powershell script from the powershell console with run as the Service account that made the file and will work fine. After I ran it once from powershell console I will then call it again from the website and will work for few weeks again.

I am wondering if what is causing Nelson script to break would be the same thing that is breaking mine.

Thanks,

Dustin

Free Windows Admin Tool Kit Click here and download it now
April 24th, 2014 4:45pm

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics