[aprssig] More secure passcodes for APRS-IS?

[Scott Miller]

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