我发现大模型后台 API KEY ，复制策略分 2 种
1 、可以明码查看复制的，比如：阶跃星辰 step
2 、首次复制，以后就隐藏的，比如：ds
第 2 种所谓安全，实则脱裤子 XX
1 、可以明码查看复制的，比如：阶跃星辰 step
2 、首次复制，以后就隐藏的，比如：ds
第 2 种所谓安全，实则脱裤子 XX
• 请不要在回答技术问题时复制粘贴 AI 生成的内容
 |
1
penzi 10h 15m ago  9
你觉得所有输入密码的地方显示 *** 是不是也是脱裤子放屁
|
 |
2
Greenm 10h 15m ago 1
有用啊，很多厂商都这样做的，比如各大云厂商下载 aksk 也这样的。 主要防止的就是你账号失窃后 API key 不会被冒用，可以减少爆炸半径。
|
 |
3
nomansky 10h 13m ago 3
我也不清楚这两种是为啥。其他的平台只能首次复制的，猜测这种只能复制的功能特性可能是为了表示 key 是一次性生成的，不做明文保存。后端用对称加密或者 hash
|
 |
4
Topmax 10h 13m ago
如果密钥一定会泄露，那只在第一次显示可以极大缩减排查范围和可能的损失。
|
 |
5
Curtion 10h 11m ago
甚至有可能第二种是因为云端就没有存明文 key, 后续想查询也做不到了
|
 |
6
ntdll 10h 2m ago
第二种安全，指的是厂家安全。因为仅展示一次，比如过半年以后被盗刷，那几乎可以断定是用户保管不当。即使后续用户在平台侧的账号泄露，也不会造成这些 api key 的泄露，而要重置这些 api key ，厂家会触发二次验证。
|
 |
7
digitv 10h 1m ago 12
只显示一次的都是假装为了安全甩锅的设计，现状就是用户很大可能不止使用一次 key ，这就导致只能自己保存，自己保存的风险远远大于平台保存。平台纯粹是懒政，想解决安全问题方法很多，最简单的加个二次验证就好了
|
 |
8
cloudzhou 10h 1m ago
这是安全策略，key 的重要性远高于账户，尤其是里面涉及资产，现在 token 就是资产
举个例子，有一天账号体系被突破了（ CSDN...），但是 key 拿不到，那么用户就很少了 否则，很快的，token 都会被刷没，各种中转站 |
 |
9
Tink 10h 0m ago
本站 api key 也是
|
 |
10
icanfork 9h 59m ago
这是合理的安全策略
|
|
11
Tink 9h 59m ago 2
这种动作最根本的原因是，让服务端尽量不保存（或无法还原）API Key 的明文
|
 |
12
chendy 9h 51m ago
很常规的安全设计
服务方一个 key 只显示一次，使用方一个 key 也只用于一个用途 这样发生一些事故的时候比较容易定位和处理 |
 |
13
94 9h 48m ago
所以为什么现在密码安全还是要推荐不同平台的账户不要用同一套账密呢。Secret Key 也是一样的道理。
|
 |
14
yidinghe PRO 你考虑一下自己帐号被黑，如果可以无限复制，那你的 key 就都被盗了。如果只能复制一次，key 就不会因为帐号被黑而被盗。
|
 |
15
keenkiller 9h 43m ago
防泄漏，后台数据库没存原始值
|
 |
16
maplezzz 9h 41m ago
这单纯就是平台把泄露的风险责任推给个人
|
 |
17
belite 9h 39m ago
1. 减少攻击面，即便自己的数据库被拖库了，api 不会泄露
2. 责任转移，以后有涉及 API 泄露的 与他无关，肯定是你的问题 脱裤子 XX 是什么意思？不能提高安全性？ |
 |
18
Fistandantilus 9h 38m ago 1
啊，你们 XX 的时候都不脱裤子吗
|
 |
19
xooass 9h 36m ago
亚马逊的店铺 apikey 好像每 3 个月就要轮换一次
|
 |
20
paopjian 9h 33m ago
现用现取的策略在你嘴里就成 脱裤子 xx 了, 把一个最高权限秘钥串当做普通文本传来传去是一点安全意识没有啊
|
 |
21
yplam 9h 32m ago
因为后台不存明文 API Key
|
 |
22
BornThisWay 9h 30m ago
合规而已 别想那么多
账号泄露了 key 没泄露不能创建个新 key ？ |
 |
23
yanerweb OP 为什么“阶跃星辰 step”等大模型后台，允许随时查看 API KEY 明码？为什么？
|
 |
26
itskingname 9h 19m ago 6
假如账号泄露，黑客登录你的后台。然后疯狂消费。你发现账单异常。上来排查：
对于阶跃这种，他们拿到了你正在使用的 key ，你上来停了这个 key 。你会面临两个问题： 1. 同一个 key ，你不知道哪些钱是黑客消耗的，哪些钱是你自己正常生产环境消耗的。 2. 你的所有生产环境都用的这个 key ，停掉以后，你的生产环境立刻就会挂掉。 对于 ds 这种，黑客登录后台以后，只能重新创建一个 key 。你上来停掉这个新增的 key 。你的所有生产环境不受影响。只需要看这个新的 key ，你马上就能知道黑客消费了多少钱。 |
|
27
cloudzhou 9h 18m ago
@shintendo 你这是好问题，如果一个系统曲线复杂，会引入不同 key 的限额等，创建的时候也应该有二次授权，其实查询的时候引入二次授权我也觉得可以，但是直接查看，在很多系统下都是尽量避免
|
 |
28
iorilu 9h 8m ago
这还要问, 当然有意义
如果平台被黑客突破 拿到了账户信息 但是, key 没保存拿不到, 理论上你没什么损失 如果给你 key 搞走了如果钱多的可能损失不小, 看你叫不叫 |
 |
29
ShineyWang 9h 2m ago
密码不明文保存,加盐
用户服务和调接口的服务不是同一个 防止数据库泄漏导致 key 泄漏;这样一方出问题不会影响另一方 cookie 可能泄漏导致能上你后台,但是看不到 key; 很多关键地方都有二次验证,这样即使 cookie 泄漏 不会导致资产损失 除了 cookie 泄漏,用户如果用了有毒的油猴脚本;也会威胁用户资产;隔离开就安全多了 |
 |
30
jimrok 8h 56m ago
你可以耍赖告平台偷偷泄露了你 key 。1 那种可能讲不清楚，也许是你共享了你的账号造成的，也可能是他们客服给你泄露的。2.那种你怎么找理由说服是他们泄露了你的 key ？
|
 |
31
git00ll 8h 53m ago
@BornThisWay 创建新 key 时，可以触发更强的验证，比如盗取了 cookie 想要创建新 key 必须重新输入密码啥的
|
 |
32
SP00F 8h 51m ago
首次设置密码，以后就看不到的，实则脱裤子 XX
又是招笑的来了，还是公式好用。😁 |
 |
33
zhuhaohenry 8h 47m ago 1
免责声明，如果泄露是你自己泄露的
|
|
34
yanerweb OP 贴上 claude sonnet 5.5 回答：
你说的这个观察挺到位的，确实第 2 种的"安全感"有点形式大于实质。 为什么第 2 种经常是"伪安全"： 1 、用户只会把 key 存到更多地方。 因为只能看一次，用户的第一反应是立刻粘到笔记、聊天记录、.env 、Git 仓库、飞书文档里。key 反而被扩散到了更多不受控的地方。 2 、丢了只能重建，改动成本高。 一旦忘记保存，就得新建 key ，然后去每个调用方替换，很多人懒得换，就会"先留着旧的"，形成 key 长期堆积。 3 、真正的泄露风险不在控制台。 泄露大多来自代码仓库、日志、前端抓包、聊天截图，不是"有人偷看你的后台页面"。能登录你后台的人，本来就能新建、删除 key ，隐藏旧 key 防不了什么。 4 、用户体验差。 多设备、多项目、团队协作时，每次都要重新生成，反而更容易乱。 |
 |
35
IvanLi127 8h 35m ago
这没那么复杂，人家后端压根不保存原始 key ，所以做不到再次回显。
|
 |
36
TimPeake 8h 27m ago 1
确实 ，苦之久矣了。类似的 就像 linux 输入密码不会显示一样(听说这个问题要改了？)，实际来说带来的收益远远低于便利性的收益。
|
 |
37
YangWaleed 8h 20m ago 4
@yanerweb
第 2 种做法保护的是平台自己，就算平台被入侵了也不会泄漏，那 key 泄漏了只能是用户侧。 而你这里列出的这些基本上都是用户视角，而且基本上也都是 “不好的使用习惯”。 1. 平台能随时查看就不会有人把 key 存到其他地方了？笔记、聊天记录、Git 、飞书文档里别说 key 了，用户名密码都不少见 2. 一个 key 一个用途，丢了也无所谓吧。一个 key 用在多个地方，泄露了你每个地方都要换反而更麻烦 3. 同样的，多设备、多项目、多人共用，更容易泄露，泄露了影响更大 所以你举的这些例子基本上都是使用习惯上的问题 |
 |
39
Marthemis 8h 12m ago
你能承受丢失带来的后果，但是上头的部门 OR 监管不允许。
|
 |
40
G0dBlessMe 8h 9m ago
不像是“望京酒仙桥”全栈工程师问出来的问题
|
 |
42
Zarhani 8h 5m ago
我都是把它们拷贝到 bitwarden 一份的
|
 |
43
docx 7h 59m ago via iPhone
热知识：GitHub PAT 也是只展示一次
|
 |
44
Y25tIGxpdmlk 7h 55m ago 1
@Tink #25 key 而已，又不是自己自定义的密码。咋就不能明文存储，又不是用这个 key 来端到端加密的，人家官方啥权限没有，难道还能盗取你的 key ，看你数据吗？
|
 |
45
crysislinux 7h 54m ago via Android
服务提供方不保存明文，然后漏了就是你漏的。
|
 |
46
WaldenHorizon 7h 47m ago
防止你账号被盗或者公共场合登录忘了退出，或者网站数据库暴露，和用户密码都是加盐哈希不保存原文一样吧。考虑用户自己保存不安全更是可笑，网站随时能看 key ，用户就一定不保存了吗
|
 |
47
suitts 7h 44m ago
风险转移
|
 |
48
LGZzzz 7h 36m ago
我觉得这两种方式没什么区别, 既然我都登陆上去回显 key, 那登陆上去我顺手重新生成一个也不是什么事了.
|
|
49
LGZzzz 7h 29m ago
我觉得上面说的“保护的是平台自己，就算平台被入侵了也不会泄漏，那 key 泄漏了只能是用户侧”很有道理.
如果平台被攻破, 流失的就不是你一个人的 key 了. 这个 key 本质上就像某个网站上的密码, 如果泄露了, 别人就会盗刷资产, 从平台的角度来看, 我先把泄漏影响最大的一面(自己被攻破了)这道防线做好,保证自己给用户生成的数量庞大的 key 不会泄漏. 另外 op 贴上的 claude sonnet 5.5 回答,第一点我不是很认同. 登录上去重新生成一个 key 的成本并没有多少, 就是点一下, 输入一个名字, 点一个复制的问题. 登录上去看一下以前的 key, 也是点一下显示, 再点一下复制. 两个操作最麻烦的操作就是登录. 如果 key 能明码查看复制, 你并不能保证用户不会把 key 复制的到处都是. 上一条回复我已经说了, 既然你都能登录上去明码查看了, 那重新生成一个也不是什么很繁琐的事情. 就算可以明码复制, 用户依然会嫌麻烦, 然后把 key 复制的到处都是. |
|
50
LGZzzz 7h 25m ago 2
我在实际使用的时候, 每当我需要一个 key 的时候, 我都会重新生成, 并且给 key 输入名字的时候, 会写明这个 key 在什么地方使用(哪个设备, 哪个应用). 不能明码查看 key, 并且重新生成, 这种强制行为在某种程度上帮助我追踪不同应用, 不同地点, 不同设置, 我到底消耗了多少 token. 我并不觉得这是一个拖裤子 xx 的设计.
|
 |
51
1OF7G 7h 4m ago
@itskingname 黑客：我先把你原来的删了，再自己建一个新的用。啊你发现了？那没事反正你服务崩了，嘻嘻。
|
 |
52
THESDZ 7h 3m ago
减少攻击面是一个非常好的方式啊。一次性，永远不给前台和 api 暴露。少一个漏洞是一个
|
 |
53
fredweili 7h 3m ago
你就觉得要方便，不太懂普通用户在安全上有多蠢
|
 |
55
jonty 7h 0m ago
@itskingname #26 黑客都能登录你后台了，你还能信任之前创建的 key ？
|
 |
56
interim 6h 22m ago 1
@yanerweb #34 不认同伪安全，你把 key 重复使用并且存在不同的地方导致的泄露本质是自己的安全习惯不好。正常是不同场景使用不同的 key ，即使泄露了，也能知道泄露源头并且快速禁用不影响其他场景正常使用，否则一个 key 泄露你需要动所有场景下使用的 key ，还找不到泄露源头。
|
 |
57
FringJX 5h 30m ago
更像是厂商鼓励你多创建 key ，而不是复制旧 key
|
 |
58
bowencool 5h 21m ago 1
重复利用 key 和多端共享 key 才是垃圾习惯，该改改了
|
 |
59
chenluo0429 5h 4m ago via Android 4
发帖是为了
A. 寻找帮助和答案 B. 发起讨论，扩展思路 C. 寻找认同，说服每一个意见不同的人 从 sonnet5.5 给你的回复看，你的问法就已经非常具有偏向性。AI 顺着你夸一夸，你还真当真了？ 询问 AI 的时候请中立，除非你就是打算拿 AI 答案来和别人吵架的。 大模型平台生成 API KEY 有两种策略，一种是仅生成时可以查看一次，后续无法查看。另一种是可以随时解密查看的。请你综合对比两种策略，给出相应的分析对比，优缺点，适用场景。并给出你更推荐哪一种。 |
 |
60
lepig 4h 56m ago
@digitv 说到非常好。
现在都是单独搞一个单独口令的目录来存放这些密钥文本，就感觉很麻烦。 他们这样做， 1. 就是你说的甩锅，出了密钥泄露是用户的问题，因为平台不会保存你的密钥(单程序员都知道它肯定是要保存到后端的)。 2. 是成本考虑。 对于腾讯/阿里这样的体量最简单的二次验证就是接收短信验证码，但是验证码要钱。量一大也是一笔不小的费用。 |
 |
61
unco020511 3h 58m ago
其实就是把安全风险转嫁给用户
|
|
63
YangWaleed 3h 48m ago
@LXVC 因为当你修改密码拿回账户后，你直接把黑客创建的那个 key 删了就行了。
如果黑客能拿到你之前的 key ，那你就还得把所有用到这个 key 的地方全换了。 更进一步，如果这个 key 你给多个设备、多个人共用，那这些设备和这些人都要全都替换一遍。 这样看是不是影响更大？ |
 |
64
qiuhang 2h 46m ago
自己为自己的密钥负责呗，厂家不存储。挺先进的密码学思路啊，有什么好困惑的。哪天厂商被拖库了，你的账号依然安全，这不是挺好的。
|
 |
65
MoozLee 2h 20m ago
是的，对安全性没有太多的帮忙，主要就是责任丢给用户，后台不用明文存储
|
 |
66
tf2 2h 14m ago
一个 key 只能用一次主要是记账方便啊。你复制来复制去的。到时候流量和账单算哪个头上都分不清了。
|
 |
67
iphoneXr 2h 7m ago
我倒是觉得云平台这种 apikey 禁止回显的方式很好！
但是有些自托管平台 比如 1panel-ai-gateway 也是这样的方式， 还限制 apikey 创建上限为 10 个就是有点 东施效颦了。 |
 |
68
JerryZhi 1h 35m ago
这就是厂商把风险转嫁给用户，纯甩锅。微软（也可能是谷歌）自己都写了篇文章说，要求用户定期修改密码并没有显著降低密码泄露风险，因为当每个平台都要求用户这样做，用户需要保护和记忆的密码数量很快就会超过脑容量，不得不使用最方便的办法将密码集中储存（无非是 txt 或者 excel 的区别），最终黑客还是只需要盗取一个密码文件即可爆掉一个人全部的账号
|
 |
70
zhy0216 1h 29m ago
这个设计可以不用存 api key 到 db 的 只用存 apikey 的 md5 值
然后一些特殊情况 比如如果云厂商被脱裤 用户可以不用换 api key |
Select Language