So first #Apple, then #GitHub and now the birdsite were apparently logging clear-text passwords for debugging and 'forgot' to turn it off for production.
My question is, what's the rationale for *ever* logging passwords? Even for debugging, I don't see much purpose behind logging clear-text passwords, could someone explain? #webdev #netsec
@MatejLach This is probably the result of some sounds-profoundly-stupid-unless-you-have-infinite-storage-and-poor-decision-making policy, like "globally log all POST requests so we can optimise our engagement". Oops! Sign-up forms are POST requests!
@MatejLach I've personally encountered a scenario where it happened by accident - bad auth attempt resulted in writing to the error log with the params, including plaintext pre-hash password. (Not saying it's ok, just that we're human and sometimes don't anticipate things well enough).
@MatejLach At least I know that polices/inteligence-agency use password to track peoples; as even when they change login or use Tor, some keep the same password.
@MatejLach During development, a few cases come to mind:
1. Making sure the "wrong password" message is actually because of a wrong password given.
2. problems with passwords containing special characters in different charsets.
3. Unit testing of the password routines without exposing too much of the innards to the Unit testing framework.
Keeping this logging on in production is the real fuckup.
@maho Good points, but for 1. shouldn't you be testing against the hashed passwords anyway, since that's what you (presumably) store?
(And I don't think there's much point in testing something like scrypt itself).
2. If the passwords are hashed, special characters shouldn't really come into play here, I'd think.
1. That still means you might have a problem with your hashing / salting algorithm which you will never find if you don't have the plaintext.
2. if a badly-encoded cyrillic password is badly-reencoded to unicode-16 before being hashed, of course the hash will differ - but you will not immediately know why.
@MatejLach
It might be genuinely useful if for example a middleware is sanitising user input. Test if your code receives a < character instead of an < character representation.
@MatejLach
Of course the fact that the logging code used for debugging ended up in the production server should count as gross incompetence...
@MatejLach
"Move fast and break stuff"...
@MatejLach this has happened more than once in places I've worked. You don't set out to log passwords, they just end up in text you're logging anyway when you least expect it.
Definitely remove query strings and userinfo from all URLs before logging them, and Authorization headers before logging request bodies. Probably the #1 cause of failures.
@MatejLach I don't want to assume incompetence over malice, but..
I've seen Apache+PHP log erroring function calls with arguments in plaintext, so it's possible that it might have been (partly) unintentional.