It just occured to me that I didn't really say why it could be bad to be passing around username/passwords to logs:

1) Someone sniffing a user's connections could obtain a valid username/password pair (true they could obtain the SID as well, but if you have implemented timeouts, they would have a small window to take advantage of the info).

2) Logs. The username/password would show up in your logs, probably the person's ISP's logs, any proxy servers that they pass through, and if they quote URL's from the site, maybe even in your users own posts (once again this could be a problem with sids too, but the same argument as above applies).

So now for example, instead of passing around URL's like: http://www.mysite.com/index?login=tr...word=password, after logging in, they pass around urls like http://www.mysite.com/index?sid=aabcde34234fbadecaf. Note, it generally is a bad idea to be so blunt as to call it a sid , although I have noticed AO does this...

By hijaacking a browsing sessions, what I was referencing was as follows. Say you have a web page, after you log in, it issues a sid that is say a sequential number (or even more secure a hash of say the username and the time using say base64 encoding, but still not secure enough) . So you wind up with a url of http://wwww.mysite.com/index?sid=1. I am hoping it is pretty clear why that is bad, there is nothing stopping someone else from coming along, putting that sid in there and having the same permissions (and really becoming same person) as your signed on user. So, if the sid is easily guessed, you can essentially take over the person's session fairly simply, which is probably what you were reading was warning you.

The writers of Hacking Exposed have put out another add-on book titled : Hacking Exposed : Web Applications in which they cover this very very extensively. I highly recommend taking a peek through the book, this topic and several others are covered.

/nebulus
'
EDIT: Just realized I didn't even touch variable poisoning. Variable poisoning could be an issue like you said only if there are no other checks/sanity checks on the variables and can be an issue not only for authentication, but for things such as variables in forms. You'd be suprised how many things are not sanity checked. Using a program such as curl or curlssl, you can inject whatever values you want, so for example, say you had a form for the quanity and price of an item:

<form action=somescript.php method=POST>
Price: <input type=hidden value=9.99 name=price1>
Quantity: <input type=text value=0 name=quantity>
<input type=submit name=submit>
</form>

You could essentially use curl to change the value of the hidden variable and do something like:

somescript.php?price1=0.09&quantity=20&submit=1

You now have a substantial discount...same bad things could happen with improperly secured login variables...