I'm reading MSDN and seeing CryptProtectData and CryptUnprotectData. Is there a "CryptRemoveData" style function that I can call when my product's uninstaller runs?
I'm guessing that the [edited add words "session token"] session token data just hangs around in the HKCU hive forever if I don't remove it?
Should I instead call CryptProtectData with a very small chunk of data to clear it out.
[Edit, added this vague sentence from MSDN "Typically, only a user with logon credentials that match those of the user who encrypted the data"]
Related
i've been practicing with the near-cli as part of my personal project to automate some tasks, this requires running near login quite a few times in debugging. However, when i do near login it seems to create a new public key every time, as when I do near keys <account> from time to time I see this list grow. When I did near keys delete <public_key> to cleanup, it did give a warning about accidentally deleting the wrong public key, so I attempted dropping keys older than the last one entered, however running near login again gave an error that I had deleted the key that gave access thru the web login. (I kept the key value and did near keys add <public_key> to restore access.
My question is, how best do I keep track of which public_keys are safe to delete when experimenting with the CLI this way?
The simplest answer is: Make sure you always have one keypair left. Keys are stored in ~/.near-credentials, with files containing both the private and public part of the key. Always keep one of these files, and make you don't remove the corresponding key from the account.
I'm having a difficult time figuring out why RegOpenCurrentUser has a samDesired parameter at all. Surely it's always going to be KEY_ENUMERATE_SUB_KEYS or even 0?
A subsequent call to RegOpenKeyEx is required to do anything meaningful in the impesronated user's registry profile. Wouldn't you pass the specific samDesired value to that call? Are there any access requirements for the first parameter (hKey) to RegOpenKeyEx?
RegOpenCurrentUser returns a handle to the root of a registry hive. I can't think of any scenario other than installing Windows or creating a brand new user profile where anything is done at a hive root. And if you're running a program as another user, presumably all of that is already done.
RegOpenCurrentUser: http://msdn.microsoft.com/en-us/library/windows/desktop/ms724894(v=vs.85).aspx
RegOpenKeyEx: http://msdn.microsoft.com/en-us/library/windows/desktop/ms724897(v=vs.85).aspx
I write a data say 'qwerty' in a block 05 (keyA). Try reading it. its successful. trying to update/rewrite the same block with another data say 'asdfg'. but i could'nt authenticate the block. getting error message.
Am i missing any settings or any suggestions on this issue
Did you also write the access bits? In normal condition, it won't be any problem for authentication if you do not change access bits.
For example, on the one hand, I can check
if a file can be written to by building up a security identifier for a user,
establishing a trustee,
getting a discrete access control list and
then getting the access mask
finally checking if it contains the FILE_GENERIC_WRITE bit.
On the other hand I could just
call GetFileAttributes and
see if the returned value == FILE_ATTRIBUTE_READONLY
For the latter case if this attribute is set, I guess it means I don't have to bother with the ACL stuff. Or is there some other subtle point that I am missing?
Is it that the GetFileAttributes returns DOS information while the access control list function is newer windows api? Should I be checking for both?
Cheers,
Ben.
The file attributes have no relation to ACLs.
You can have a "read only" file that you can have full permissions to, and non read only files that you have no access to at all.
You can also have non read only files with full access that you still can;t write to due to read only media.
Further more, the read only flag can also be removed by anyone with (write) access to the file.
The best way to see if you can write to a file is to try and write to it (or at least open it for writing).
I am using dompdf to create pdf files. But whant I want to be done is to create once the file, so the user can see the contents, but protect the file so the user once he close it, he can't reopen it later. Is that possible OR should I use other program?
This really isn't possible. It sounds like what you want is for the document to be destroyed after first reading (Mission Impossible style). That's not how the web works. A file that can be accessed over the web can be easily downloaded and opened offline.
Certainly there are hacks around this, but they would be fairly involved to implement. I once created a Flash-based viewer that loaded another file that contained the actual document. Any tech-savvy user could still obtain the original document by examining the network traffic, but your average non-technical user wouldn't know how to do it.
You do have options for enabling restrictions in a PDF, but the user will always be able to save it and re-open it later. Probably what you want to do is implement restrictions on the document and load it in an iframe to prevent saving.
You can implement print/copy restrictions as follows:
$dompdf = new DOMPDF();
$dompdf->load_html($html);
$dompdf->render();
$dompdf->get_canvas()->get_cpdf()->setEncryption('', 'ownerpass', array());
$dompdf->stream();
The parameters of setEncryption are:
string, user password (restrictions apply)
string, owner password (unlocks document)
array, strings indicating allowed actions when user password is supplied (e.g. print, copy). If left blank the user is limited to saving the document.
A pdf is a document, it has no scripting instructions, maybe you want to embed it in an exe, have the exe extract it, and keep checking the lock bit, as soon as it is clear delete it.