🚀 Feature: Add a page showing info regarding Login Codes #232

Closed
opened 2025-10-09 16:33:54 +03:00 by OVERLORD · 3 comments
Owner

Originally created by @gtensolr on GitHub.

Feature description

This feature would add a page on the GUI that show all of the Login Codes, with the ability of the admin to revoke a code or re-send it. In addition it would be nice to have filters such as Active/Expired, Used/Not Used, User who generated. In addition a built-in simple logic to deter brute force login would be nice, i.e. after 5 failed codes, the IP is banned for a couple of hours.

Pitch

Currently one of the only ways of Inviting a user to create an account on Pocket ID is to create a Login Code and mail to that person. After the code is created, there's no way for the admin to see active codes, if they were used or not and to revoke them, which can open an attack vector to the server. Having the ability to monitor Login Codes, especially when it's recognized that they offer lower level of security would be ideal.

Originally created by @gtensolr on GitHub. ### Feature description This feature would add a page on the GUI that show all of the Login Codes, with the ability of the admin to revoke a code or re-send it. In addition it would be nice to have filters such as Active/Expired, Used/Not Used, User who generated. In addition a built-in simple logic to deter brute force login would be nice, i.e. after 5 failed codes, the IP is banned for a couple of hours. ### Pitch Currently one of the only ways of Inviting a user to create an account on Pocket ID is to create a Login Code and mail to that person. After the code is created, there's no way for the admin to see active codes, if they were used or not and to revoke them, which can open an attack vector to the server. Having the ability to monitor Login Codes, especially when it's recognized that they offer lower level of security would be ideal.
OVERLORD added the feature label 2025-10-09 16:33:54 +03:00
Author
Owner

@stonith404 commented on GitHub:

Brute forcing shouldn't be a concern for Pocket ID since the system only permits validation of a login code once every 10 seconds.

Login codes valid for less than 15 minutes consist of 6 characters, resulting in 56'800'235'584 possible combinations. Within this 15-minute window, an attacker could only attempt 96 combinations, making successful brute force attacks statistically improbable.

For login codes with validity periods exceeding 15 minutes, a 16-character string is generated, yielding 3'226'266'762'400'000'000'000 possible combinations. With a maximum expiration period of 31 days for login codes, an attacker could make at most 267'840 attempts in a month, rendering brute force attacks practically impossible.

Because of that I don't really see a use-case for having a dashboard to manage login codes, it would just bloat the application.

@stonith404 commented on GitHub: Brute forcing shouldn't be a concern for Pocket ID since the system only permits validation of a login code once every 10 seconds. Login codes valid for less than 15 minutes consist of 6 characters, resulting in 56'800'235'584 possible combinations. Within this 15-minute window, an attacker could only attempt 96 combinations, making successful brute force attacks statistically improbable. For login codes with validity periods exceeding 15 minutes, a 16-character string is generated, yielding 3'226'266'762'400'000'000'000 possible combinations. With a maximum expiration period of 31 days for login codes, an attacker could make at most 267'840 attempts in a month, rendering brute force attacks practically impossible. Because of that I don't really see a use-case for having a dashboard to manage login codes, it would just bloat the application.
Author
Owner

@kmendell commented on GitHub:

You can see the 'Token Sign in' log under the global audit log section to see if the login code was used or not.

As far as a UI to see all the codes, im not sure i see the use, as you shouldnt need to generate logion codes really more than once, or in the case of account recovery.

Adding fail2ban im not sure about, ill talk to elias on that, but i think to keep the scope of the project simple, my initial thought is not to implement it, You could extract the logs from docker and you could run fail2ban yourself based on those logs?

@kmendell commented on GitHub: You can see the 'Token Sign in' log under the global audit log section to see if the login code was used or not. As far as a UI to see all the codes, im not sure i see the use, as you shouldnt need to generate logion codes really more than once, or in the case of account recovery. Adding fail2ban im not sure about, ill talk to elias on that, but i think to keep the scope of the project simple, my initial thought is not to implement it, You could extract the logs from docker and you could run fail2ban yourself based on those logs?
Author
Owner

@gtensolr commented on GitHub:

I appreciate your time for responding to my suggestion!

Currently you can see the one time code thru the global audit logs, but that doesn’t allow the user to “manipulate” the code such as resending it and revoking. Although not a common scenario, if the admin generates a code with 1 month duration and its not promptly used (email when to spam, technologically challenged family members, etc), it open as change for brute force.

In regards to fail2ban and logs: Since I’m not using the built in Caddy and instead am using nginx for Pocket ID, I was able to configure Crowdsec properly to block IPs that are attempting to brute force the login code, even if none are configured.

@gtensolr commented on GitHub: I appreciate your time for responding to my suggestion! Currently you can see the one time code thru the global audit logs, but that doesn’t allow the user to “manipulate” the code such as resending it and revoking. Although not a common scenario, if the admin generates a code with 1 month duration and its not promptly used (email when to spam, technologically challenged family members, etc), it open as change for brute force. In regards to fail2ban and logs: Since I’m not using the built in Caddy and instead am using nginx for Pocket ID, I was able to configure Crowdsec properly to block IPs that are attempting to brute force the login code, even if none are configured.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/pocket-id-pocket-id-2#232