+ 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?)

---
* Origin: 1995| Invention of the Cookie. The End. (21:3/102)

Re: binkd: Bad password
By: Oli to All on Thu Sep 09 2021 07:55 pm

Hi,

+ 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?)

The session I saw was this:

+ 10 Sep 03:48:13 [166923] incoming session with tmo-116-252.customers.d1-online.com [80.187.116.252]
- 10 Sep 03:48:13 [166923] VER binkd/1.1a-112/Linux binkp/1.1
- 10 Sep 03:48:13 [166923] FOR 21:3/0@fsxnet
+ 10 Sep 03:48:13 [166923] addr: 2:280/464.47@fidonet
+ 10 Sep 03:48:13 [166923] addr: 21:3/102@fsxnet
+ 10 Sep 03:48:13 [166923] addr: 39:150/200.47@amiganet (n/a or busy)
+ 10 Sep 03:48:13 [166923] addr: 0:0/0.1@null (n/a or busy)
+ 10 Sep 03:48:13 [166923] addr: 4096:1/3@onion (n/a or busy)
- 10 Sep 03:48:13 [166923] OPT NDA EXTCMD CRYPT GZ BZ2
+ 10 Sep 03:48:13 [166923] Remote supports asymmetric ND mode
+ 10 Sep 03:48:13 [166923] Remote supports EXTCMD mode
+ 10 Sep 03:48:13 [166923] Remote requests CRYPT mode
+ 10 Sep 03:48:13 [166923] Remote supports GZ mode
+ 10 Sep 03:48:13 [166923] Remote supports BZ2 mode
- 10 Sep 03:48:13 [166923] TRF 0 0
+ 10 Sep 03:48:13 [166923] Remote has 0b of mail and 0b of files for us
? 10 Sep 03:48:13 [166923] `CRAM-MD5-7b5f59cb165df93407526c2ef6790a6e': incorrect password
+ 10 Sep 03:48:13 [166923] done (from 2:280/464.47@fidonet, failed, S/R: 0/0 (0/0 bytes))

The line of particular interest is the one with "FOR" - I've not seen that before.

(I assume you were configured with the correct password.)

What I dont like about binkd is I presented you the FSXnet addresses (zone 21) - but binkd logged the session with your fido address, even though you also presented a zone 21 address (with the same domain).


...δεσ∩
--- SBBSecho 3.14-Linux
* Origin: I'm playing with ANSI+videotex - wanna play too? (21:2/116)

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?)

The session I saw was this:

+ 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.

- 10 Sep 03:48:13 [166923] VER binkd/1.1a-112/Linux binkp/1.1
- 10 Sep 03:48:13 [166923] FOR 21:3/0@fsxnet

^^^
[...]

+ 10 Sep 03:48:13 [166923] addr: 0:0/0.1@null (n/a or busy)
+ 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.

? 10 Sep 03:48:13 [166923] `CRAM-MD5-7b5f59cb165df93407526c2ef6790a6e': incorrect password

data leak ;) that could have been a real password. Not sure how crackable the hash is. Why does binkd even log it?

The line of particular interest is the one with "FOR" - I've not seen
that before.

That's because I have just invented it ;). See below

(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.

What I dont like about binkd is I presented you the FSXnet addresses
(zone 21) - but binkd logged the session with your fido address, even 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 <aka>" 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 <aka> <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)

Re: binkd: Bad password
By: Oli to deon on Fri Sep 10 2021 09:14 am

? 10 Sep 03:48:13 [166923] `CRAM-MD5-7b5f59cb165df93407526c2ef6790a6e': incorrect password

data leak ;) that could have been a real password. Not sure how crackable the hash is. Why does binkd even log it?

Yeah if it was a cleartext password, I wouldnt have posted it for everybody to see - there may be some sysops here with ulterior motives.

But I dont think this hash is "crackable", since it is a reply to the nonce that I presented to you when you connected with the the addition of your password.

I dont recall how binkd creates this nonce - ie: is it a truely a random number, or created from something like the time or sequence number.

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.

+ 18:48 [5024] addr: 21:3/100@fsxnet
+ 18:48 [5024] addr: 21:3/0@fsxnet

I wonder if this is something that could be fixed upstream. I agree and think it should be an easy fix.
When you connect, I only presented you the FSX addresses - and specifically the hub's address first. I do think binkd could have checked for any other known passwords in the configuration - but not sure if that would break other things.

There was MPWD in the design, but I'm not sure if/how that can be used with CRAM, and if it could, then that probably fix this. (Not sure if binkd actually implemented it either?)

See, that is what I mean with 'kaputt'. The server cannot know the AKA that has been polled.

But the server can (and in binkd's case does) know the clients addresses before presenting it's own. The fact that I only presented you zone 21 addresses, my binkd should have logged the session with your zone 21 address (IMHO), not the fido one you presented (which was probably the first one).

M_NUL FOR
The idea is simple. Client sends the (single) AKA for the node it polls in an M_NUL "FOR <aka>" 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 <aka> <aka> ..." frame for informational purposes.

Have you presented this idea to the binkd folks to see what they think of it?

I'd like the idea of authenticating with multiple AKA's - since I feed for a few networks, clearing all mail out in the same session is appealing to me.


...δεσ∩
--- SBBSecho 3.14-Linux
* Origin: I'm playing with ANSI+videotex - wanna play too? (21:2/116)

deon wrote (2021-09-11):

? 10 Sep 03:48:13 [166923]
`CRAM-MD5-7b5f59cb1s5dfs3407s26c2es679sa6e': incorrect password

data leak ;) that could have been a real password. Not sure how
crackable the hash is. Why does binkd even log it?

Yeah if it was a cleartext password, I wouldnt have posted it for
everybody to see - there may be some sysops here with ulterior motives.

But I dont think this hash is "crackable", since it is a reply to the
nonce that I presented to you when you connected with the the addition of your password.

AFAIK MD5 is not very strong and a brute force attacks might be successful, depending on the password in use. If it were only uppercase and numbers and not longer than 8 characters ... ;)

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.

+ 18:48 [5024] addr: 21:3/100@fsxnet
+ 18:48 [5024] addr: 21:3/0@fsxnet

I wonder if this is something that could be fixed upstream.

Where is upstream? The FTSC?
I don't see any real binkd development. At the moment not even bugs get fixed.

I also see it more as a problem in the design of the binkp protocol and not specific to binkd.

I agree and
think it should be an easy fix. When you connect, I only presented you
the FSX addresses - and specifically the hub's address first. I do think binkd could have checked for any other known passwords in the
configuration - but not sure if that would break other things.

That would work in this specific case, but would make the protocol even weirder and less transparent for the user. I also think it would be hard to get the security right. A server could present you any address and fish for passwords. So the client should send a password for an alternative address only for addresses that have the same host:port in the nodelist or DNS root-domain. If the client doesn't use nodelists, but DNS lookups, it would to have make a lookup and see if host:port matches before sending the alternative password.

But yes it's possible and maybe some other binkp mailers are already doing it. I'm not convinced that this is a good strategy.

There was MPWD in the design, but I'm not sure if/how that can be used
with CRAM, and if it could, then that probably fix this. (Not sure if
binkd actually implemented it either?)

Interesting. It is mentioned in this draft, but never made it in the final standard.
https://www.ritlabs.com/binkp/

It wouldn't solve all the other problems of N-to-N AKAs though. It might also a pain-in-the-ass to debug. If one of your passwords is wrong, you get an M_ERR.

See, that is what I mean with 'kaputt'. The server cannot know the
AKA that has been polled.

But the server can (and in binkd's case does) know the clients addresses before presenting it's own. The fact that I only presented you zone 21 addresses, my binkd should have logged the session with your zone 21 address (IMHO),

Okay, I overlooked that your server only responded with 21:* addresses.

not the fido one you presented (which was probably the first one).

It was. Binkd uses the order from config file.

M_NUL FOR
The idea is simple. Client sends the (single) AKA for the node it
polls in an M_NUL "FOR <aka>" 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 <aka> <aka> ..." frame for informational purposes.

Have you presented this idea to the binkd folks to see what they think of it?

Not yet. For now it's just prototyping and testing.

I'm also nor sure who the binkd folks (plural) are and where do they hang around. Do I have to subscribe to the binkd-dev mailing list? Or should this better be discussed on BINKD, NET_DEV, FTSC_PUBLIC to include other binkp mailer developers?

I'd like the idea of authenticating with multiple AKA's - since I feed
for a few networks, clearing all mail out in the same session is
appealing to me.

I'm not against the idea of multiple AKAs in one session, but I want more than authentication with multiple AKAs. My goal is to have (authenticated) file/mail transfer from a specific local AKA to a specific remote AKA (in both directions). Achieving this with multiple AKAs in one session might involve some bigger extension to the protocol. I doubt there is enough momentum to create binkp/1.2 or binkp/2.0 and I'm not sure it would be worth the effort.

Maybe I'm missing something and it's easier than I think.

I had no intentions to extend the binkp protocol. My main interest is a better interface between mailer and tosser. BSO is too simple, which makes it more complex and error prone than necessary (one example are PKT and TIC passwords). Everything gets dumped into one inbound and tosser and filefix have to untangle it. I tried binkd's inboxes, but it didn't work reliable. It turned out the problem is the N-to-N ambiguous AKA mapping with creates weird side effects.

I don't want waste time on big ideas for the binkp protocol, when only a few people would be interested at all. And I think it's better to simplify than to make the protocol more complex (to implement).

---
* Origin: 1995| Invention of the Cookie. The End. (21:3/102)