PHP: Write/update webpage to server

[gumOnShoe]

Hey, just wondering who has experience with doing this sort of thing and what method you would use to do it. As a basic example, a user (lets call him FooMaster) signs up to your web page. You have a directory called "users" on your webserver, and in there you want to create a folder called FooMaster with index.php located at that link. And then you have a template and you'll just update it based on the information FooMaster gives you.

I'm assuming this is possible. How else would you make web pages on the fly?

Thanks much for the direction.

[NinoGrounds]

Avoid this style. Soon you'll have a ton of files and folders. Hard to maintain. Store users' data in a single file or db. I prefer databases, for a ton of reasons. And then you simply create a template.php file, where the template code is, and then you just fetch users' data into it. Thus, you are creating pages "on the fly".

[gumOnShoe]

At 10/2/11 01:35 PM, NinoGrounds wrote: Avoid this style. Soon you'll have a ton of files and folders. Hard to maintain. Store users' data in a single file or db. I prefer databases, for a ton of reasons. And then you simply create a template.php file, where the template code is, and then you just fetch users' data into it. Thus, you are creating pages "on the fly".

Mmmk, I'll look into doing it this way instead. I'm a little worried about every user ever needing to compile a complete PHP page when they load their user page or someone else does, but I see what you are getting at. Hard disk space for me is infinite, but I pay for ram.

[SupJD]

Basically the best way to create dynamic content is like the following.

Have a register page with a simple form asking for username, email, password and whatever else you want to know, keep this relatively small to make the process quick for them to sign up (you can always get them to add more later once they're registered).

When you process this form with PHP you get it to store that data into a MySQL database under a table called `users` for example. The fields you have in that table would be as follows:

id - This needs to be a primary key and set to auto increment, this will give each user an unique/individual id. Which is how you'll fetch their information later.

username, email, password (make sure its encrypted), ip address (for future reference such as banning etc), timestamp (a unix timestamp, making sure you set it to UTC) and whatever else you asked from them. Make sure all data that is processed is validated (not just with Javascript but with your PHP too). Look up MySQL/database injection on Google to understand why.

Then on your profile.php page, you have a set template, but the ID query string in the url determines what profile is fetched from the database. so your URL could be "www.yoursite.com/user/profile.php?id=8"

What you can then do is use $_GET to fetch that ID number and attached it to a variable (also check its numerical, again, mysql injection), and run a query in your database such as

$query = mysql_query("SELECT * FROM `users` WHERE (`id` = '$id')") or die(mysql_error());

This then places whatever ID number in the query string into the WHERE clause. Then proceed to fetch which ever bits of information you want from that row in the database, so for example:

echo("This is ".$name."'s profile");

Of course, depending on whatever ID is in the query string, you'll be able to view each users info. It's the easiest, most commonly used way for creating this. And if none of this makes any sense then I suggest reading up a bit more on PHP/MySQL on tizag or somewhere similar :)

[polym]

Have none of you heard of Kohana?

It does basically the same fucking thing. It has a heirarchy of folders with files in them that does exactly what he asks (without using databases).

[citricsquid]

At 10/2/11 03:16 PM, childlover wrote: I hope you know that makes absolutely no sense. Do you even know what RAM is?

it's the fuuuuuutttttturrrrrrrrreeeeeeee maaaaaaaan:

http://dreamhost.com/servers/vps/

It works exactly as he stated, he pays his host based on RAM allocation and they provide him no limits on the disk space he uses.

[SupJD]

But why would you want each user to have their own page with the same code on it? It's just overly messy, I can understand the folder thing to store their uploaded images or files etc but surely it just makes more sense to use a template for displaying a page.

The majority of sites use it, take NG for example, they don't have individual pages for each and every upload in the portal etc. It's a template and the data is fetched depending on the ID.

[citricsquid]

At 10/2/11 03:22 PM, polym wrote: Have none of you heard of Kohana?

It does basically the same fucking thing. It has a heirarchy of folders with files in them that does exactly what he asks (without using databases).

you're confused. Kohana is an MVC framework, the file/folder structure it uses is not relevant to the OPs problem. gumOnShoe is talking about having profile pages for every user and his idea was to create a folder for each user based on a "template" folder.

o.0

[kaiser-d]

If you expect a small user base, you can write user account details as xml nodes. If you expect a larger user base, create an SQL database and use php to write user data to that. Do not use XML to store user passwords or sensitive information.

[gumOnShoe]

Thanks for all the tips anyone, and I see you remember what I'm using Sam. I've got to say, its not always the best service though. Their method for stopping you from going over your ram limit is to kill a process. But I'm not sure that they are killing things intelligently, which sometimes leads to site outages. But yes, I know what RAM is. I'm guessing that comment was deleted.

At 10/2/11 08:59 PM, kaiser-d wrote: If you expect a small user base, you can write user account details as xml nodes. If you expect a larger user base, create an SQL database and use php to write user data to that. Do not use XML to store user passwords or sensitive information.

I'm staying away from XML. I have a personal hatred for the stuff. Yeah, I know HTML is a subset, but its a pet peeve of mine regardless. And I've already got a database that I'm storing stuff in, including users. I just hadn't done anything with the information being saved yet and was wondering on the best way forward. Everyone seems pretty much in agreement that PHP is better than individual pages based on a template? That's probably the easiest way to do it anyway...

Anyway, brownies just finished baking. MMM brownies.

[NinoGrounds]

At 10/2/11 03:19 PM, SupJD wrote: username, email, password (make sure its encrypted)

You guys encrypt usernames and emails too? I mean it makes sense for emails, but for usernames too? I never really encrypted usernames and emails. You're using md5 right ?

[SupJD]

At 10/2/11 10:42 PM, NinoGrounds wrote:

At 10/2/11 03:19 PM, SupJD wrote: username, email, password (make sure its encrypted)

You guys encrypt usernames and emails too? I mean it makes sense for emails, but for usernames too? I never really encrypted usernames and emails. You're using md5 right ?

I don't encrypt usernames and I don't usually encrypt emails either, depends on the project... I put brackets round that just meaning for passwords more than anything.

And I personally advise no longer using the md5 hash, you want to use SHA-2.

[gumOnShoe]

At 10/2/11 11:01 PM, SupJD wrote:

At 10/2/11 10:42 PM, NinoGrounds wrote:

At 10/2/11 03:19 PM, SupJD wrote: username, email, password (make sure its encrypted)

You guys encrypt usernames and emails too? I mean it makes sense for emails, but for usernames too? I never really encrypted usernames and emails. You're using md5 right ?

I don't encrypt usernames and I don't usually encrypt emails either, depends on the project... I put brackets round that just meaning for passwords more than anything.

And I personally advise no longer using the md5 hash, you want to use SHA-2.

md5 & SHA-2 aren't strictly speaking encription. They are 1 way hashing algorithms. There is no way to get back the actual password which is really the point. That said, if a user suffers from a man in the middle attack, it doesn't much matter which hashing algorithm you use. The offending party can simply send the hash on instead of the password. Without an actual encryption (private key/public key system) you can't build a completely safe to use system where you are literally covering everything you can as a web designer.

[NinoGrounds]

At 10/4/11 07:59 PM, gumOnShoe wrote: wizdom

So by you, using https to protect data while in carriage and using crypt() with salt isn't enough? Or were you referring to the public/private keys of HTTPS ?

[gumOnShoe]

At 10/4/11 08:04 PM, NinoGrounds wrote:

At 10/4/11 07:59 PM, gumOnShoe wrote: wizdom

So by you, using https to protect data while in carriage and using crypt() with salt isn't enough? Or were you referring to the public/private keys of HTTPS ?

public/private keys is the way https works. Basically, you need to have a secure connection using very long secret passwords to guarantee anything. Salt is fine. I wouldn't swear by it. It definately keeps users from using a dictionary attack against your hash algorthm; unless they can find out the salt, but you are hopefully salting server side anyways, otherwise everyone can see the salt, But to salt server side, you have to pass the password over the net, and to do that safely, unencrypted, you need to have a secure https connection.

[NinoGrounds]

At 10/4/11 08:29 PM, gumOnShoe wrote: public/private keys is the way https works. Basically, you need to have a secure connection using very long secret passwords to guarantee anything. Salt is fine. I wouldn't swear by it. It definately keeps users from using a dictionary attack against your hash algorthm; unless they can find out the salt, but you are hopefully salting server side anyways, otherwise everyone can see the salt, But to salt server side, you have to pass the password over the net, and to do that safely, unencrypted, you need to have a secure https connection.

You might have errors here. You mean, the attacker can see the password when the user signs up before it reaches to the server. So he sees a real, raw, unecrypted password. Right? Because I don't think it's possible for attacker to see it when it reaches the server, and when it gets encrypted.
I am creating a random salt server side every time a user signs up.

I also have a question, since I've never been using HTTPS, but I am strongly considering it now. If I decide to use HTTPS, should I also force using SSL when exchanging data with database?

[NinoGrounds]

At 10/4/11 08:29 PM, gumOnShoe wrote: you have to pass the password over the net, and to do that safely, unencrypted, you need to have a secure https connection.

I'm sorry, you had no errors, I misunderstood what you wrote.

[gumOnShoe]

At 10/5/11 01:19 AM, NinoGrounds wrote: You might have errors here. You mean, the attacker can see the password when the user signs up before it reaches to the server. So he sees a real, raw, unecrypted password. Right? Because I don't think it's possible for attacker to see it when it reaches the server, and when it gets encrypted.
I am creating a random salt server side every time a user signs up.

I also have a question, since I've never been using HTTPS, but I am strongly considering it now. If I decide to use HTTPS, should I also force using SSL when exchanging data with database?

In an ideal world yes. However, SSL means decripting data, which means there's additional processing time that needs to happen on your server and on their computer. This will on some level slow down your site and hit performance (unless you have a very robust server).

However, it would depend on what you are actually doing. You'll notice that Newgrounds doesn't use https for its password system. I'm not even sure that they do it for their store. The question you have to ask yourself is: Are users doing something on my site that absolutely needs protection. If users are using social security numbers, or other identity information on your site regularly, I'd agree you probably need to do something more than what you are. I'm not sure https is required for a simple user system.

In the end, how much of your time and money is it worth to fight an eventual losing battle? Man in the middle and all of that is a scary attack you can sort of protect against, but if your customers download a key logger it doesn't matter what you do.

[gumOnShoe]

Actually the store was a better example than I realized. Newgrounds doesn't generally use https:\\ but they do for their store. There you go a perfect example of when to use it. Don't worry about it so much with passwords. Worry about it with credit card numbers and contact info.

[SupJD]

At 10/4/11 07:59 PM, gumOnShoe wrote: md5 & SHA-2 aren't strictly speaking encription. They are 1 way hashing algorithms. There is no way to get back the actual password which is really the point.

Yeah, sorry I used the wrong terminology :P

I was under the impression you could use brute force to reverse the process of hashing though? An automated system which can crack it in a pretty reasonable time scale. The same is still possible with SHA but it just takes more time and more processing power. I'm not entirely 100% sure on all this though, it's just from little bits I've read now and then.

[gumOnShoe]

At 10/5/11 11:59 AM, SupJD wrote:

At 10/4/11 07:59 PM, gumOnShoe wrote: md5 & SHA-2 aren't strictly speaking encription. They are 1 way hashing algorithms. There is no way to get back the actual password which is really the point.

Yeah, sorry I used the wrong terminology :P

I was under the impression you could use brute force to reverse the process of hashing though? An automated system which can crack it in a pretty reasonable time scale. The same is still possible with SHA but it just takes more time and more processing power. I'm not entirely 100% sure on all this though, it's just from little bits I've read now and then.

Technically you can't use bruteforce to undo a hash. A hash algorithm is like the remainder in devision. You can always get the remainders that look similar from different options. That said, there's a discrete set of possible inputs to give you a resulting hash. So, it is possible to bruteforce a password scheme, and it is possible to build a dictionary of hash values based on real words (which is why people talk about salts), but it isn't possible to reverse the math of the hash algorithm itself. The bruteforce literally is the same as a bruteforce attack on "what word am I thinking of?" with a few more algorithmic steps.

[NinoGrounds]

At 10/5/11 07:36 PM, gumOnShoe wrote: The bruteforce literally is the same as a bruteforce attack on "what word am I thinking of?" with a few more algorithmic steps.

You are a very wise man

[AhrimanZora]

I'm sorry to do this without having enough rep, but here it goes. You guys are mostly incorrect regarding crypto, but that's normal.
There are 3 main kinds of crypto used in computers today:
Asymmetric key, AKA Public/Private key: The pub/priv key is a subset of the Asymmetric key, so I prefer the more generalized term. The most common usage is SSL, to accomplish 2 things. #1 Prove the server is who it claims to be #2 exchange a symmetric key for later encryption. Typical ciphers are Diffie-Hellman and RSA.
Symmetric key: this means you have the same private info in both places, and use that private info to both encrypt and decrypt the data. This is done in SSL, after the Symmetric Key is exchanged. Typical ciphers are 3DES and AES.
Hashing: This is a "one way conversion" and basically is used to say "this data hasn't changed." Hashing is used in passwords, with a SALT. Hashing is used to sign documents in conjunction with a Private Key. Typical ciphers are MD5 (128 bits) and SHA-1 (using 160 bits) or SHA-256 (using 256 bits). MD5 has been cracked to the point that evil binaries or false documents of the same type can be generated in a matter of hours or days. 8 character passwords using MD5 can be cracked in a matter of days. The same password in SHA1 could probably be cracked in a matter of weeks, but the crypto cracking routines haven't been released as widely or as well for SHA1. The Chinese government has sponsored a lot of SHA cracking efforts, but only a small number of these are assumed to be published. I would like to see more routines that use SHA256 AND MD5 together, because the inadequacies of one algorithm are covered by the other.

YOU CAN brute force a hash. Look up CUDA and Rainbow Tables. SSL has also been cracked a vast number of ways. Unless you register your browser with a personal key, and the web server expects your personal key when you submit data, don't expect SSL to do anything more than slow down a skilled attacker. Now they have to compromise one additional machine before they can start trading your stocks.

Regarding secure password submission: The POST contains the raw password, not the MD5/SHA256 version. A large number of pieces of software can automatically detect that. SSL is required to provide any hiding of the password in transmission at all. If the entire SSL conversation is in plain view, then don't count on it too much. If a Man in the Middle attack is possible (and one always is with SSL unless you register your browser key on the server) then this is simply a minor impediment. The REASON to do MD5/SHA256/SALT on the server in the database for passwords is so that when the server gets hacked, users won't be able to see each other's passwords without brute forcing the hashes.