u/cd7k wrote (the comment Michael replied to):
> not an issue with the security architecture. How is it not an issue with the security architecture? You shouldn't be *able* to know a users password, but you could compare a hash of what they entered with the hash you had stored. At no point, anywhere, should you be able to
u/michaelnovati replied ·
If I remember correctly, I think there was a couple of situations, again, I'm not speaking on behalf of the company and just as a person reading through these articles.
One was that there's a version of Facebook that runs on feature phones that has no ability to make any kind of requests other than get requests and has very minimal client-side processing, No JavaScript, no cookies, or anything.
So if you had that situation where you can only make get requests and you have zero JavaScript that you can run. how would you do authentication? You have to send the password over get but you have to make sure that every level of your back end isn't logging that in any human readable place. So you have to make sure that your server logs don't show it. you have to make sure that any logging systems that the request metadata gets sent to don't show it basically have it completely thrown away.
If you know a solution that works with only HTML no cookies, and get requests to do authentication. I'm all ears.
after the initial authentication is done then every single link on the page can contain a token in it that can be short-term and used for authentication but that initial authentication check is what I'm talking about.
Second, is the logging issue, where client-side tools can suck in every single field on the screen or like whatever logic and those could be accidentally sucked into some kind of logging back-end system that isn't actually used for authentication at all and it would just be like the same as if it's sucked in your name or a comment you made on that same screen with the bug that's being logged.