- 14 Jan 11:02:34 [23306] SYS The Oracle BBS
- 14 Jan 11:02:34 [23306] LOC Clinton, PA
- 14 Jan 11:02:34 [23306] ZYZ Fr333n3rgy
- 14 Jan 11:02:34 [23306] TIME Thu, 13 Jan 2022 22:02:34 0000
- 14 Jan 11:02:34 [23306] VER Mystic/1.12A47 binkp/1.0
- 14 Jan 11:02:34 [23306] BUILD 2021/12/24 21:21:08 Raspberry Pi/32
+ 14 Jan 11:02:34 [23306] addr: 21:1/136@fsxnet
+ 14 Jan 11:02:34 [23306] addr: 3:770/999@fidonet
? 14 Jan 11:02:34 [23306] inconsistent pwd settings for this node
? 14 Jan 11:02:34 [23306] `letmein': incorrect password
+ 14 Jan 11:02:34 [23306] done (from 21:1/136@fsxnet, failed, S/R: 0/0 (0/0 bytes))
14 Jan 11:02:34 [23306] session closed, quitting...

in the above case I have a node in Zone 21 defined in BinkD and a password etc. all set up.

The node has then flown a fidonet test aka 3:770/999 that I have a definition for also in BinkD

node 3:770/999@fidonet noname.com letmein h /hub/filebox/fidonet_z3n770n999

The passwords between Zone 21 definition in BinkD for this node and the test Fido aka are not the same.

It seems like I can't offer a node that I have setup for one Zone an option to connect to another Zone unless I use the same passwords across all definitions? Is this correct or am I missing something?

--- Mystic BBS v1.12 A47 2021/11/06 (Linux/64)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (3:770/100)

Re: Password Question
By: Paul Hayton to All on Fri Jan 14 2022 11:14 am

Howdy,

+ 14 Jan 11:02:34 [23306] addr: 21:1/136@fsxnet
+ 14 Jan 11:02:34 [23306] addr: 3:770/999@fidonet
? 14 Jan 11:02:34 [23306] inconsistent pwd settings for this node
? 14 Jan 11:02:34 [23306] `letmein': incorrect password

It seems like I can't offer a node that I have setup for one Zone an option to connect to another Zone unless I use the same passwords
across all definitions? Is this correct or am I missing something?

Correct.

There is an implementation of binkd that authenticates against *each* address (there is a flag for it, but it escapes me) - but I dont think any implementation of binkp protocol does it.

So the authentiction is done against the first address presented, and validated with each addtional address to determine if mail for those addresses should also be sent to this authenticated caller.


...����
--- SBBSecho 3.14-Linux
* Origin: I'm playing with ANSI+videotex - wanna play too? (3:633/509)

On 14 Jan 2022 at 09:31a, deon pondered and said...

Howdy,

Hey

It seems like I can't offer a node that I have setup for one Zone an op to connect to another Zone unless I use the same passwords
across all definitions? Is this correct or am I missing something?

Correct.

OK thanks.

There is an implementation of binkd that authenticates against *each* address (there is a flag for it, but it escapes me) - but I dont think
any implementation of binkp protocol does it.

If anyone knows that version, please sing out.

So the authentiction is done against the first address presented, and validated with each addtional address to determine if mail for those addresses should also be sent to this authenticated caller.

OK thanks, that clarifies this for me. Hmm

--- Mystic BBS v1.12 A47 2021/11/06 (Linux/64)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (3:770/100)

Paul wrote (2022-01-14):

+ 14 Jan 11:02:34 [23306] addr: 21:1/136@fsxnet
+ 14 Jan 11:02:34 [23306] addr: 3:770/999@fidonet
? 14 Jan 11:02:34 [23306] inconsistent pwd settings for this node
? 14 Jan 11:02:34 [23306] `letmein': incorrect password

in the above case I have a node in Zone 21 defined in BinkD and a
password etc. all set up.

The node has then flown a fidonet test aka 3:770/999 that I have a definition for also in BinkD

node 3:770/999@fidonet noname.com letmein h /hub/filebox/fidonet_z3n770n999

The passwords between Zone 21 definition in BinkD for this node and the test Fido aka are not the same.

It seems like I can't offer a node that I have setup for one Zone an option to connect to another Zone unless I use the same passwords across all definitions? Is this correct or am I missing something?

Yes, that is another problem with binkp's flawed security model.

I this use case one could try to use the perl-hooks for an workaround. Simplest solution would be to check for the test AKA and then only present the relevant Fido AKA (and drop all your other AKAs). So call from 3:770/999 only returns 3:770/100.

The problem with this workaround is, that the node cannot receive any other mails (from FSX) if ith's polling its mails, as long as the test AKA is configured. So could make the perl script a bit more complicated and check, if there is anything in your outbound for 3:770/999 and if the outbound is empty, drop the Fido AKA.

Maybe there are better strategies... (?)

You could also just not use a password, it's not a secret anyway.

If the calling node is using binkd, they could use the hide-aka option in binkd.cfg. No idea if Mystic provides anything similar.

But I wonder, why does a node have to use a test AKA, if they already have a working connection in another network with your hub and knows how the stuff works? Just give them a node number in Fido and configure the same password.

---
* Origin: Birds aren't real (2:280/464.47)

Re: Password Question
By: Oli to Paul Hayton on Fri Jan 14 2022 12:51 pm

Hey Oli,

Yes, that is another problem with binkp's flawed security model.

I this use case one could try to use the perl-hooks for an workaround. Simplest solution would be to check for the test AKA and then
only present the relevant Fido AKA (and drop all your other AKAs). So call from 3:770/999 only returns 3:770/100.

The problem with this workaround is, that the node cannot receive any other mails (from FSX) if ith's polling its mails, as long as the
test AKA is configured. So could make the perl script a bit more complicated and check, if there is anything in your outbound for
3:770/999 and if the outbound is empty, drop the Fido AKA.

You dont need a perl script to hide AKA's - it's a config option. Although IIRC, you were playing with a perl script that enhanced the hide AKA option that binkd provides.

On FSX Hub 3, it's a hub for multiple networks, but when anybody in FSX connects to it, it'll hide the AKA's for the other networks that are not common with the hub. The side effect is, if more than 1 address is in common (and thus presented), then the password must be the same for each, otherwise you get that "invalid password" type message.



...����
--- SBBSecho 3.14-Linux
* Origin: I'm playing with ANSI+videotex - wanna play too? (3:633/509)

deon wrote (2022-01-14):

You dont need a perl script to hide AKA's - it's a config option.
Although IIRC, you were playing with a perl script that enhanced the hide AKA option that binkd provides.

Right, you can use hide-aka. But there is more flexibility with the perl hooks.

On FSX Hub 3, it's a hub for multiple networks, but when anybody in FSX connects to it, it'll hide the AKA's for the other networks that are not common with the hub.

Same here.

The side effect is, if more than 1 address is in
common (and thus presented), then the password must be the same for each, otherwise you get that "invalid password" type message.

It would be great to force the client to present only one AKA and/or announce for which AKA it is calling.

---
* Origin: Birds aren't real (2:280/464.47)

Paul wrote (2022-01-14):

There is an implementation of binkd that authenticates against
*each* address (there is a flag for it, but it escapes me) - but I
dont think any implementation of binkp protocol does it.

If anyone knows that version, please sing out.

Multi-authentication in one session is a half-baked solution for a problem that is bigger in scope. Also it takes two to tango (both peers would have to support it).

---
* Origin: Birds aren't real (2:280/464.47)