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