You have no greater security provided because the variables are sent over HTTP POST than you have with variables sent over HTTP GET.
<form action="http://example.com" method="get">
User: <input type="text" name="username" /><br/>
Password: <input type="password" name="password" /><br/>
<input type="hidden" name="extra" value="lolcatz" />
GET /?username=swordfish&password=hunter2&extra=lolcatz HTTP/1.1
Accept: application/xml,application/xhtml+xml,text/html;q=0.9,text/ [...truncated]
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US) [...truncated]
POST / HTTP/1.1
Accept: application/xml,application/xhtml+xml,text/ [...truncated]
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; [...truncated]
Included in both examples
Many browsers do not support HTTP methods other than POST/GET.
Many browsers behaviors store the page address, but this doesn't mean you can ignore any of these other issues.
Is one inherently more secure then another? I realize that POST doesn't expose information on the URL but is there any real value in that or is it just security through obscurity? What is the best practice here?
This is correct, because the software you're using to speak HTTP tends to store the request variables with one method but not another only prevents someone from looking at your browser history or some other naive attack from a 10 year old who thinks they understand h4x0r1ng, or scripts that check your history store. If you have a script that can check your history store, you could just as easily have one that checks your network traffic, so this entire security through obscurity is only providing obscurity to script kiddies and jealous girlfriends.
Over https, POST data is encoded, but could urls be sniffed by a 3rd party?
Here's how SSL works. Remember those two requests I sent above? Here's what they look like in SSL:
(I changed the page to https://encrypted.google.com/ as example.com doesn't respond on SSL).
bb3D?05Dh/PrS6_/&5p@V f $)/xvxfgO'q@y&e&S0rB3D/Y_/fO?
t7DX1O8oD?fVObiooi'8)so?o??`o"FyVOByY_ Supo? /'i?Oi"4
(note: I converted the HEX to ASCII, some of it should obviously not be displayable)
The entire HTTP conversation is encrypted, the only visible portion of communication is on the TCP/IP layer (meaning the IP address and connection port information).
The only thing that POST is a security measure towards? Protection against your jealous ex flipping through your browser history. That's it. The rest of the world is logged into your account laughing at you.
To further demonstrate why POST isn't secure, Facebook uses POST requests all over the place, so how can software such as FireSheep exist?
Note that you may be attacked with CSRF even if you use HTTPS and your site does not contain XSS vulnerabilities. In short, this attack scenario assumes that the victim (the user of your site or service) is already logged in and has a proper cookie and then the victim's browser is requested to do something with your (supposedly secure) site. If you do not have protection against CSRF the attacker can still execute actions with the victims credentials. The attacker cannot see the server response because it will be transferred to the victim's browser but the damage is usually already done at that point.
A shame you didn't talk about CSRF :-). Is there any way to contact you?
"[...] so this entire security through obscurity is only providing obscurity to script kiddies and jealous girlfriends.[...]" . this entirely depends on the skills of the jealous gf. moreover, no gf/bf should be allowed to visit your browser history. ever. lol.