-
-
Notifications
You must be signed in to change notification settings - Fork 10.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
My API Key was stolen!!! #1123
Comments
Thank you for raising an issue. We will investigate into the matter and get back to you as soon as possible. |
你加了密码了么? |
Have you added a password? |
这个问题首先得说清楚:
|
This question needs to be clarified first:
|
楼主还使用了大小写加标点 |
The author also used uppercase and lowercase punctuation |
如果真是这样,那么可能就是密码被爆破了。类似的问题兄弟产品 ChatNextWeb 也遇到过:
在 LobeChat 中,目前有关密码校验的实现如下: export const checkAuth = ({ apiKey, accessCode }: AuthConfig) => {
const { ACCESS_CODES } = getServerConfig();
// 如果用户在网页填写 api key,不做密码比对
if (apiKey) {
return { auth: true };
}
// 如果服务端没有填写 ACCESS_CODES 环境变量
if (!ACCESS_CODES.length) return { auth: true };
// 实际比对密码
if (!accessCode || !ACCESS_CODES.includes(accessCode)) {
return { auth: false, error: ChatErrorType.InvalidAccessCode };
}
return { auth: true };
}; 其中关于密码的比对是通过 我强化一下这块的安全实现吧。 |
If this is the case, then the password may have been compromised. Similar problems have also been encountered by brother product ChatNextWeb:
In LobeChat, the current implementation of password verification is as follows: export const checkAuth = ({ apiKey, accessCode }: AuthConfig) => {
const { ACCESS_CODES } = getServerConfig();
// If the user fills in the api key on the web page, no password comparison will be performed
if (apiKey) {
return { auth: true };
}
// If the server does not fill in the ACCESS_CODES environment variable
if (!ACCESS_CODES.length) return { auth: true };
// Actual comparison password
if (!accessCode || !ACCESS_CODES.includes(accessCode)) {
return { auth: false, error: ChatErrorType.InvalidAccessCode };
}
return { auth: true };
}; The comparison of passwords is achieved through pure plaintext comparison such as Let me strengthen the security implementation of this area. |
This issue is closed, If you have any questions, you can comment and reply. |
🎉 This issue has been resolved in version 0.123.0 🎉 The release is available on: Your semantic-release bot 📦🚀 |
💻 系统环境
Other
📦 部署环境
Vercel / Zeabur / Sealos
🌐 浏览器
Chrome
🐛 问题描述
我的API KEY在这个项目上被盗了!
各位G友,不知道你们有没有遇到过KEY被盗刷的情况?
我今天准备使用LOBE时,发现KEY不能用,结果去查了一下,发现我的KEY余额已经被干完了,于是查询消费记录,发现287页全是这个KEY在被消耗的记录,持续了1天半的时间,24小时不间断。
请看这个截图。
如果你也不幸有这样的遭遇,请一定注意保护好自己的KEY,最好不要在环境变量里设置默认的KEY,同时,为自己的KEY设置好最大限额或最大使用频率。
同时,如果你也不幸和我一样,请在下方留言,让更多人都能看到并引起重视!希望作者能排查问题,让大家能放心使用这么优秀的开源项目!
————————
My API KEY has been stolen on this project!
Dear G friends, may I know if you have ever encountered a situation where KEY has been hacked?
When I was preparing to use LOBE today, I found that KEY couldn't be used. I checked and found that my KEY balance had already been used up. So I checked my consumption records and found that page 287 was full of records of this KEY being consumed, which lasted for a day and a half, 24 hours without interruption.
Please take a look at this screenshot.
If you also have such unfortunate experiences, please pay attention to protecting your keys. It is best not to set default keys in environment variables, and at the same time, set a maximum limit or maximum usage frequency for your keys.I hope the author can troubleshoot the issue and let everyone rest assured to use such an excellent open source project!
🚦 期望结果
为什么会存在这种KEY被盗刷的情况?KEY是如何被人盗窃的?
📷 复现步骤
No response
📝 补充信息
No response
The text was updated successfully, but these errors were encountered: