[GH-ISSUE #333] 允许重置为任意的key而无需验证是否会导致后续通知被截获? #293

Closed
opened 2026-03-03 11:42:15 +03:00 by kerem · 3 comments
Owner

Originally created by @inCloudRain on GitHub (Dec 20, 2025).
Original GitHub issue: https://github.com/Finb/Bark/issues/333

我注意到目前使用重置或还原key功能可以将一个任意的推送Key绑定到当前设备上,而此过程缺乏对Key所有权的验证。

这引发了我的担忧:如果我将自己的推送Key分享给第三方用于向我发送消息,理论上,对方是否有可能利用此机制,在他们自己的Bark客户端中将我的Key绑定到他们的设备上?如果可行,则之后所有发送到该Key的通知,都将被他们的设备截获,而我的设备将无法收到。

请作者确认是否存在该风险?

Originally created by @inCloudRain on GitHub (Dec 20, 2025). Original GitHub issue: https://github.com/Finb/Bark/issues/333 我注意到目前使用重置或还原key功能可以将一个任意的推送Key绑定到当前设备上,而此过程缺乏对Key所有权的验证。 这引发了我的担忧:如果我将自己的推送Key分享给第三方用于向我发送消息,理论上,对方是否有可能利用此机制,在他们自己的Bark客户端中将我的Key绑定到他们的设备上?如果可行,则之后所有发送到该Key的通知,都将被他们的设备截获,而我的设备将无法收到。 请作者确认是否存在该风险?
kerem closed this issue 2026-03-03 11:42:16 +03:00
Author
Owner

@Finb commented on GitHub (Dec 20, 2025):

如果对方知道你的 key,确实可以替代你接收推送。

尽量不要将 key 泄露,可以添加多次服务器获取多个 key,只共享那个不重要的 key。
还可以使用加密推送,只有你的设备可以正确解密。

<!-- gh-comment-id:3677680814 --> @Finb commented on GitHub (Dec 20, 2025): 如果对方知道你的 key,确实可以替代你接收推送。 尽量不要将 key 泄露,可以添加多次服务器获取多个 key,只共享那个不重要的 key。 还可以使用加密推送,只有你的设备可以正确解密。
Author
Owner

@inCloudRain commented on GitHub (Dec 20, 2025):

但aes加密也是对称的,而且接收解密端似乎只能设置一组密钥,这么看来目前唯一安全的方法就是对每个推送方都提供不同的key了。

是否应该考虑使用不对称的推送key或者提供不对称加密?

<!-- gh-comment-id:3677709461 --> @inCloudRain commented on GitHub (Dec 20, 2025): 但aes加密也是对称的,而且接收解密端似乎只能设置一组密钥,这么看来目前唯一安全的方法就是对每个推送方都提供不同的key了。 是否应该考虑使用不对称的推送key或者提供不对称加密?
Author
Owner

@Finb commented on GitHub (Dec 20, 2025):

不考虑

你自己的推送使用加密推送,第三方的推送还是普通的。
并不需要你将秘钥共享给第三方

<!-- gh-comment-id:3677711074 --> @Finb commented on GitHub (Dec 20, 2025): 不考虑 你自己的推送使用加密推送,第三方的推送还是普通的。 并不需要你将秘钥共享给第三方
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/Bark#293
No description provided.