Fiddler is intercepting password for SSL enabled HTTPS login

When I keep the Fiddler ON and enter into my SSL enabled HTTPS pega website, I am seeing password of my login in the 303 transmissions.

I know this will not happen if the login is authenticated through SSO. But, is there any way to HASH ( or atleast encrypt ) the password during the 303 transmission.

I took a look at the following article but I'm not sure if it will solve the problem I have.

Can you advise on how to hide/hash/encrypt the login password during transmissions during logon ?

**Moderation Team has archived post**

This post has been archived for educational purposes. Contents and links will no longer be updated. If you have the same/similar question, please write a new post.


Keep up to date on this post and subscribe to comments

October 21, 2016 - 9:17am


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. 







October 21, 2016 - 10:19am

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.


October 21, 2016 - 3:41pm

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 )

October 24, 2016 - 4:04pm

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:

December 30, 2017 - 11:15am

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.