Hi,

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. 

--Chris

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.

Thanks for both the responses.

In my reported scenario, 

1. I am neither using a simple HTTP nor SSO currently. 
2. I am launching a Pega app that is secured with SSL 
3. I am launching Fiddler that can sniff secured traffic ( Fiddler Options --> HTTPS --> Capture HTTPS CONNECTs ( Ticked) & Decrypt HTTPS traffic ( Ticked ) ) from the same machine
4. I can clearly see the content of 303 & 200 transmission through Fiddler as the tool is configured to detect with above option.

My query was -- What should be the configuration I need to do on top of the SSL so that even tools like Fiddler cannot detect the traffic. This is the query raised by my Security testers.

( On a side note - Using Fiddler in my machine, I was able to intercept my PDN password I used to login to my PDN account )

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:

http://stackoverflow.com/questions/13505628/if-i-can-see-my-password-in-fiddler-webform-session-does-it-mean-its-sending-p

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.