Subj : binkd: Bad password
To   : Oli
From : deon
Date : Sat Sep 11 2021 12:37 pm

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

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

.