[GH-ISSUE #264] Feature request: Password Protected Admin-page. #2915

New Issue

sascha_hemi · 2026-03-20T22:05:40+01:00

sascha_hemi commented

2026-03-20 22:05:40 +01:00

Originally created by @frodr1k on GitHub (Mar 6, 2024).
Original GitHub issue: https://github.com/OpenEPaperLink/OpenEPaperLink/issues/264

Is your feature request related to a problem? Please describe.
Lack of security. The admin page should at least be protected by a login

Describe the solution you'd like
The AP needs some kind of password protection at least. In the long term we should run some kind of shakedown of the AP to find and fix other vulnerabilities. But first things first.

Describe alternatives you've considered

Additional context
Add any other context or screenshots about the feature request here.

Originally created by @frodr1k on GitHub (Mar 6, 2024). Original GitHub issue: https://github.com/OpenEPaperLink/OpenEPaperLink/issues/264 **Is your feature request related to a problem? Please describe.** Lack of security. The admin page should at least be protected by a login **Describe the solution you'd like** The AP needs some kind of password protection at least. In the long term we should run some kind of shakedown of the AP to find and fix other vulnerabilities. But first things first. **Describe alternatives you've considered** **Additional context** Add any other context or screenshots about the feature request here.

sascha_hemi added the enhancement label 2026-03-20 22:05:40 +01:00

sascha_hemi closed this issue

2026-03-20 22:05:40 +01:00

sascha_hemi commented

2026-03-20 22:05:40 +01:00

@jjwbruijn commented on GitHub (Mar 6, 2024):

Please only use an OEPL AP on a network you have control over.

A 'shakedown' of the AP isn't necessary. It's unsecured. It's not meant to be used on a 'public' network. Security of a device like this was never a goal, and any attempts to make it 'safe' will generally be laughable.

Even if you would secure the webserver, the AP uses unencrypted/unauthenticated multicast packets to sync state to other potential accesspoints. A DoS attack on an ESP32 doesn't require a whole lot of traffic and would also disturb the functioning of the accesspoint.

Furthermore, the 802.15.4 protocol used by OEPL is fully unencrypted and unauthenticated, which means it can be spoofed easily. If this is a concern, a different solution might be more fitting for you.

@jjwbruijn commented on GitHub (Mar 6, 2024): Please only use an OEPL AP on a network you have control over. A 'shakedown' of the AP isn't necessary. It's unsecured. It's not meant to be used on a 'public' network. Security of a device like this was never a goal, and any attempts to make it 'safe' will generally be laughable. Even if you would secure the webserver, the AP uses unencrypted/unauthenticated multicast packets to sync state to other potential accesspoints. A DoS attack on an ESP32 doesn't require a whole lot of traffic and would also disturb the functioning of the accesspoint. Furthermore, the 802.15.4 protocol used by OEPL is fully unencrypted and unauthenticated, which means it can be spoofed easily. If this is a concern, a different solution might be more fitting for you.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/OpenEPaperLink#2915