* To quote your previous claim: "There is no such thing as an unguessable name." Right. That doesn’t mean *I* have to guess it.
* Even if your deployment team had such staggeringly bad operational security practices as to allow people to take packet captures from an internal network and show them on public slides without any kind of questions being asked, if this actually happens *YOU ARE NO WORSE OFF THAN IN THE SITUATION WHERE YOU USED A WELL-KNOWN HEADER NAME*! Yes you are worse off. Because that now-exposed header value can be used for spoofing. As opposed to protection by TLS, and then sending the plaintext message around. * I don't know how many different ways I can say that this is a defense in depth Because it is not. It is taking an application-level piece of configuration data and requiring it to be treated as if it were crypto material. Which it cannot be, because multiple parties need to know it (as I said, the proxy, the backend, the app developers, the support team, etc). It’s defense by “collapsing layers” rather than “in depth.” * As with all defense in depth, the aim is to be more than 1 configuration mistake away from total compromise. But that is exactly what you are proposing. Exposing the header *is* a total compromise and multiple entities will need to know that header value. At any rate, I think we’re done here.
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
