Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

Scenario

I have a web server that authenticates and redirects from HTTP to HTTPS. Clients can then view available "downloads" in their account. I want to be able to sign these download links - as in, I want the link to only be used by the authenticated user, only once, and I want to be able to recover information about when a specific "token" was used...

Question

What is this actually called? I can't seem to find anything about it, and I'm sure I've seen it before. I just need to find out what it's called or what a resource is regarding it so I can read about it and implement it.

As a bonus question: does anyone know offhand how to implement public key authenticated database connections in PHP (like mysql_connect(); or whatever, but when the database is on the local network instead of the same machine, and you don't want the connection sniffable)

share|improve this question
    
Just wanted to note that the connect method in the SqlSrv (microsoft SQL) API supports setting "Encrypt" to true, which then uses the operating environment's configured cryptographic primitives (so FIPS 140-2 compliant if that is configured). Also you can choose to not trust self-signed certificates when connecting to the database as another member of the same associative array argument that serves as part of the input 2-tuple for the connect method –  Andrew Feb 27 '13 at 16:37

2 Answers 2

up vote 4 down vote accepted

I don't know about the terminology, but restricting access to a download link is simple. For example, (assuming a LAMP environment), you could generate a download hash(token) for each user-download page pair. Now, on the download page, check if the logged in user (extracted from $_SESSION) has access to the given page (using MySQL), and check the hash (from $_GET). You let the user download the page(Using header('Content-disposition: attachment') followed by readfile($filename);), and then revoke access to the given token by removing it from the database.

However, since you are redirecting from HTTP to HTTPS, the session will change. In this case, you can propagate the session by passing the id via GET/POST using the technique described here.

Though having an HTTP login for an HTTPS page is rather bad practice: the password/etc can still be sniffed by the middleman.

share|improve this answer
    
Sorry I should have rephrased that - the HTTP page that loads initially (something.com) immediately redirects to "something.com/"; before user authentication –  Andrew Feb 27 '13 at 16:35

There are two ways to restrict access to a piece of data: with procedures, and with mathematics.

Procedures: this requires that your server somehow knows who is connected. You'll need user authentication of some sort (e.g. login+password). Running the whole thing in a SSL session is a good start. Once you know who is connected, it is quite straightforward for a server to grant or deny access to any specific download link, and record any access.

Things become (much) more complex if you not only want to know that a user downloaded a file, but also want to be able to prove it (e.g. to a judge during subsequent legal dispute).

Mathematics: cryptography can concentrate the problem of access data into the problem of knowing keys. You can encrypt each file with its own random key, and leave the files as a free-for-all download. But, of course, the file data remains hidden to whoever does not have the file key. Since a file key is nothing more than a sequence of 16 random bytes or so, distribution of file keys can be down in many ways, including "physical methods" like scratchcards. In this kind of setup, you don't have to restrict access to the files or even use HTTPS; a user will be presumed to have been able to download the file as soon as he obtained the key.

Important note: you cannot prevent a user who has downloaded the file once from keeping a copy of it, or distributing it to whoever he wants. Multimedia content distributors would just love to be able to enforce such a restriction, but it is not possible while the user's computer is still his computer.

share|improve this answer
    
Yea I established TLS w/ a self-signed certificate and wrote the PHP scripts for a sanitized SQL-database based login using salted hashes. I was concerned about how to create another authentication vector (something the user has) in the form of a token and relate it to a specific download. –  Andrew Feb 27 '13 at 16:34
    
Also I should have explicitly stated that I was operating within the bounds of the HIPAA act - so I can't use encrypted public downloads as encrypted health information is probably still considered health information (I don't know for sure, kinda curious now), and distributing it would probably violate HIPAA –  Andrew Feb 27 '13 at 16:41

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.