Mintplex-Labs/anything-llm
1
0
Fork 0
mirror of https://github.com/Mintplex-Labs/anything-llm.git synced 2026-07-19 14:13:35 -04:00
Code Issues 328 Packages Projects Releases 10 Wiki Activity

[GH-ISSUE #942] [FEAT] Login token recommendation #569

New Issue
Closed
opened 2026-02-22 18:20:13 -05:00 by yindo · 4 comments
yindo commented 2026-02-22 18:20:13 -05:00
Owner
Copy Link
Copy Source

Originally created by @xnetsc on GitHub (Mar 20, 2024).
Original GitHub issue: https://github.com/Mintplex-Labs/anything-llm/issues/942

To enhance the security of web login processes, a more secure and sophisticated approach involves the use of cryptographic keys, as follows:

1.	During user registration or password change, leverage the latest password as a seed to generate a unique pair of public and private keys. This ensures that the public and private keys are always directly correlated with the user’s password, allowing for the generation of these keys based on the user password at any given time.
2.	The server stores the username along with the corresponding public key.

Further steps for the login process include:

3.	At the time of login, the user’s password is used to regenerate the private key. Subsequently, a JSON object required for login is created, which may contain various pieces of information, but crucially includes a timestamp to guard against replay attacks. This JSON data is then signed using the private key.
4.	The signed information is submitted to the server.
5.	Upon receiving the login request (via “api/request-token”), the server retrieves the public key associated with the username from its database. It then uses this public key to verify the authenticity of the submitted login information. If the verification is successful, additional checks, such as the validity of the timestamp, are conducted.
6.	Once these checks are passed, a user token is generated. This token is encrypted using the user’s public key and sent back to the client.
7.	Upon receiving the response, the client decrypts the received token using its private key, thus completing the login process.

This methodology significantly enhances security by ensuring that passwords are not transmitted in plaintext, thereby reducing the risk of interception and unauthorized access.

Additionally, this approach offers the significant advantage of eliminating the need for the server to store user passwords. Instead, only usernames and their corresponding public keys are stored. This ensures that sensitive user information remains secure, even in the event of server anomalies, such as a security breach by hackers. By adopting this method, the integrity and confidentiality of user data are significantly enhanced, providing a robust defense against unauthorized access and data leaks.

Originally created by @xnetsc on GitHub (Mar 20, 2024). Original GitHub issue: https://github.com/Mintplex-Labs/anything-llm/issues/942 To enhance the security of web login processes, a more secure and sophisticated approach involves the use of cryptographic keys, as follows: 1. During user registration or password change, leverage the latest password as a seed to generate a unique pair of public and private keys. This ensures that the public and private keys are always directly correlated with the user’s password, allowing for the generation of these keys based on the user password at any given time. 2. The server stores the username along with the corresponding public key. Further steps for the login process include: 3. At the time of login, the user’s password is used to regenerate the private key. Subsequently, a JSON object required for login is created, which may contain various pieces of information, but crucially includes a timestamp to guard against replay attacks. This JSON data is then signed using the private key. 4. The signed information is submitted to the server. 5. Upon receiving the login request (via “api/request-token”), the server retrieves the public key associated with the username from its database. It then uses this public key to verify the authenticity of the submitted login information. If the verification is successful, additional checks, such as the validity of the timestamp, are conducted. 6. Once these checks are passed, a user token is generated. This token is encrypted using the user’s public key and sent back to the client. 7. Upon receiving the response, the client decrypts the received token using its private key, thus completing the login process. This methodology significantly enhances security by ensuring that passwords are not transmitted in plaintext, thereby reducing the risk of interception and unauthorized access. Additionally, this approach offers the significant advantage of eliminating the need for the server to store user passwords. Instead, only usernames and their corresponding public keys are stored. This ensures that sensitive user information remains secure, even in the event of server anomalies, such as a security breach by hackers. By adopting this method, the integrity and confidentiality of user data are significantly enhanced, providing a robust defense against unauthorized access and data leaks.
yindo added the enhancement label 2026-02-22 18:20:13 -05:00
yindo closed this issue 2026-02-22 18:20:13 -05:00
yindo commented 2026-02-22 18:20:13 -05:00
Author
Owner
Copy Link
Copy Source

@mccoysc commented on GitHub (Mar 20, 2024):

Or,in an alternative approach to authentication and data integrity, we forgo traditional token-based verification in favor of a system where each user action and its associated data payload are authenticated through digital signatures. In this model, users sign every request with their private key. The server then verifies the legitimacy and integrity of these requests by validating the signature against the user's public key. This method ensures two critical security assurances:

Authenticity - By verifying the digital signature with the public key, the server confirms that the request was indeed initiated by the legitimate user, effectively replacing the need for token-based authentication. This process guarantees that the requestor possesses the corresponding private key without revealing it, thereby affirming their identity.

Integrity - Digital signatures not only authenticate the sender but also ensure that the request data has not been altered in transit. Any modification to the original data would invalidate the signature, alerting the server to potential tampering. This ensures that the server processes the user's true intentions as expressed in the request.

This approach simplifies the authentication process by directly leveraging cryptographic principles, offering a clear and robust method for securing user interactions. It enhances security by ensuring both the identity of the requester and the integrity of the request data, providing a streamlined alternative to conventional token-based systems.

I recommend using this approach.

@mccoysc commented on GitHub (Mar 20, 2024): Or,in an alternative approach to authentication and data integrity, we forgo traditional token-based verification in favor of a system where each user action and its associated data payload are authenticated through digital signatures. In this model, users sign every request with their private key. The server then verifies the legitimacy and integrity of these requests by validating the signature against the user's public key. This method ensures two critical security assurances: Authenticity - By verifying the digital signature with the public key, the server confirms that the request was indeed initiated by the legitimate user, effectively replacing the need for token-based authentication. This process guarantees that the requestor possesses the corresponding private key without revealing it, thereby affirming their identity. Integrity - Digital signatures not only authenticate the sender but also ensure that the request data has not been altered in transit. Any modification to the original data would invalidate the signature, alerting the server to potential tampering. This ensures that the server processes the user's true intentions as expressed in the request. This approach simplifies the authentication process by directly leveraging cryptographic principles, offering a clear and robust method for securing user interactions. It enhances security by ensuring both the identity of the requester and the integrity of the request data, providing a streamlined alternative to conventional token-based systems. ### **I recommend using this approach.**
yindo commented 2026-02-22 18:20:13 -05:00
Author
Owner
Copy Link
Copy Source

@mccoysc commented on GitHub (Mar 20, 2024):

If implementing the second approach is challenging due to significant changes required in the front-end code, making it difficult to achieve in the short term, I suggest that, at the very least, the first approach mentioned above should be adopted.

@mccoysc commented on GitHub (Mar 20, 2024): If implementing the second approach is challenging due to significant changes required in the front-end code, making it difficult to achieve in the short term, I suggest that, **at the very least**, the first approach mentioned above should be adopted.
yindo changed title from [FEAT] Login token recommendation to [GH-ISSUE #942] [FEAT] Login token recommendation 2026-06-05 14:36:02 -04:00
yindo commented 2026-06-05 14:36:03 -04:00
Author
Owner
Copy Link
Copy Source

@xnetsc commented on GitHub (Mar 20, 2024):

Or,in an alternative approach to authentication and data integrity, we forgo traditional token-based verification in favor of a system where each user action and its associated data payload are authenticated through digital signatures. In this model, users sign every request with their private key. The server then verifies the legitimacy and integrity of these requests by validating the signature against the user's public key. This method ensures two critical security assurances:

Authenticity - By verifying the digital signature with the public key, the server confirms that the request was indeed initiated by the legitimate user, effectively replacing the need for token-based authentication. This process guarantees that the requestor possesses the corresponding private key without revealing it, thereby affirming their identity.

Integrity - Digital signatures not only authenticate the sender but also ensure that the request data has not been altered in transit. Any modification to the original data would invalidate the signature, alerting the server to potential tampering. This ensures that the server processes the user's true intentions as expressed in the request.

This approach simplifies the authentication process by directly leveraging cryptographic principles, offering a clear and robust method for securing user interactions. It enhances security by ensuring both the identity of the requester and the integrity of the request data, providing a streamlined alternative to conventional token-based systems.

I recommend using this approach.

<!-- gh-comment-id:2011074986 --> @xnetsc commented on GitHub (Mar 20, 2024): Or,in an alternative approach to authentication and data integrity, we forgo traditional token-based verification in favor of a system where each user action and its associated data payload are authenticated through digital signatures. In this model, users sign every request with their private key. The server then verifies the legitimacy and integrity of these requests by validating the signature against the user's public key. This method ensures two critical security assurances: Authenticity - By verifying the digital signature with the public key, the server confirms that the request was indeed initiated by the legitimate user, effectively replacing the need for token-based authentication. This process guarantees that the requestor possesses the corresponding private key without revealing it, thereby affirming their identity. Integrity - Digital signatures not only authenticate the sender but also ensure that the request data has not been altered in transit. Any modification to the original data would invalidate the signature, alerting the server to potential tampering. This ensures that the server processes the user's true intentions as expressed in the request. This approach simplifies the authentication process by directly leveraging cryptographic principles, offering a clear and robust method for securing user interactions. It enhances security by ensuring both the identity of the requester and the integrity of the request data, providing a streamlined alternative to conventional token-based systems. ### **I recommend using this approach.**
yindo commented 2026-06-05 14:36:03 -04:00
Author
Owner
Copy Link
Copy Source

@xnetsc commented on GitHub (Mar 20, 2024):

If implementing the second approach is challenging due to significant changes required in the front-end code, making it difficult to achieve in the short term, I suggest that, at the very least, the first approach mentioned above should be adopted.

<!-- gh-comment-id:2011092558 --> @xnetsc commented on GitHub (Mar 20, 2024): If implementing the second approach is challenging due to significant changes required in the front-end code, making it difficult to achieve in the short term, I suggest that, **at the very least**, the first approach mentioned above should be adopted.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
Desktop
Docker
Integration Request
Integration Request
OS: Linux
OS: Mobile
OS: Windows
UI/UX
blocked
bug
bug
core-team-only
documentation
duplicate
embed-widget
enhancement
feature request
github_actions
good first issue
investigating
needs info / can't replicate
possible bug
pull-request
Mirrored from GitHub Pull Request
 question
stage: specifications
wontfix
No Label enhancement
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: Mintplex-Labs/anything-llm#569
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?