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)