Is it unwise to do this? The thing I'm talking about is username and password being passed to a processing file, like this:
echo'<script>location.href="process.php?u='.$_POST['username'].'&p='.md5($_POST['password']).'"</script>';
This is after the username and password has been validated. Could this somehow be intercepted maliciously? Or is this a safe enough thing to do?
That is a very bad thing to do. All user data should be stored in $_SESSION, or, you should set a validation cookie and use that for authentication.
Additionally, you should never "keep" the user's password. You should hash it and store the hash in the database, then check the posted password against the hash on login.
Additionally, your hash should be one way, and you shouldn't be able to retrieve or view the user's original password.
Finally, MD5 is horribly defeated. It is no longer remotely secure, and can be demolished by a rainbow table attack. You should look into something much stronger and slower (slow is good) such as bcrypt.
DO NOT DO THIS
There, now that we've cleared that up, allow me to explain...
What you're essentially doing is sending this data to the user in the clear. Even if you're using SSL encryption for the transport, it's still a big risk. It's not "rendering in the browser" but that doesn't matter. It's still being sent to the browser. And even if in this particular case you don't run into any issues, it's a bad habit to build.
You might even ask, "But I'm using md5() so the password is obscured, right?"
Wrong.
The text is obscured, yes. But you're delivering the obscured version of the text to the client and then keying off of that text. Which means you're still displaying an effective password for all to see.
If the password is "correcthorsebatterystaple" then you don't want to display it in plain text because that would give somebody the password, right? (In fact, you don't even want to store it in plain text. Anywhere. You, as the site admin, don't even want to know or have any way to find out the text of the password. If you can, someone else can.) Right.
So, instead, you obscure the password as "elughwelfguweliurgnswfglwerlgu" which your code interprets as the password. So you can display that, right? Wrong. Because now, by accepting "elughwelfguweliurgnswfglwerlgu" as the password from the client, you've made "elughwelfguweliurgnswfglwerlgu" into the plain text password that your system accepts. So the obscuring of the text does nothing.
In short, never ever deliver a password to anybody in any form. Your application should receive passwords as input, but never produce them as output in any way.
NO NO NO
When a person enters a password to set up an account (or change password) use POST and SSL.
Otherwise the password is a one way street without either MD5 or plain text in the URL.
When a user logs in give them a session. This can expire and therefore become invalid.
As to be intercepted - You can just get a packet sniffer
Could this somehow be intercepted maliciously?
Yes. Anyone can look at the source of your page and see the username and the md5 hash of the password. It will also show up in the URL of the browser when the page redirects for the user.
Could it be intercepted via a man-in-the-middle attack? Not necessarily. If you are using HTTPS, the query string will be encrypted in the SSL packet along with the rest of the request. If you're not using HTTPS, anyone will be able to see the query string which, so you know, makes GET just as secure as POST when looking at man-in-the-middle attacks.
Here's a good comparison of how GET can be less secure in HTTPS environment: Is an HTTPS query string secure?
