Feature Replace pwd hashes in debug log with generic string

[Irrat]

All too often (Probably every other month) you see someone sharing their debug log without realizing they want to hide their pwd hashes.
Only a few people would want said hash in their logs to be the real thing, and to date I don't recall a situation where I want the real hash in my logs.

So I'm thinking that a new preference could be introduced, "hideLogHashes" which simply replaces any hashes in your log with a generic string.
Default by true, people can turn it to false.

436ydfgswtretrwtyds - for example, turns into 12345pwdhash54321

 

[Veracity]

This matters, because … ?

A password hash has nothing to do with your password. It is, essentially, a sessionid. It changes every session, and as long as you have logged out since you shared the log, it cannot he used to harm you.

Is this because the word “password” is scary?

There are many many requests which work equally well with or without.

 

[Irrat]

This matters, because … ?

A password hash has nothing to do with your password. It is, essentially, a sessionid. It changes every session, and as long as you have logged out since you shared the log, it cannot he used to harm you.

Is this because the word “password” is scary?

There are many many requests which work equally well with or without.

Every so often a naive user shares their log in discord, and someone has to tell them to relog.

An hour ago was the last time.

 

[Veracity]

If you insist.

When logging URLs, we replace “pwd=xxxxxx” with “pwd”. You want to edit KoL supplied response texts? I see no reason to do anything different.

Especially since KoLmafia will accept URLs like that and include the current password hash as the value when submitting the request.

 

[gausie]

I have pause here now, DEBUG logs also contain PHPSESSID and all the necessary load balancer and user string sessions. I think there is a possible session fixation attack here, but I haven't tried it.

 

[Irrat]

After some mild investigation, the attack vector requires that the debug log is shared immediately after the requests is made, and that the user does not make another http request so that the AWS load balancer cookie remains unchanged.

Obfuscation of the session id should invalidate that (Though obfuscating the AWS instead is better), obfuscation of the pwd hash should invalidate most "Hey click this link" attacks

 

[heeheehee]

After some mild investigation, the attack vector requires that the debug log is shared immediately after the requests is made, and that the user does not make another http request so that the AWS load balancer cookie remains unchanged.

I don't think that's right.

I can successfully issue a curl request using "stale" cookies (namely, after issuing several more HTTP requests). In fact, the only things that seem to be validated are:

• PHPSESSID is valid (invalidated on logout).
• AWSALBCORS matches an active session (probably times out after 5-10 minutes).
• User-Agent header matches exactly.

Dropping all other headers / cookies (AWSALB in particular) still yields 200 (invalid requests yield 302 redirecting to login.php?notloggedin=1).

 

[heeheehee]

One thing I haven't checked is whether the server also requires a matching IP address.

Also: looks like the expiry on the AWSALB cookies is 7 days:

Expires=Sun, 16 Oct 2022 01:43:55 GMT; Path=/

pwd=xxxx is only useful for "click this link" attacks. You need the PHPSESSID and AWSALBCORS and User-Agent to actually issue requests on behalf of a user, but if you have those, you can grab pwd from api.php (or basically anywhere else).