Is it possible to generate a SharedAccessKey which expires after the first request rather than after a certain amount of time?
No, it's not possible. You would need some mechanism of your own to track the usage of shared access signature.
Related
Where does a JSON web token live? After doing jwt.sign and adding the payload / expiring date, what happens next, where is it stored ? I cant seem to find anything about it.
Thanks in advance.
JWT is not stored anywhere, its very existence contains everything. Its consisted of three parts, first one is hashing method, second one contains all the information you put there and the last one is signature so you can check if the token is valid or not (if you have secret).
This is actually the main reason JWT is so popular and used - as it can carry information through the multiple systems that can be verified by authorized systems.
In IBM-Graph, in order to avoid excessively long authorization for each request we request a session token first, and send that along in the headers of any subsequent requests. Exactly as explained in the documentation.
In order to persist this single token across our applications cluster, we are currently storing the active IBM-Graph session token in memcached. This way each node of our cluster pulls this token out prior to every request to our graph.
Having monitored this key, it appears to not have changed/expired since we made our first request a couple of days ago. Therefore, I have some questions regarding it:
How long do these session tokens last for?
Is our current method of distributing this single key even required?
Is there a better method?
It would be nice to be able to remove the need to hit memcached for every request altogether. Knowing how long they last for could help us to devise a more elegant solution than constantly hammering a single small memcached instance.
How long do these session tokens last for?
IBM Graph tokens are intended to last for a long while - you should expect somewhere around a day, though it's subject to change. It shouldn't ever be shorter than an hour.
Is our current method of distributing this single key even required?
No, not really. I'd write some code to automatically acquire new tokens on HTTP 403 (i.e., at boot time and when they expire) and use them locally. There's no limit to the number of tokens you can have active at one time.
I have an S3 bucket containing objects that I want to share with users of a website. I know I can use something like Query String Authentication to provide secure access to the objects, but what if I instead make each object publicly-readable yet "hidden" behind a complex key (i.e. URL) containing a cryptographically-strong random number? If the containing bucket disallows listing of objects, there wouldn't be a way to guess or discover the URLs, correct? Or is there some security hole I'm overlooking?
Side note: my first thought was to use UUIDs in the keys, but I read that they can apparently be predicted, given a few previous instances. That said, I don't have an understanding of how easily that can be done. If it's non-trivial, I probably wouldn't worry too much about using them instead of a strong random number...
The problem is if the once shared URL gets into the hands of another user (say via sharing). If you ensure the URL is kept sufficiently secret, it is ok with this approach (say you return the URL to a user via https, and this user dont share it).
Any loophole here will cause a security hole - and here is where the query string based signature scheme is helpful, since the signatures are made to expire after a fixed time and so any re-sharing wont also harm you.
You can use UUIDs (ensure they dont end up duplicating, by regenerating another one if the new one collides). They are probably as difficult (or more) to guess as any other 8-letter password.
The standard way to do what you want is to generate pre-signed URLs for each of the objects you want to share. If you make them with a short lifetime, then they cannot be shared outside that time period. All of the AWS-provided SDKs have support for this feature.
What is the best approach to fetching a certified time stamp from the internet from within my app?
I have a licence file that expires at a regular period and I must make sure that the certificate is not expired.
Is such a thing even possible/ does it exist? Ideally when my app runs, it should get a secured/certified time stamp representing current time, but I want to make sure it cannot be faked by the application runner.
Are there any services that offer this out there? It can be commercial, I just don't know where to start and am looking for some pointers.
Look at Timestamping protocol (RFC 3161). It gives you secure time. To properly use the protocol you can ask the server timestamp some random hash (the server doesn't care), then validate the timestamp and if it's ok, use the time in the timestamp. That would be the most effective approach.
There was a TSP client available in BouncyCastle, if memory serves, and our SecureBlackbox product (including free CryptoBlackbox package) also includes a TSP client and powerful validation mechanisms.
This question may seem a bit odd, but is it possible, with a poor-mans solution in VCL, to parse a signed request (with a shared secret key, aka poor-mans solution of HMAC), created by the referrer (main) site, and only serve the content from varnish if the signature is correct and the (signed) timestamp hasn't expired?
That is, similar to how Amazon S3 is works, where you can easily create a signed temporary URL to your S3-object that will expire in a defined amount seconds.
Note: I'm not talking about cache object expiry here, but URL-expiration for the client.
It gets handy when you only want to give out temporary URL's to your users to prevent long-term hotlinking without checking the referrer-header.
So - A poor-mans-solution to temporary URL's in VCL (preferrably in the vcl_recv ) making the internal object expire). Is it possible without making a VMOD?
Edit:
I found another way of authorizing content with Varnish:
http://monolight.cc/2011/04/content-authorization-with-varnish/
But it's still not what I want to achieve.
Best regards!
Yes, this is possible.
In essence you need to verify the signature (digest vmod), pick out the timestamp from whatever header it is in (regsub), and compare it to the current time.
Use std.integer() to cast the timestamp:
https://www.varnish-cache.org/docs/trunk/reference/vmod_std.html#integer
use the built in now variable in VCL to find the current timestamp. You might want to do (now + 0s) to force Varnish to give you a unix timestamp.
https://www.varnish-cache.org/docs/trunk/reference/vcl.html#variables
The digest vmod is on github:
https://github.com/varnish/libvmod-digest
There is already a VMOD for this, if that helps?
Varnish Secure Download Module