我已经实现了一个像这样工作的身份验证系统：
成功登录后，服务器获取客户端的用户名并使用 AES-256 对其进行加密。
这个密文存储在客户端的浏览器中，当客户端想要做一些需要登录的事情时，这个密文被发送到服务器。服务端对密文进行解密，得到登录客户端的用户名。
攻击者无法破坏客户的帐户，因为他/她不知道加密密钥，因此攻击者是否知道用户名并不重要。但是，我担心如果客户端的浏览器被暴露，攻击者将同时访问密文和纯文本（用户名）。鉴于密文和明文都是已知的，这是否允许攻击者“计算”加密密钥？因为该密钥用于所有客户端，所以如果它被暴露，整个系统就会被破坏。
在回答您的主要问题时，据我们所知，在可预见的未来，AES256 是安全的。但是，您的身份验证方案有几个缺点。
首先，如果发送令牌的任何请求遭到破坏，或者如果用户安装了可以从浏览器中获取加密用户名的恶意插件，则该帐户将永远无法使用。您实际上是在创建一个用于身份验证的令牌，该令牌永远无法更改，并且与用户名是 1:1 的关系。如果被入侵，拒绝访问的唯一方法是关闭帐户并强制用户使用不同的用户名创建新帐户。
更好的方法是在用户进行身份验证时生成一个随机令牌并将其存储在数据库中，或者生成一个随机值并将其加密为令牌。然后，如果帐户被盗或用户希望“退出”，您可以删除该令牌并生成一个新令牌。
如果您的加密密钥被泄露或以某种方式被破解，攻击者可以像您系统中的任何用户一样做任何事情。使用基于随机令牌的方法，他们必须知道用于为每个用户生成令牌的随机部分。攻击者必须有权访问您的数据库和您的加密密钥。
不可以。攻击者无法从明文和密文中获取加密密钥，因为 AES 可以抵抗已知明文攻击。请参阅Crypto SE 的答案中的详细信息。
我建议你检查你的设计。将用户名保密会导致许多问题。例如，如果用户需要报告问题，如果是机密，用户如何告诉用户名？如果管理员需要更改用户权限，如果用户名是秘密的，那么负责人如何告诉管理员需要更改哪些用户？等等。我建议不要加密用户名。
所以实际上我们这里有一个 XY 问题。实际上，应该使用身份验证令牌来了解用户的实际身份。在这种情况下，不需要对用户名进行加密，因此不需要关于 AES 和已知明文攻击的问题。
问“为什么”是不好的形式。
有大量免费的、开源的、久经考验的身份验证系统。
除非您是加密工程方面的专家（而且我们在这里的事实并非如此），否则请不要发明您自己的系统。
只是为了自学而弄乱代码是很好的，但不要更进一步。
AES 对于已知明文攻击 (KPA) 是安全的，在这种攻击中，攻击者可以同时访问明文和密文。AES 可以承受超过 20 年的攻击，而 AES-256 是黄金标准，即使 AES-256 也可以击败 Grover 的最优搜索算法的 Quantum 攻击。在可预见的未来，即使是AES-128 也是安全的——除了多目标攻击。
正如您所注意到的，您的身份验证方案不安全。您应该使用