Bug - Not A Bug Password Hash

StDoodle

Minion
NOTICE!

This bug only appears while in chat with the GM script "ActiveChat" enabled for me. However, sfwarlock says he gets the bug in different situations. I'm stumped.

---------------------------------------

After getting disconnected for lack of activity, I found the following message repeating endlessly after my connection was re-established:
Code:
Password hash mismatch
Path: "/KoLmafia/messageUpdate?pwd="
Hmm... upon further review, this issue persists until KoLmafia has been completely closed and restarted, if that helps.

(Also, it appears I can no longer copy text from the gCLI, which is a shame, but likely a problem with something other than KoLmafia...)

Edit to add: using r8223 on Vista 64
Edit 2: unlike the poster on the GD thread, it DOESN'T show my current password on the gCLI.
Edit 3: debug emailed; can't figure out the *^%$ file attachment thing..
 
Last edited by a moderator:

Veracity

Developer
Staff member
Oh. well, he need not have "redacted" the hash. It's not like it's his real password, or usable to derive it; it's good for only that single session.
 

Chez

Member
For what it's worth, ActiveChat sends a blank password hash as part of the url, which is why you're not seeing it in the gCLI.
I was under the impression that mafia will replace any password hashes with what it believes to be the correct hash. Has this changed recently ?

Edit: Also, if it helps...seems like the issue was introduced somewhere between r8206 (working) and r8215 (not working). Doodle, if you can verify that, I can download some more releases inbetween and try to narrow it down further.
 
Last edited:

StDoodle

Minion
I don't know EXACTLY which revision I was using, but I don't tend to go more than a week without grabbing the latest build, so that is somewhere in the neighborhood. Let me know if there's more I can do.
 

Chez

Member
After some more digging around I think I've narrowed it down to r8208.

LocalRelayAgent.java contains some modifications that deals with non-null and incorrect password hashes. (lines 266-289)

As stated above, I'm sending through blank password hashes, since mafia (used to) replace them with the correct hashes anyway. The specific URL's that are affected are:

"/KoLmafia/submitCommand?cmd=someurlencodedcommand&pwd="
"/KoLmafia/messageUpdate?pwd="

Not sure what the best solution would be. I couldn't find an easy way to get hold of the correct password hash without loading additional pages and doing html scraping. If anyone can point me in the right direction I can make modifications to my script as required.

Either way, I'll wait for a response from one of the mafia devs before taking it further. Let me know if I can provide any more info.
 

Veracity

Developer
Staff member
Revision 8208 did not change when KoLmafia decided to drop a request because of non-matching or missing password hash. It used to drop such requests silently. That revision made it log a message when it drops a request.

I have never heard of ActiveChat. I am surprised that it is submitting KoLmafia internal commands. ASH programs can use "string my_hash()" to get the password hash. If ActiveChat is GM, that probably doesn't help.
 

Chez

Member
Hi Veracity

ActiveChat is a (fairly new) GM script based on CDM's original Tabbed Chat script. It incorporates gCLI integration in much the same way as mafia gives you the option to, which is why I'm submitting internal commands.

More info can be found here: http://hardcoreoxygenation.com/forums/viewtopic.php?t=6019

Also, r8207 and earlier certainly did not drop those requests, silently or otherwise. I accept that this was probably not the intended behavior to start with, so I'll look into other ways of obtaining the correct hash.
 

Veracity

Developer
Staff member
Ah, I see. Yes, prior to 8208, internal calls - those starting with /KoLmafia - simply required that there be a "pwd" field. It never actually looked at them, near as I can tell, since they were internal commands and were not sent on to KoL itself.

Yes. I did make it check the password hash for /KoLmafia internal calls, starting in 8208.
 

garjon

Member
Code:
Password hash mismatch
Path: "/multiuse.php?whichitem=1918&action=useitem&ajax=1&quantity=3&pwd=771216ebf9ec67f88335c13c5ce6e97f&_=1267921133905"
Getting this trying to use items (old purses and wallets) from the relay. The request goes through in the item manager.
Using most recent build from builds.kolmafia.us.
 

Veracity

Developer
Staff member
I am unable to reproduce this.

- I bought 3 old coin purses
- I went to the Relay Browser and opened up the Miscellaneous page of inventory
- I turned on verbose debug logging:

Code:
-----From Browser-----
GET /multiuse.php?whichitem=1918&action=useitem&ajax=1&quantity=3&pwd=d9acc707d3e7d1e40e1dd83cbd11b6a1&_=1267922830875 HTTP/1.1

(note the path. It's the same as yours, modulo the password hash. That gives me confidence that I did the same thing as you did.)

Code:
Requesting: http://www.kingdomofloathing.com/multiuse.php?whichitem=1918&action=useitem&ajax=1&quantity=3&pwd=d9acc707d3e7d1e40e1dd83cbd11b6a1&_=1267922830875
...
Retrieved: http://www.kingdomofloathing.com/multiuse.php?whichitem=1918&action=useitem&ajax=1&quantity=3&pwd=d9acc707d3e7d1e40e1dd83cbd11b6a1&_=1267922830875
...
Parsing result: You gain 1,428 Meat
You gain 1,428 Meat
Processing result:  Meat Gained: 1,428
Processing result: old coin purse (-3)
 

Veracity

Developer
Staff member
Can I mark this "fixed"?

The fact is, it's a security hole if we automatically fill in the password hash for you. J.Random.Greasemonkey Script - or arbitrary website, if it is intent on trickery - can submit an arbitrary KoLmafia command, and if we don't require you to submit the correct hasht but automatically fill it in, said script can really screw you over. By requiring the password hash, we require you to do a little work to scrape the hash, before asking KoLmafia to do dangerous things.

I'e tightened things up - and that's the new regime. I'm not going to relax and open up security holes again.
 

Chez

Member
Agree 100% on the potential security issues. I've already modified my script to send through the correct hash, so from my side I'm happy if you mark it as fixed.
 
kolmafia fails to log out

In the relay browser, I click the Logout button, and then the CLI shows this:

Password hash mismatch
Path: "/KoLmafia/logout?pwd="


However, if I then use the General -> Logout of KoL button in that menu, it logs out just fine.
 

Veracity

Developer
Staff member
What is the "Logout button"? Are you referring to the HTML link labeled "log out" - in the full menu pane?
What "menu" in the Relay Browser is labelled "General" and has a "Logout of KoL" menu item ("button"?) in it?
In the compact menu pane, there is a "Function" menu with a "Log Out" menu item in it.

Both of those - the HTML link and the "Log Out" menu item - invoke /KoLmafia/logout?pwd=xxxx, where xxxx is the password hash of the session - and both of them work just fine to log you out. In fact, that is how I (almost) always log out of the Relay Browser.

Is this some Greasemonkey thing?
 

Bale

Minion
Actually, that happened to me once, recently, when I clicked the logout link in my relay browser. Only happened once though so I didn't bother reporting it. Weird.

I was using Opera 10.51, obviously no greasemonkey, though I do have a relay over-ride script so that might have been responsible.
 
I'll try to be more specific.

Clicking the logout button in the top menu (with the rest of the navigation links) in the relay browser causes that error which the CLI shows. This has happened to me every time with mafia v14.0, unmodified.

If, however, I go to the Mafia swing GUI, and go to the General menu, and select the logout that's located there, it behaves exactly as expected.

The only script I have active which touches that top navigation pane (where the moons are, etc), is the Raid Manager for the clan dungeons.
 

Veracity

Developer
Staff member
I don't know what to say. For me, clicking on that link sends a command to KoLmafia which submits a request to logout.php and waits for the the redirect to loggedout.php, which it displays in the Relay Browser. It also deletes all GUI windows and pops up the Login Frame.

In other words, it works perfectly.
 
Top