• 请不要在回答技术问题时复制粘贴 AI 生成的内容
yanerweb
V2EX  ›  程序员

困惑: API KEY 只能复制一次,这不“脱裤子 XX”吗?

  •  
  •   yanerweb · 15h 25m ago · 7780 views
    我发现大模型后台 API KEY ,复制策略分 2 种

    1 、可以明码查看复制的,比如:阶跃星辰 step

    2 、首次复制,以后就隐藏的,比如:ds

    第 2 种所谓安全,实则脱裤子 XX
    81 replies  •  2026-10-13 00:27:41 +08:00
    penzi
        1
    penzi  
       15h 22m ago   ❤️ 9
    你觉得所有输入密码的地方显示 *** 是不是也是脱裤子放屁
    Greenm
        2
    Greenm  
       15h 22m ago   ❤️ 1
    有用啊,很多厂商都这样做的,比如各大云厂商下载 aksk 也这样的。 主要防止的就是你账号失窃后 API key 不会被冒用,可以减少爆炸半径。
    nomansky
        3
    nomansky  
       15h 20m ago   ❤️ 3
    我也不清楚这两种是为啥。其他的平台只能首次复制的,猜测这种只能复制的功能特性可能是为了表示 key 是一次性生成的,不做明文保存。后端用对称加密或者 hash
    Topmax
        4
    Topmax  
       15h 20m ago
    如果密钥一定会泄露,那只在第一次显示可以极大缩减排查范围和可能的损失。
    Curtion
        5
    Curtion  
       15h 18m ago
    甚至有可能第二种是因为云端就没有存明文 key, 后续想查询也做不到了
    ntdll
        6
    ntdll  
       15h 9m ago
    第二种安全,指的是厂家安全。因为仅展示一次,比如过半年以后被盗刷,那几乎可以断定是用户保管不当。即使后续用户在平台侧的账号泄露,也不会造成这些 api key 的泄露,而要重置这些 api key ,厂家会触发二次验证。
    digitv
        7
    digitv  
       15h 8m ago   ❤️ 12
    只显示一次的都是假装为了安全甩锅的设计,现状就是用户很大可能不止使用一次 key ,这就导致只能自己保存,自己保存的风险远远大于平台保存。平台纯粹是懒政,想解决安全问题方法很多,最简单的加个二次验证就好了
    cloudzhou
        8
    cloudzhou  
       15h 8m ago
    这是安全策略,key 的重要性远高于账户,尤其是里面涉及资产,现在 token 就是资产
    举个例子,有一天账号体系被突破了( CSDN...),但是 key 拿不到,那么用户就很少了
    否则,很快的,token 都会被刷没,各种中转站
    Tink
        9
    Tink  
       15h 7m ago
    本站 api key 也是
    icanfork
        10
    icanfork  
       15h 6m ago
    这是合理的安全策略
    Tink
        11
    Tink  
       15h 6m ago   ❤️ 3
    这种动作最根本的原因是,让服务端尽量不保存(或无法还原)API Key 的明文
    chendy
        12
    chendy  
       14h 57m ago
    很常规的安全设计
    服务方一个 key 只显示一次,使用方一个 key 也只用于一个用途
    这样发生一些事故的时候比较容易定位和处理
    94
        13
    94  
       14h 55m ago
    所以为什么现在密码安全还是要推荐不同平台的账户不要用同一套账密呢。Secret Key 也是一样的道理。
    yidinghe
        14
    yidinghe  
    PRO
       14h 52m ago
    你考虑一下自己帐号被黑,如果可以无限复制,那你的 key 就都被盗了。如果只能复制一次,key 就不会因为帐号被黑而被盗。
    keenkiller
        15
    keenkiller  
       14h 50m ago
    防泄漏,后台数据库没存原始值
    maplezzz
        16
    maplezzz  
       14h 48m ago
    这单纯就是平台把泄露的风险责任推给个人
    belite
        17
    belite  
       14h 46m ago
    1. 减少攻击面,即便自己的数据库被拖库了,api 不会泄露
    2. 责任转移,以后有涉及 API 泄露的 与他无关,肯定是你的问题
    脱裤子 XX 是什么意思?不能提高安全性?
    Fistandantilus
        18
    Fistandantilus  
       14h 45m ago   ❤️ 2
    啊,你们 XX 的时候都不脱裤子吗
    xooass
        19
    xooass  
       14h 43m ago
    亚马逊的店铺 apikey 好像每 3 个月就要轮换一次
    paopjian
        20
    paopjian  
       14h 40m ago
    现用现取的策略在你嘴里就成 脱裤子 xx 了, 把一个最高权限秘钥串当做普通文本传来传去是一点安全意识没有啊
    yplam
        21
    yplam  
       14h 39m ago
    因为后台不存明文 API Key
    BornThisWay
        22
    BornThisWay  
       14h 37m ago
    合规而已 别想那么多
    账号泄露了 key 没泄露不能创建个新 key ?
    yanerweb
        23
    yanerweb  
    OP
       14h 33m ago
    为什么“阶跃星辰 step”等大模型后台,允许随时查看 API KEY 明码?为什么?
    shintendo
        24
    shintendo  
       14h 30m ago
    @cloudzhou 账号都突破了,不能建新 key 吗
    Tink
        25
    Tink  
       14h 28m ago
    @yanerweb 说明阶跃星辰服务端明文存了你的 key
    itskingname
        26
    itskingname  
       14h 25m ago   ❤️ 7
    假如账号泄露,黑客登录你的后台。然后疯狂消费。你发现账单异常。上来排查:

    对于阶跃这种,他们拿到了你正在使用的 key ,你上来停了这个 key 。你会面临两个问题:
    1. 同一个 key ,你不知道哪些钱是黑客消耗的,哪些钱是你自己正常生产环境消耗的。
    2. 你的所有生产环境都用的这个 key ,停掉以后,你的生产环境立刻就会挂掉。


    对于 ds 这种,黑客登录后台以后,只能重新创建一个 key 。你上来停掉这个新增的 key 。你的所有生产环境不受影响。只需要看这个新的 key ,你马上就能知道黑客消费了多少钱。
    cloudzhou
        27
    cloudzhou  
       14h 25m ago
    @shintendo 你这是好问题,如果一个系统曲线复杂,会引入不同 key 的限额等,创建的时候也应该有二次授权,其实查询的时候引入二次授权我也觉得可以,但是直接查看,在很多系统下都是尽量避免
    iorilu
        28
    iorilu  
       14h 14m ago
    这还要问, 当然有意义

    如果平台被黑客突破

    拿到了账户信息

    但是, key 没保存拿不到, 理论上你没什么损失

    如果给你 key 搞走了如果钱多的可能损失不小, 看你叫不叫
    ShineyWang
        29
    ShineyWang  
       14h 9m ago
    密码不明文保存,加盐
    用户服务和调接口的服务不是同一个

    防止数据库泄漏导致 key 泄漏;这样一方出问题不会影响另一方
    cookie 可能泄漏导致能上你后台,但是看不到 key;

    很多关键地方都有二次验证,这样即使 cookie 泄漏 不会导致资产损失

    除了 cookie 泄漏,用户如果用了有毒的油猴脚本;也会威胁用户资产;隔离开就安全多了
    jimrok
        30
    jimrok  
       14h 3m ago
    你可以耍赖告平台偷偷泄露了你 key 。1 那种可能讲不清楚,也许是你共享了你的账号造成的,也可能是他们客服给你泄露的。2.那种你怎么找理由说服是他们泄露了你的 key ?
    git00ll
        31
    git00ll  
       14 hrs ago
    @BornThisWay 创建新 key 时,可以触发更强的验证,比如盗取了 cookie 想要创建新 key 必须重新输入密码啥的
    SP00F
        32
    SP00F  
       13h 58m ago
    首次设置密码,以后就看不到的,实则脱裤子 XX

    又是招笑的来了,还是公式好用。😁
    zhuhaohenry
        33
    zhuhaohenry  
       13h 54m ago   ❤️ 1
    免责声明,如果泄露是你自己泄露的
    yanerweb
        34
    yanerweb  
    OP
       13h 51m ago
    贴上 claude sonnet 5.5 回答:
    你说的这个观察挺到位的,确实第 2 种的"安全感"有点形式大于实质。
    为什么第 2 种经常是"伪安全":
    1 、用户只会把 key 存到更多地方。 因为只能看一次,用户的第一反应是立刻粘到笔记、聊天记录、.env 、Git 仓库、飞书文档里。key 反而被扩散到了更多不受控的地方。
    2 、丢了只能重建,改动成本高。 一旦忘记保存,就得新建 key ,然后去每个调用方替换,很多人懒得换,就会"先留着旧的",形成 key 长期堆积。
    3 、真正的泄露风险不在控制台。 泄露大多来自代码仓库、日志、前端抓包、聊天截图,不是"有人偷看你的后台页面"。能登录你后台的人,本来就能新建、删除 key ,隐藏旧 key 防不了什么。
    4 、用户体验差。 多设备、多项目、团队协作时,每次都要重新生成,反而更容易乱。
    IvanLi127
        35
    IvanLi127  
       13h 42m ago
    这没那么复杂,人家后端压根不保存原始 key ,所以做不到再次回显。
    TimPeake
        36
    TimPeake  
       13h 34m ago   ❤️ 1
    确实 ,苦之久矣了。类似的 就像 linux 输入密码不会显示一样(听说这个问题要改了?),实际来说带来的收益远远低于便利性的收益。
    YangWaleed
        37
    YangWaleed  
       13h 27m ago   ❤️ 5
    @yanerweb
    第 2 种做法保护的是平台自己,就算平台被入侵了也不会泄漏,那 key 泄漏了只能是用户侧。

    而你这里列出的这些基本上都是用户视角,而且基本上也都是 “不好的使用习惯”。

    1. 平台能随时查看就不会有人把 key 存到其他地方了?笔记、聊天记录、Git 、飞书文档里别说 key 了,用户名密码都不少见
    2. 一个 key 一个用途,丢了也无所谓吧。一个 key 用在多个地方,泄露了你每个地方都要换反而更麻烦
    3. 同样的,多设备、多项目、多人共用,更容易泄露,泄露了影响更大

    所以你举的这些例子基本上都是使用习惯上的问题
    yxd19
        38
    yxd19  
       13h 21m ago
    @yanerweb 请不要在回答技术问题时复制粘贴 AI 生成的内容
    Marthemis
        39
    Marthemis  
       13h 19m ago
    你能承受丢失带来的后果,但是上头的部门 OR 监管不允许。
    G0dBlessMe
        40
    G0dBlessMe  
       13h 16m ago
    不像是“望京酒仙桥”全栈工程师问出来的问题
    yanerweb
        41
    yanerweb  
    OP
       13h 13m ago
    @yxd19 精准点题,如果我不写 AI 回答,你知道是 AI 内容
    Zarhani
        42
    Zarhani  
       13h 12m ago
    我都是把它们拷贝到 bitwarden 一份的
    docx
        43
    docx  
       13h 6m ago via iPhone
    热知识:GitHub PAT 也是只展示一次
    Y25tIGxpdmlk
        44
    Y25tIGxpdmlk  
       13h 2m ago   ❤️ 1
    @Tink #25 key 而已,又不是自己自定义的密码。咋就不能明文存储,又不是用这个 key 来端到端加密的,人家官方啥权限没有,难道还能盗取你的 key ,看你数据吗?
    crysislinux
        45
    crysislinux  
       13h 1m ago via Android
    服务提供方不保存明文,然后漏了就是你漏的。
    WaldenHorizon
        46
    WaldenHorizon  
       12h 54m ago
    防止你账号被盗或者公共场合登录忘了退出,或者网站数据库暴露,和用户密码都是加盐哈希不保存原文一样吧。考虑用户自己保存不安全更是可笑,网站随时能看 key ,用户就一定不保存了吗
    suitts
        47
    suitts  
       12h 51m ago
    风险转移
    LGZzzz
        48
    LGZzzz  
       12h 43m ago
    我觉得这两种方式没什么区别, 既然我都登陆上去回显 key, 那登陆上去我顺手重新生成一个也不是什么事了.
    LGZzzz
        49
    LGZzzz  
       12h 36m ago
    我觉得上面说的“保护的是平台自己,就算平台被入侵了也不会泄漏,那 key 泄漏了只能是用户侧”很有道理.
    如果平台被攻破, 流失的就不是你一个人的 key 了. 这个 key 本质上就像某个网站上的密码, 如果泄露了, 别人就会盗刷资产, 从平台的角度来看, 我先把泄漏影响最大的一面(自己被攻破了)这道防线做好,保证自己给用户生成的数量庞大的 key 不会泄漏.
    另外 op 贴上的 claude sonnet 5.5 回答,第一点我不是很认同. 登录上去重新生成一个 key 的成本并没有多少, 就是点一下, 输入一个名字, 点一个复制的问题. 登录上去看一下以前的 key, 也是点一下显示, 再点一下复制. 两个操作最麻烦的操作就是登录. 如果 key 能明码查看复制, 你并不能保证用户不会把 key 复制的到处都是. 上一条回复我已经说了, 既然你都能登录上去明码查看了, 那重新生成一个也不是什么很繁琐的事情. 就算可以明码复制, 用户依然会嫌麻烦, 然后把 key 复制的到处都是.
    LGZzzz
        50
    LGZzzz  
       12h 32m ago   ❤️ 2
    我在实际使用的时候, 每当我需要一个 key 的时候, 我都会重新生成, 并且给 key 输入名字的时候, 会写明这个 key 在什么地方使用(哪个设备, 哪个应用). 不能明码查看 key, 并且重新生成, 这种强制行为在某种程度上帮助我追踪不同应用, 不同地点, 不同设置, 我到底消耗了多少 token. 我并不觉得这是一个拖裤子 xx 的设计.
    1OF7G
        51
    1OF7G  
       12h 11m ago
    @itskingname 黑客:我先把你原来的删了,再自己建一个新的用。啊你发现了?那没事反正你服务崩了,嘻嘻。
    THESDZ
        52
    THESDZ  
       12h 10m ago
    减少攻击面是一个非常好的方式啊。一次性,永远不给前台和 api 暴露。少一个漏洞是一个
    fredweili
        53
    fredweili  
       12h 10m ago
    你就觉得要方便,不太懂普通用户在安全上有多蠢
    john1024
        54
    john1024  
       12h 8m ago
    @chendy 正解
    jonty
        55
    jonty  
       12h 7m ago
    @itskingname #26 黑客都能登录你后台了,你还能信任之前创建的 key ?
    interim
        56
    interim  
       11h 29m ago   ❤️ 1
    @yanerweb #34 不认同伪安全,你把 key 重复使用并且存在不同的地方导致的泄露本质是自己的安全习惯不好。正常是不同场景使用不同的 key ,即使泄露了,也能知道泄露源头并且快速禁用不影响其他场景正常使用,否则一个 key 泄露你需要动所有场景下使用的 key ,还找不到泄露源头。
    FringJX
        57
    FringJX  
       10h 37m ago
    更像是厂商鼓励你多创建 key ,而不是复制旧 key
    bowencool
        58
    bowencool  
       10h 28m ago   ❤️ 1
    重复利用 key 和多端共享 key 才是垃圾习惯,该改改了
    chenluo0429
        59
    chenluo0429  
       10h 11m ago via Android   ❤️ 5
    发帖是为了
    A. 寻找帮助和答案
    B. 发起讨论,扩展思路
    C. 寻找认同,说服每一个意见不同的人

    从 sonnet5.5 给你的回复看,你的问法就已经非常具有偏向性。AI 顺着你夸一夸,你还真当真了?
    询问 AI 的时候请中立,除非你就是打算拿 AI 答案来和别人吵架的。
    大模型平台生成 API KEY 有两种策略,一种是仅生成时可以查看一次,后续无法查看。另一种是可以随时解密查看的。请你综合对比两种策略,给出相应的分析对比,优缺点,适用场景。并给出你更推荐哪一种。
    lepig
        60
    lepig  
       10h 3m ago
    @digitv 说到非常好。
    现在都是单独搞一个单独口令的目录来存放这些密钥文本,就感觉很麻烦。
    他们这样做,
    1. 就是你说的甩锅,出了密钥泄露是用户的问题,因为平台不会保存你的密钥(单程序员都知道它肯定是要保存到后端的)。
    2. 是成本考虑。 对于腾讯/阿里这样的体量最简单的二次验证就是接收短信验证码,但是验证码要钱。量一大也是一笔不小的费用。
    unco020511
        61
    unco020511  
       9h 5m ago
    其实就是把安全风险转嫁给用户
    LXVC
        62
    LXVC  
       9h 1m ago
    @yidinghe 如果账号都被黑了,那黑客随意创建一个不就完了,为啥要用你之前的?
    YangWaleed
        63
    YangWaleed  
       8h 55m ago
    @LXVC 因为当你修改密码拿回账户后,你直接把黑客创建的那个 key 删了就行了。

    如果黑客能拿到你之前的 key ,那你就还得把所有用到这个 key 的地方全换了。
    更进一步,如果这个 key 你给多个设备、多个人共用,那这些设备和这些人都要全都替换一遍。
    这样看是不是影响更大?
    qiuhang
        64
    qiuhang  
       7h 53m ago
    自己为自己的密钥负责呗,厂家不存储。挺先进的密码学思路啊,有什么好困惑的。哪天厂商被拖库了,你的账号依然安全,这不是挺好的。
    MoozLee
        65
    MoozLee  
       7h 26m ago
    是的,对安全性没有太多的帮忙,主要就是责任丢给用户,后台不用明文存储
    tf2
        66
    tf2  
       7h 21m ago
    一个 key 只能用一次主要是记账方便啊。你复制来复制去的。到时候流量和账单算哪个头上都分不清了。
    iphoneXr
        67
    iphoneXr  
       7h 14m ago
    我倒是觉得云平台这种 apikey 禁止回显的方式很好!

    但是有些自托管平台 比如 1panel-ai-gateway 也是这样的方式,
    还限制 apikey 创建上限为 10 个就是有点 东施效颦了。
    JerryZhi
        68
    JerryZhi  
       6h 42m ago
    这就是厂商把风险转嫁给用户,纯甩锅。微软(也可能是谷歌)自己都写了篇文章说,要求用户定期修改密码并没有显著降低密码泄露风险,因为当每个平台都要求用户这样做,用户需要保护和记忆的密码数量很快就会超过脑容量,不得不使用最方便的办法将密码集中储存(无非是 txt 或者 excel 的区别),最终黑客还是只需要盗取一个密码文件即可爆掉一个人全部的账号
    JerryZhi
        69
    JerryZhi  
       6h 41m ago
    @JerryZhi 现在这种一次性 KEY 带来的用户行为是类似的
    zhy0216
        70
    zhy0216  
       6h 36m ago
    这个设计可以不用存 api key 到 db 的 只用存 apikey 的 md5 值
    然后一些特殊情况 比如如果云厂商被脱裤 用户可以不用换 api key
    ryd994
        71
    ryd994  
       4h 7m ago via Android
    @JerryZhi #68 脑容量爆就对了。人就是不应该用密码。passkey 了解一下? smartcard 了解一下?
    我们公司的电脑全都禁止密码登入的。只能用 smartcard 登入。
    smartcard pin 可以比密码简单得多是因为 smartcard 有物理隔离和限制重试次数两层防御。黑客首先要偷到你的 smartcard ,然后要在 3 次或者 5 次以内猜中你的 pin 。即使 6 位纯数字 pin 也几乎不可能。

    谷歌微软都是支持 passkey 登入的。
    yulon
        72
    yulon  
       3h 33m ago
    @Tink #25 这个 key 是服务器发给你的,你本来就应该假定服务器会有留存或是被中间人截取,既然用户都那么假定了,那么服务器再怎么密文都是无用功,只要能够追踪使用者和即时报废就行了
    jetsung
        73
    jetsung  
       2h 56m ago
    CloudFlare 也是如何设计的
    JinShu
        74
    JinShu  
       2h 39m ago
    外国人的思维策略,制造稀缺感
    studyrun
        75
    studyrun  
       1h 59m ago
    @yanerweb #41 说的是不要复制粘贴,你可以截图,人人都复制粘贴,这个站的 seo 就废了
    maolon
        76
    maolon  
       1h 54m ago
    你泄漏过一次就知道了,我之前的公司 aws 账号没管好,一个哥们的账号被偷了然后进了账号。

    如果不是一次性显示 key 的话进来的人就能把那哥们在用的都偷走了,最后只能偷开了几个 vm ,影响范围小得多。
    Tink
        77
    Tink  
       1h 46m ago
    @yulon #72 “你本来就应该假定服务器会有留存或是被中间人截取”,这个假定作为后端不成立
    lifanxi
        78
    lifanxi  
       1h 38m ago
    @lepig 为什么“程序员都知道肯定要保存到后端”?既然这样设计了,我就绝不会把明文存到后端。如果明文存到后端,我这设计安全评审就肯定过不去。
    scegg
        79
    scegg  
       1h 24m ago
    一般来说,这种设计会生成一个 key 和一个 pass 。这个 pass 的生成过程应该是在浏览器内完成的,全程不会离开浏览器,并只会给用户看一次。这个算法类似 Ed25519 。服务端只会保留 key 和一个算法生成的结果,这个结果无法反推出 pass 。pass 只会被用户保存。在使用时,服务端会产生 challenge_id ,由有 pass 的客户端在本地执行算法,将结果发回服务器,服务器即可认证此客户端是否真的拥有 pass 。
    ( 1 ) pass 全程不会离开客户机。pass 从未存放在服务器上,所以服务器也没有能力再给你看这个 pass 。
    ( 2 )如果出现 pass 泄露,那一定是用户责任。
    ( 3 )如果 pass 被盗用,服务方只要证明这个 pass 的算法生成结果在最近没有发生过变化,那么就可以免责。因为服务端和中间网络商都没有能力获取这个 pass 。
    RW5kZXJBdmFyaXRp
        80
    RW5kZXJBdmFyaXRp  
       53 mins ago
    举个例子:你生成了 20 个 key ,并且每日流水 200USD
    然后号被盗了
    我想白嫖模型,你说我是生成一个新 key 还是说每个 key 每天白嫖 2usd
    x86
        81
    x86  
       52 mins ago
    你号被别人登了复制了你的 key 就明白了,日常耗一点你根本没法察觉吧
    About   ·   Help   ·   Advertise   ·   Blog   ·   API   ·   FAQ   ·   Privacy   ·   Solana   ·   1288 Online   Highest 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 148ms · UTC 17:20 · PVG 01:20 · LAX 10:20 · JFK 13:20
    ♥ Do have faith in what you're doing.