What you are seeing here is simply HTTP form level authentication. This is done with a HTML form post and the UserIdentifier and Password will be able to be seen with tools like Fiddler or browser level network captures. Keep in mind though that these tools are capturing the data client side in a way that it can seen. When using SSL the network packets are encrypted as they pass through to the server and that is why you use SSL, so information along the path from client to server can not be read.
When you're using SSO you are probably using desktop level authentication, SPENGO / Kerberos. Using Fiddler you can can still see authentication communication, it's not password but token data.
The "About Password Hashing" is all about how we store password data and what extra security features you can enabled.
If you are using SSL - then all your HTTP traffic will be end-to-end encrypted - and anyone 'sniffing' the traffic over-the-wire (as opposed to you running FIDDLER on your workstation) will see only encrypted traffic - and therefore will not have access to the plain-text of the password or any other data.
It seems like you're concerned about a man-in-the-middle attack, but what you've done is basically replace one end point with the "man-in-the-middle" - that being Fiddler that you've configured to decrypt HTTPS (and specifically accepted it's own certificate).
To any external party the HTTPS traffic will be encrypted end to end.
You'll find a similar answer to this on stackoverflow:
Fiddler2 relies on a "man-in-the-middle" approach to HTTPS interception. To your web browser, Fiddler2 claims to be the secure web server, and to the web server, Fiddler2 mimics the web browser. In order to pretend to be the web server, Fiddler2 dynamically generates an https certificate.
Fiddler's certificate is not trusted by your web browser (since Fiddler is not a Trusted Root Certification authority), hence looks like in your case you have added the fiddler certificate to the trusted store.