Subj : binkd: Bad password To : deon From : Oli Date : Fri Sep 10 2021 09:14 am deon wrote (2021-09-10): >> + 18:48 [5024] call to 21:3/0@fsxnet >> + 18:48 [5024] outgoing session with net3.fsxnet.nz:24554 >> - 18:48 [5024] OPT CRAM-MD5-2ac9af04c99d25b8725ef1180fd32cee >> - 18:48 [5024] SYS Alterant MailHub >> - 18:48 [5024] TIME Fri, 10 Sep 2021 03:48:13 +1000 >> - 18:48 [5024] VER binkd/1.1a-112/Linux binkp/1.1 >> + 18:48 [5024] addr: 21:3/100@fsxnet >> + 18:48 [5024] addr: 21:3/0@fsxnet >> ? 18:48 [5024] rerror: Bad password >> + 18:48 [5024] done (to 21:3/0@fsxnet, failed, S/R: 0/0 (0/0 bytes)) >> Why, oh why? >> (Not why do I get an error, but why is binkd so braindead?) d> The session I saw was this: d> + 10 Sep 03:48:13 [166923] incoming session with xxxxx Not that I care much in this case, but I think in general it would be a good idea to remove unnecessary personal data before posting it on the web (echo->synchronet web->google/archive.org). It would be even better, if it were obfuscated in the binkd logs by default. d> - 10 Sep 03:48:13 [166923] VER binkd/1.1a-112/Linux binkp/1.1 d> - 10 Sep 03:48:13 [166923] FOR 21:3/0@fsxnet ^^^ [...] d> + 10 Sep 03:48:13 [166923] addr: 0:0/0.1@null (n/a or busy) d> + 10 Sep 03:48:13 [166923] addr: 4096:1/3@onion (n/a or busy) My internal addresses should never have made it over the wire. I guess on that connection I had the perl script disabled that would hide AKAs in other domains. d> ? 10 Sep 03:48:13 [166923] `CRAM-MD5-7b5f59cb165df93407526c2ef6790a6e': d> incorrect password data leak ;) that could have been a real password. Not sure how crackable the hash is. Why does binkd even log it? d> The line of particular interest is the one with "FOR" - I've not seen d> that before. That's because I have just invented it ;). See below d> (I assume you were configured with the correct password.) That's the braindead part: I have a password for 21:3/100 - You have a password for 21:3/102. I have NO password for 21:3/0 - You have a password for 21:3/102. When I call 21:3/100 it works, when I call 21:3/0 I get a password error. d> What I dont like about binkd is I presented you the FSXnet addresses d> (zone 21) - but binkd logged the session with your fido address, even d> though you also presented a zone 21 address (with the same domain). See, that is what I mean with 'kaputt'. The server cannot know the AKA that has been polled. The client presents a list of AKAs, the server responds with a list of AKAs and both sides have matching or differing passwords for none/some/all of these AKAs. M_NUL FOR ========= The idea is simple. Client sends the (single) AKA for the node it polls in an M_NUL "FOR " frame. It also sends a single AKA in the ADR frame. The server responds also with a single AKA. Now we have a single AKA <-> single AKA (1-to-1) session and all the ambiguities go away. If you still want to present additional AKA, you could put it in an M_NUL "AKA ..." frame for informational purposes. The only disadvantage is that you cannot send files for different AKAs over one session. But then it's not a POTS connection and most of the time messages get delivered instantly and often a poll carries messages for only one network anyway. Unfortunately it needs more work than a little extension on the protocol level. Inbound/outbound and passwords needs to be 1-to-1 aware too. The experiments I did required only a bit of binkd / perlhooks hacking. For a full solution I think it's better to start a new binkp mailer from scratch (or extend Ginko). --- * Origin: 1995| Invention of the Cookie. The End. (21:3/102) .