[aprssig] More secure passcodes for APRS-IS?

[Shawn Stoddard]

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/58322859/attachment.htm>