Subj : Is binkp/d's security model kaputt? To : All From : Oli Date : Thu Sep 02 2021 09:42 am I'm trying to figure out how to configure binkd for reliable security. I see several problems. Part design flaw of the binkp protocol (and FTN tradition), part implementation. 1) Passwords stored in clear text It's not ideal, but I can live with that. At least it allows MD5-CRAM, which is not very secure, but better than clear plaintext over the wire. 2) Password is one way authentication only The client side (the calling system) does send a password, but there is no authentication of the server. It's not really a fully "pwd protected session" as binkd suggests. A man-in-the-middle can ignore the password (or accept any password) and binkd still would log a "pwd protected session". 3) CRYPT cannot be enforced If I understand it correctly, a CRYPT session only works when both sides use the same password. It's kind of an indirect authentication of both sides. Unfortunately there is no simple way in binkd to enforce CRYPT. Standard binkd does not prevent man-in-the-middle with CRYPT. 4) No direct node address mapping For sessions with multiple AKAs the protocol does not allow sending files from a specific AKA and/or to a specific AKA. This has several implications: 5) nonsecure inbound might be delivered to 'secure' inbound If the session is "pwd protected" everything will be stored in the 'secure' inbound directory, even files and PKTs for AKAs that don't have a password. 6) The ibox field is a joke Just because you configured an ibox for a node, doesn't mean that all files for that node will always be put in that ibox. The ibox also might receive files for other nodes. 7) check-pkthdr does not always work reliable Similar problem with check-pkthdr. We cannot always reliably predict the From- and To-AKA for a PKT in a multi-AKA session. IMHO binkd/binkp offers lots of pseudo security and several security and usability pitfalls. Are there any good workarounds or do we need a binkp/2.0? --- * Origin: . (21:3/102) .