[aprssig] More secure passcodes for APRS-IS?

[Erik Finskas]

It is true that the APRS passcode 'authentication' is not secure enough
when reflected to modern security criterias and is widely misused to flood
APRS-IS.

There are some other methods possible to prevent flooding from regular
users by rate-limiting the connection, and/or enhanced authentication
method for igates and servers with increased traffic rates.

A good reminder is that we all already have a free PKS solution enrolled
through LOTW, which allows everyone to have a certificate to use for
authentication purposes. It (only) requires some development to make it
usable for user authentication to APRS-IS.

73,
Erik OH2LAK

On Thu, 3 Apr 2025 at 19:47, Scott Miller <scott at opentrac.org> wrote:

> I'm sorry if that came out a little harsh - I haven't finished my coffee
> yet this morning.
>
> The instances I've seen of abuse have usually been fairly isolated and I
> think could be adequately addressed by coordinated temporary IP bans.
> The APRS-IS core operators would be in a better position to discuss
> countermeasures
>
> Scott
> N1VG
>
> On 4/3/2025 9:24 AM, Scott Miller wrote:
> > Who are you suggesting should take on the burden of verifying the
> > identity of everyone who wants to connect? Who defines the access
> > criteria? Are you going to implement different tiers of access for
> > internet to RF gating than for internet-only (e.g., flood monitors)?
> >
> > "Everyone can read the APRS-IS data stream" is a feature, not a bug.
> > It's always been open for public access. It'd be impossible to prevent
> > an authorized user from mirroring the stream, and someone definitely
> > would.
> >
> > There's no authentication on the RF side and you can post
> > disinformation that way, too. If you've got specific examples of abuse
> > that's happening, present them and we can tackle them. This is a
> > discussion that's been had many times over the past 20+ years and a
> > solution has to be more than technological. There are fundamental
> > policy questions about who the system belongs to, what traffic is
> > permissible, and who should have access that are much tougher problems
> > than selecting a hash algorithm.
> >
> > Scott
> > N1VG
> >
> > On 4/3/2025 6:17 AM, Øyvind Hanssen wrote:
> >> I have observed some cases of abuse of the APRS-IS network. It is too
> >> easy to post disinformation or to do DOS attacks, etc. Also, everyone
> >> can read the APRS-IS data stream. Maybe there are local APRS-IS
> >> networks that need a more restrictive access policy?
> >>
> >> The verification scheme is not designed to be secure. It is a simple
> >> hash of the username (callsign). Alternatively we might use SSL/TLS
> >> when making connections to APRS-IS nodes, but it is more complex to
> >> handle and not all software support it. It is necessary to have a CA
> >> that issues certificates, etc. etc. .
> >>
> >> What about a more secure hashing scheme? Using a secret + the
> >> username to generate a hash. HMAC (possibly with SHA-256) is a de
> >> facto standard and more secure than a simple hashing scheme. Hashes
> >> can be truncated and base-64 encoded. If existing software can use
> >> e.g.  a 16 character code instead of the 4-digit (16bit) passcodes
> >> without modification, it may be something? Also, such a scheme does
> >> not encrypt content. If that is a requirement, maybe SSL/TLS is better.
> >>
> >> It is not a proof of identity, but is a proof that you either know
> >> the secret or someone who does, has granted you access. Only
> >> passcode-issuers and APRS-IS nodes need to know the secret. The risk
> >> is of course that the secret is leaked and it may be rather
> >> cumbersome if it must be renewed.
> >>
> >> 73
> >>
> >> LA7ECA, Øyvind
> >>
> >>
> >> _______________________________________________
> >> aprssig mailing list
> >> aprssig at lists.tapr.org
> >> http://lists.tapr.org/mailman/listinfo/aprssig_lists.tapr.org
> >
> >
> > _______________________________________________
> > aprssig mailing list
> > aprssig at lists.tapr.org
> > http://lists.tapr.org/mailman/listinfo/aprssig_lists.tapr.org
>
>
> _______________________________________________
> aprssig mailing list
> aprssig at lists.tapr.org
> http://lists.tapr.org/mailman/listinfo/aprssig_lists.tapr.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tapr.org/pipermail/aprssig_lists.tapr.org/attachments/20250404/2a354747/attachment.htm>