.htaccess .php proxy

[Publisher Bucks]

Is there any reason that I shouldnt put this in a .php script to allow a client to download a digital file they have purchased?

define('PROTECTED_USERNAME', 'username');
define('PROTECTED_PASSWORD', 'password');

This is to let a client download a file in a .htpasswd protected directory.

The download link is already limited to 30 minutes and before the links are given they have to enter a transaction id and their first and last name.

Any security issue is what I'm mainly concerned about.

Thanks.

[cerulean]

Originally Posted by Publisher Bucks

Is there any reason that I shouldnt put this in a .php script to allow a client to download a digital file they have purchased?

define('PROTECTED_USERNAME', 'username');
define('PROTECTED_PASSWORD', 'password');

This is to let a client download a file in a .htpasswd protected directory.

The download link is already limited to 30 minutes and before the links are given they have to enter a transaction id and their first and last name.

Any security issue is what I'm mainly concerned about.

Thanks.

It all comes down to how important the information you're protecting is. When I do development versions of software, I hide them behind HTTP basic authentication, because it's a minor problem if the information gets leaked. It's already going to go live soon anyway.

If you are fine with the security issues related to HTTP basic authentication, like issues related to brute forcing, password sharing, and the like, then there is no problem rolling a PHP variant.

I will always caution against storing passwords in plaintext. If someone does gain access this file or the information related to it, that information would be compromised. This is why the standard is to one-way salt and hash a password using an algorithm, like bcrypt.

I wouldn't consider the other metadata you're collecting to be secure, but again, it depends on how important the protected information is.

If you decide to do HTTP basic authentication, I would recommend just implementing actual standard http basic authentication through the htpasswd command and use the bcrypt flag:

https://httpd.apache.org/docs/2.4/howto/auth.html

https://httpd.apache.org/docs/trunk/.../htpasswd.html

You can even access that data in PHP:

https://www.php.net/manual/en/features.http-auth.php

Nginx has an equivalent.

As an aside, if you have a database of users and passwords, you may be better off with an actual login manager, but that might be a level above what you're trying to do.

[Publisher Bucks]

Well right now the customer data is stored in SQL (hashed with SHA1) and the script just grabs their transaction ID, email address and associates that with another table that contains the product(s) they purchased.

In order to download them, the transaction ID and email address (plus their name) has to all match a form submission which then redirects the customer to a 'download' page with their individual files.

The problem is, the files that they're purchasing have been stored on a domain (behind .htpsswd protection) that is over 10 years old, that, was honestly never even considered might be needed for this purpose, there's nothing on that domain except about 12,000 individual files, all with a unique ID.

I figured if i used a proxy to store a new username and password in the .htpsswd file, (there is no directory browsing possible) that would resolve my having to dynamically create an actual username and password for each customer when a purchase is made.

Am I overthinking things or would this be fine? There isn't really anything of 'value' per se in the protected directory that if it gets lost somehow I wouldn't be able to re-upload from a physical HD.

I'll be honest, coding out an actual user login system isn't something I feel like doing on a weekend, at least not until I have the user account creation stuff setup

[cerulean]

Originally Posted by Publisher Bucks

Well right now the customer data is stored in SQL (hashed with SHA1) and the script just grabs their transaction ID, email address and associates that with another table that contains the product(s) they purchased.

In order to download them, the transaction ID and email address (plus their name) has to all match a form submission which then redirects the customer to a 'download' page with their individual files.

The problem is, the files that they're purchasing have been stored on a domain (behind .htpsswd protection) that is over 10 years old, that, was honestly never even considered might be needed for this purpose, there's nothing on that domain except about 12,000 individual files, all with a unique ID.

I figured if i used a proxy to store a new username and password in the .htpsswd file, (there is no directory browsing possible) that would resolve my having to dynamically create an actual username and password for each customer when a purchase is made.

Am I overthinking things or would this be fine? There isn't really anything of 'value' per se in the protected directory that if it gets lost somehow I wouldn't be able to re-upload from a physical HD.

I'll be honest, coding out an actual user login system isn't something I feel like doing on a weekend, at least not until I have the user account creation stuff setup

I understand what you're trying to do. I think it's healthy to overthink security and protection when user information is involved, and when money is involved. Both of these things are true for you.

Is there a reason you can't just send an email link on purchase with a unique code that downloads the correct file on a timer (as you've described?) You wouldn't need a username or password, as long as the file uses X-Accel-Redirect or X-Sendfile to load the file behind a proxy to obfuscate the process of passing the file to the user.

We're at a point in software development where everyone already has a service or an offering. Sometimes it's more financially beneficial to just purchase a pre-existing solution than it is to code through the weekend something from scratch. I am sure there are already systems that do what you want, and the costs would likely be minimal if it saved you time.

[ladida]

Originally Posted by Publisher Bucks

Any security issue is what I'm mainly concerned about.

Just the thought of you using htpasswd makes you at least 10 years behind on technology.

[cerulean]

Originally Posted by ladida

Just the thought of you using htpasswd makes you at least 10 years behind on technology.

I would roughly estimate that the great majority of adult sites still employ HTTP basic authentication in some form, likely with authn_dbd and probably mod_auth_form. When marketing LoginBlue, I looked at hundreds of paysites and the kinds of forms they use.

Being behind on technology is not necessarily a bad thing. Sometimes the right tool for the right job isn't new. But you are correct in thinking that this is a deprecated concept to employ these days, when there are many better alternatives.