[aprssig] More secure passcodes for APRS-IS?

Fri Apr 4 12:55:44 EDT 2025

For example, many use the DNS name rotate.aprs.net. This resolves to a list of servers, so you don’t really know who to expect to answer. I suspect a lot of code just plays back a script to weave through login. While I like your thought, you’ve now introduced a decision point which would take years to get added to a large portfolio of applications.

On Fri, Apr 4, 2025, at 12:30, Erik Beck wrote:
> Not sure how people use a load balancer; it does make a failover arrangement a bit more complicated, admittedly.
> 
> 
> Sent from my iPhone
> 
>> On Apr 4, 2025, at 11:46, Shawn Stoddard <stoddard at pobox.com> wrote:
>> 
>> That kills the poor man’s load balancer that is in-use or at least complicates it. 
>> 
>> On Fri, Apr 4, 2025, at 11:07, Erik Beck wrote:
>>> Another idea might be to extend the existing hash algorithm to include a server-specific 'salt'. That way the codes can't be reused ad nauseam by simple cut and paste.
>>> 
>>> Erik, N7FYO 
>>> 
>>> Sent from my iPhone
>>> 
>>>> On Apr 4, 2025, at 03:17, Erik Finskas <erik.finskas at gmail.com> wrote:
>>>> 
>>>> 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
>>>> _______________________________________________
>>>> 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/928f9dc0/attachment.htm>