I am developing a C# .net 3.5 application.
I am trying to verify a file signature by using WinVerifyTrust.
I also want a revocation check so I set the following parametrs of the WinTrustData.
FdwRevocationChecks = WTD_REVOKE_WHOLECHAIN;
DwProvFlags = WTD_REVOCATION_CHECK_CHAIN;
everyting works OK except when I move the system time forward, then the method is stuck and winVerifyTrust return an answer only after a very long while.
Do you have any idea why it is happening and how can I prevent it?
Thanks
This might be happening since revocation information, whether CRL or OCSP has a thisUpdate field which tells when the revocation information becomes valid. The OS might have downloaded the revocation information and has to block till the time it becomes valid for use.
Related
ClientSide Sending Key Example: tabc-xkaf-gaga-gtax to the Server
Server Checks if Key Exists in Database if YES then return TRUE as Response
ClientSide IF RESPONSE = TRUE THEN
OPEN FORM1
But thats not a Secure way to do it cause they can change the Response of the ServerSide check and then get the Product for free cause it will open Form1 anyone has a better way to do it?
Signed server side response and verify server response at client side to check whether response was altered or not.
Refer this article for how to digitally signed and verify
Moreover this will be a typical solution and suit for very complex security .
For simple solution, You can send hash of response along with server response and convert response to hash at client side. compare both hash , if they match it means response was not changed.
As you indicated, professional attackers can see and decode VB.Net applications, and hence, as an initial conclusion, you cannot reliably protect your code. In the first step, you must encrypt your code by using several encryption techniques such as the one mentioned by #Always_a_learner. However, this will not 100% protect your code from reverse-engineering (A good discussion could be found here).
A good trick in such cases is to make some intentional dependencies. For example, some core calculations should be done by the server (if possible) and only the result should be returned to the client. More explanation, for core calculations, the client should send a request to the server, and the server first verifies the requester (the sender) validity state, and if she is a valid user, then runs calculations and returns results to the user.
This solution is fine only if you can trade-off between speed and security.
I could not find in the docs the canonical way to check whether given credentials can be used to clone given repository. There is an issue that suggests that one way may be to check whether git_cred_acquire_cb() is called more than once. Can somebody confirm this or point out another way?
This is the suggested way. If your credential callback is called a second time, then the first credentials that you provided were not accepted. This pattern is primarily useful for UI applications (popping up a modal username/password dialog).
You can use the callback data to count the number of times you were called.
I realize that this may be imperfect, especially if you're binding libgit2 in another language. Setting up a data struct on the heap and managing its lifecycle is not always trivial.
You may also be able to just provide credentials and wait for a GIT_EAUTH return code. In theory, the various transport mechanisms should give up after several authentication failures no matter what. However, we found at least one bug in the 0.27 releases that would loop forever. Hence the suggestion.
I currently need to parse the CommonName from a packet. I have code that works up to a point, however am having trouble skipping over the "issuer" member of a Certificate record for TLSv1.2. I have done research on the format of the SSL records and have investigated the dump via wireshark. I've found the format is generally - Length, followed by the data. However when trying to find the issue length, I cannot seem to get it, and is inconsistent with the bytes presented. Any ideas..or a better way to skip over the issuer field, and go directly to the "subject" of an TLS 1.2 record. Coded in C..Thank you for useful responses.
You need to understand ASN.1. Go read this book (it is a free download). Once you have read and understood it, you can write your decoder, following the ASN.1 specification for certificates. This is doable, but requires great implementation care. In fact, this is a bad idea unless you are a demi-god of C programming.
Alternatively, use some library that already knows how to decode a certificate. Typically, OpenSSL.
I'm making an API call from one app to another. I handle authorization by passing an md5ed shared secret + timestamp...
$token = md5( $secret . time() );
Then at the API endpoint, I check the authenticity of the request like this...
if ( md5($shared_secret . time() ) == $token )
...do stuff
This works. But it isn't as reliable as I'd like. I suspect the reason is due to latency in the network (or my slow localhost server) causing the timestamps to be mismatched by a second or so.
I worked around this in a lazy way by dropping the last digit of the timestamp, thus creating up to a 10 second window for my slowpoke server to make the call. However, I'm not satisfied with this because if the call happens to fall at the very end of the 9th second, I'll have the same problem again (send at #######49 != received at ########50).
There must be a better way to do this. What is it?
Consider using token = time || MAC(time, shared_secret) where || is concatenation and MAC is a Message Authentication Algorithm such as HMAC, that takes a secret key and some data and produces an authentication tag. On the server end, check the MAC is valid and the time (received in plaintext) is within an acceptable window.
This is more secure than your current solution (md5 makes a poor MAC) and also solves your window problem.
Note that this scheme is susceptible to replay attacks within the error window that you allow (e.g. the same token could be sent ten times in a one second window, and the server has no way of telling).
Use a nonce instead? Save the nonce to a DB or some persistent storage to make sure the same one isn't used.
Conversely to your '9th second problem' you have a similar problem for seconds ###...0 to ###...9 hashing to the same value when you cut off the trailing 0 through 9. It would allow replay in that 10 second time frame.
Seems like that would be more of a problem for guaranteeing/checking authenticity.
You'd have to send the plaintext and hashed text together for the server to check it but that seems a little better than the time stamp method.
Either way, with those two parameters alone you're only checking that it's not a duplicate request as opposed to authenticating anything.
Using a timestamp is not the correct way because the time is not reliable across systems. Perhaps you can use the length/hash of the message as a parameter instead. It does not, unfortunately, prevent playback from an attacker.
Correct me if I'm wrong, but it seems as though you're dealing with authentication (ie, the sender is who they say they are) rather than authorization. I would suggest that you use SSL/TLS to secure the transmission to know whether or not the transmission is being proxied.
This question already has answers here:
How to obtain codesigned application certificate info
(2 answers)
Closed 8 years ago.
I have app signed. I created an identity and used codesign to sign my app as per Apple's Code Signing Guide.
Now, how do I check the signature from within my application?
I need to verify this on Cocoa apps (Objective-C) and apps written in C.
You could use NSTask and run "codesign --verify" and check the exit status. Of corse if the program was altered it could be altered to remove the check, so I'm not sure what that buys you.
If you are not worried about directed tampering (like the kind that might remove your check of the signature) you can use the codesign "kill" option, if you do merely executing means the signature is valid (at least for all pages that have been executed so far...but if a not-yet-resident page has been tampered with you will get killed when that one is read in anyway).
Maybe if you could explain a little more about why you want to verify the signature a better answer could be formed.
Note: Currently MacOS X does not verify signed code prior to execution. This may be different for sandboxed code, and it would seem sensible that it is otherwise anybody could edit the entitlements.
To check an applications signature from within the application itself you use the Code Signing Services. In particular look at SecCodeCheckValidity. The code to do the checking is not long, but there is quite a bit to understand so I won't give a code sample - you need to read and understand the documentation.
Checking the signature allows your application to detect changes to its code & resources and report it is "damaged" (it may well be, not all changes are malicious) and refuse to run. Adding such code does not of course guarantee your code is not damaged, but certainly it does raise the barrier higher against intentional damage (and if MacOS X starts doing the check itself then there will be a big win).
The way signiture verification is implemented on iOS is that when an application is being launched, the launchd daemon decrypts the binary using that device's specific private key (this is why you can't just decompile apps or copy-paste them from one device to another), if the decryption fails, the application fails to launch.
The native tools that do this are not available within applications due to the iOS sandboxing.
If you're simply attempting to track if someone has modified your binary, you can perform an MD5 or SHA1 hash of it, store it in NSUserDefaults and compare it at each app start. If the hash changes between executions you know it has been modified (possibly by a legitimate application update or possibly nefariously.)
Here's an example on how to get the hash of an NSData.
The binary file you're looking for is: AppName.app/AppName