Feature Request: account/password #38

New Issue

2026-10-05T01:17:09+02:00

adam commented

2026-10-05 01:17:09 +02:00

Adding the ability for users to create an account/password (account would be mapped to their nodeid and aliased as whatever account name they choose) would provide the ability to secure messages etc against spoofed nodes. Additionally, the ability to only allow bot access (obviously this would only be enabled if channel mode is false and dm only mode is true) to authenticated users would be important for some use cases. maybe a "create account" function for unauthenticated nodes, and approval requests either appear in the terminal on the running host, and also get sent to whoever is added as an admin node for meshing-around?

Adding the ability for users to create an account/password (account would be mapped to their nodeid and aliased as whatever account name they choose) would provide the ability to secure messages etc against spoofed nodes. Additionally, the ability to only allow bot access (obviously this would only be enabled if channel mode is false and dm only mode is true) to authenticated users would be important for some use cases. maybe a "create account" function for unauthenticated nodes, and approval requests either appear in the terminal on the running host, and also get sent to whoever is added as an admin node for meshing-around?

adam closed this issue

2026-10-05 01:17:09 +02:00

adam commented

2026-10-05 01:17:09 +02:00

Magic link pointing to a website that mirrors the bot and BBS is one way to do this. Email link and all. Over RF one could use a large window (30 min) with 2FA so you have to put in the 6 digit code at the start of the message. Need somewhat accurate clocks for this to work, so outputting the time would be helpful as one of the commands in the bot then.

Magic link pointing to a website that mirrors the bot and BBS is one way to do this. Email link and all. Over RF one could use a large window (30 min) with 2FA so you have to put in the 6 digit code at the start of the message. Need somewhat accurate clocks for this to work, so outputting the time would be helpful as one of the commands in the bot then.

adam commented

2026-10-05 01:17:10 +02:00

If the message server is on a secure channel why are nodes spoofing?

I am not sure I understand the need for security inside a secure message network. A mesh is secure with channel keys

Is the situation realistic to be exploited? Or just table top ideas?

If the message server is on a secure channel why are nodes spoofing? I am not sure I understand the need for security inside a secure message network. A mesh is secure with channel keys Is the situation realistic to be exploited? Or just table top ideas?

adam commented

2026-10-05 01:17:11 +02:00

If for example I wanted to lock DM keys with known friends

Via CLI lock in the key to the node DB on your bot node

meshtastic --set-favorite-node <node_id>

If for example I wanted to lock DM keys with known friends Via CLI lock in the key to the node DB on your bot node `meshtastic --set-favorite-node <node_id>`

adam commented

2026-10-05 01:17:11 +02:00

If the message server is on a secure channel why are nodes spoofing?

I am not sure I understand the need for security inside a secure message network. A mesh is secure with channel keys

Is the situation realistic to be exploited? Or just table top ideas?

Imagine somebody takes your mesh node, pairs it to their app (because most people dont change the bluetooth pin), and then connects to the BBS (which they would see in message history) to read mail or sensitive information.

Remember that there are three "factors" to security:

Who you are
What you have
What you know

If we conflate who you are (nodeid) with what you have (mesh node), then that is not secure as having the node also gives you the "identity" of the nodeid therefore those two factors are only one. Adding what you know, eg user/pass, makes it truly two-factor which is the baseline for security in 2025.

And really the nodeid would still be the username (alias to a chosen username might make things easier/more convenient but wouldnt be strictly necessary), but a password is essential (and of course with time limited sessions)

> If the message server is on a secure channel why are nodes spoofing? > > I am not sure I understand the need for security inside a secure message network. A mesh is secure with channel keys > > Is the situation realistic to be exploited? Or just table top ideas? Imagine somebody takes your mesh node, pairs it to their app (because most people dont change the bluetooth pin), and then connects to the BBS (which they would see in message history) to read mail or sensitive information. Remember that there are three "factors" to security: Who you are What you have What you know If we conflate who you are (nodeid) with what you have (mesh node), then that is not secure as having the node also gives you the "identity" of the nodeid therefore those two factors are only one. Adding what you know, eg user/pass, makes it truly two-factor which is the baseline for security in 2025. And really the nodeid would still be the username (alias to a chosen username might make things easier/more convenient but wouldnt be strictly necessary), but a password is essential (and of course with time limited sessions)

adam commented

2026-10-05 01:17:12 +02:00

I would contend the node with a Bluetooth PIN wouldn't normally be out of your control.

Would it also need to enforce every post with TOTP / OTP? Importing a classic OAUTH also would handle this but now you also need a phone OTP the use community here is very small? Two?

I would contend the node with a Bluetooth PIN wouldn't normally be out of your control. Would it also need to enforce every post with TOTP / OTP? Importing a classic OAUTH also would handle this but now you also need a phone OTP the use community here is very small? Two?

adam commented

2026-10-05 01:17:13 +02:00

PyOTP could be used here, with Google and Microsoft Auth.

But this adds a new problem; how would you manage keys for let's say 50 people.

The scope creep for the audience size here.

PyOTP could be used here, with Google and Microsoft Auth. But this adds a new problem; how would you manage keys for let's say 50 people. The scope creep for the audience size here.

adam commented

2026-10-05 01:17:13 +02:00

nothing heard, closing issue

nothing heard, closing issue

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: adam/meshing-around#38