<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto">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.<div><br></div><div>Erik, N7FYO <div><br id="lineBreakAtBeginningOfSignature"><div dir="ltr">Sent from my iPhone</div><div dir="ltr"><br><blockquote type="cite">On Apr 4, 2025, at 03:17, Erik Finskas <erik.finskas@gmail.com> wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr"><div dir="ltr">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.<div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>73,</div><div>Erik OH2LAK</div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Thu, 3 Apr 2025 at 19:47, Scott Miller <<a href="mailto:scott@opentrac.org">scott@opentrac.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I'm sorry if that came out a little harsh - I haven't finished my coffee <br>
yet this morning.<br>
<br>
The instances I've seen of abuse have usually been fairly isolated and I <br>
think could be adequately addressed by coordinated temporary IP bans. <br>
The APRS-IS core operators would be in a better position to discuss <br>
countermeasures<br>
<br>
Scott<br>
N1VG<br>
<br>
On 4/3/2025 9:24 AM, Scott Miller wrote:<br>
> Who are you suggesting should take on the burden of verifying the <br>
> identity of everyone who wants to connect? Who defines the access <br>
> criteria? Are you going to implement different tiers of access for <br>
> internet to RF gating than for internet-only (e.g., flood monitors)?<br>
><br>
> "Everyone can read the APRS-IS data stream" is a feature, not a bug. <br>
> It's always been open for public access. It'd be impossible to prevent <br>
> an authorized user from mirroring the stream, and someone definitely <br>
> would.<br>
><br>
> There's no authentication on the RF side and you can post <br>
> disinformation that way, too. If you've got specific examples of abuse <br>
> that's happening, present them and we can tackle them. This is a <br>
> discussion that's been had many times over the past 20+ years and a <br>
> solution has to be more than technological. There are fundamental <br>
> policy questions about who the system belongs to, what traffic is <br>
> permissible, and who should have access that are much tougher problems <br>
> than selecting a hash algorithm.<br>
><br>
> Scott<br>
> N1VG<br>
><br>
> On 4/3/2025 6:17 AM, Øyvind Hanssen wrote:<br>
>> I have observed some cases of abuse of the APRS-IS network. It is too <br>
>> easy to post disinformation or to do DOS attacks, etc. Also, everyone <br>
>> can read the APRS-IS data stream. Maybe there are local APRS-IS <br>
>> networks that need a more restrictive access policy?<br>
>><br>
>> The verification scheme is not designed to be secure. It is a simple <br>
>> hash of the username (callsign). Alternatively we might use SSL/TLS <br>
>> when making connections to APRS-IS nodes, but it is more complex to <br>
>> handle and not all software support it. It is necessary to have a CA <br>
>> that issues certificates, etc. etc. .<br>
>><br>
>> What about a more secure hashing scheme? Using a secret + the <br>
>> username to generate a hash. HMAC (possibly with SHA-256) is a de <br>
>> facto standard and more secure than a simple hashing scheme. Hashes <br>
>> can be truncated and base-64 encoded. If existing software can use <br>
>> e.g. a 16 character code instead of the 4-digit (16bit) passcodes <br>
>> without modification, it may be something? Also, such a scheme does <br>
>> not encrypt content. If that is a requirement, maybe SSL/TLS is better.<br>
>><br>
>> It is not a proof of identity, but is a proof that you either know <br>
>> the secret or someone who does, has granted you access. Only <br>
>> passcode-issuers and APRS-IS nodes need to know the secret. The risk <br>
>> is of course that the secret is leaked and it may be rather <br>
>> cumbersome if it must be renewed.<br>
>><br>
>> 73<br>
>><br>
>> LA7ECA, Øyvind<br>
>><br>
>><br>
>> _______________________________________________<br>
>> aprssig mailing list<br>
>> <a href="mailto:aprssig@lists.tapr.org" target="_blank">aprssig@lists.tapr.org</a><br>
>> <a href="http://lists.tapr.org/mailman/listinfo/aprssig_lists.tapr.org" rel="noreferrer" target="_blank">http://lists.tapr.org/mailman/listinfo/aprssig_lists.tapr.org</a><br>
><br>
><br>
> _______________________________________________<br>
> aprssig mailing list<br>
> <a href="mailto:aprssig@lists.tapr.org" target="_blank">aprssig@lists.tapr.org</a><br>
> <a href="http://lists.tapr.org/mailman/listinfo/aprssig_lists.tapr.org" rel="noreferrer" target="_blank">http://lists.tapr.org/mailman/listinfo/aprssig_lists.tapr.org</a><br>
<br>
<br>
_______________________________________________<br>
aprssig mailing list<br>
<a href="mailto:aprssig@lists.tapr.org" target="_blank">aprssig@lists.tapr.org</a><br>
<a href="http://lists.tapr.org/mailman/listinfo/aprssig_lists.tapr.org" rel="noreferrer" target="_blank">http://lists.tapr.org/mailman/listinfo/aprssig_lists.tapr.org</a><br>
</blockquote></div>
<span>_______________________________________________</span><br><span>aprssig mailing list</span><br><span>aprssig@lists.tapr.org</span><br><span>http://lists.tapr.org/mailman/listinfo/aprssig_lists.tapr.org</span><br></div></blockquote></div></div></body></html>