AES加密与;安全漏洞 [英] AES encryption & security flaw

问题描述

的检查更新＃1 的

Check update#1

这逻辑是对认证过程的候选人，通过简单的HTTP请求完成的：

This logic is a candidate for a authentication procedure, done by simple HTTP requests:

• 我要送：用户名+ encrypted_userName（encrypted_userName实际上是用户名的加密结果，使用AES和放大器进行;如关键我使用的密码的MD5哈希值）。注意：我不发送的MD5哈希密码

我比较服务器上的
• ：encrypted_userName与own_encrypted_userName（因为在服务器上我有机会在用户完全的信息，我计算自己encrypted_userName）

问：这是一个安全漏洞？说坏家伙抓住了完整的HTTP请求，他可以从这个2的相关信息提取密码？

Question: is this a security flaw? Say bad guy captures full HTTP request, can he extract password from this 2 infos?

code的详细信息，如果需要的话：

CODE DETAILS, if needed:

private static Cipher getCipher(String key, int mode) throws Exception{
     byte[] rawKey = getRawKey(key.getBytes("UTF-8"));
     SecretKeySpec skeySpec = new SecretKeySpec(rawKey, "AES");
     Key key2 = skeySpec;
     Cipher cipher = Cipher.getInstance("AES/ECB/PKCS5PADDING");
     cipher.init(mode, key2);
     return cipher;
}

private static byte[] getRawKey(byte[] seed) throws Exception {
/*  BEFORE:
     KeyGenerator kgen = KeyGenerator.getInstance("AES");
     SecureRandom sr = SecureRandom.getInstance("SHA1PRNG");
     sr.setSeed(seed);
     kgen.init(128, sr); // 192 and 256 bits may not be available
     SecretKey skey = kgen.generateKey();
     byte[] raw = skey.getEncoded();
*/
     byte[] raw = MD5Util.getMD5HashRaw(seed);
     return raw;
}

（注意：我之所以用密码的哈希值是code是平台（客户端Android设备）之间的兼容，而注释版本是不是）

(NOTE: reason why i use the hash of the password is that code is compatible among platforms (client is Android device), while the commented version is NOT)

简短的回答：

presented逻辑并不甚至接近被认为是安全的身份验证mecanism
（为什么？检查迈克尔的回答波纹管）

Presented logic is not even close to be considered a secure authentication mecanism (for Why? check Michael's answer bellow)

决定使用Kerberos （而不是HTTPS的，因为我不熟悉+看似复杂设置）：

Decided to use Kerberos (AND not https, since I am not familiar + seems complicated to setup):

这是不支持Kerberos的真实版本（如V4或V5），这只是我自己的实现，以便让称它为​​使用Kerberos类似的（我知道，我知道：不要滚你自己的加密！ ）

It is not a true version of Kerberos (like v4 or v5), it is just my own implementation so lets call it "similar with Kerberos" (I know, I know: DONT "roll your own encryption"!!!),

下面是一些细节：

• 它适用于UDP（现在）



• 认证做一次，方法是：

• it works on UDP (now)

• authentication is done only once, by:

• 客户端发送一个验证器消息（包含：[用户id]以纯文本和放大器; something_ecrypted]与[entered_user_password（有curently [something_ecrypted]只包含时间戳，称之为[authenticator_creation_timestamp））注意：密码不上发射


• 在接收到消息服务器，tryies解密[something_ecrypted]与[actual_user_password] - >如果良好的话，客户是谁是pretends是，所以我把他送回一个OK响应（如Kerberos的这个响应包含一些东西，就像一个[PUBLIC_KEY（RSA密钥，但USER_PASSWORD加密）+授予票证（称之为[TGT]，只有通过服务器已知的密码进行加密，目前它doenst到期，这[TGT]也包含了一些的东西，这样的2个时间戳：[TGT_creation_time_stamp] + [authenticator_creation_timestamp]（在认证消息中收到的））


• 收到此确定消息后，客户端已采购了一个有效的[PUBLIC_KEY] ..这么好看！

• client sending a Authenticator message (contains: [userId] in plain text & [something_ecrypted] with [entered_user_password] (curently [something_ecrypted] contains just a timestamp, call it [authenticator_creation_timestamp])) NOTE: password is not transmited
• server upon receiving message, tryies to decrypt the [something_ecrypted] with [actual_user_password] -> if SUCCESS then client is who it pretends to be, so i send him back a OK response (as in Kerberos this response contains some stuff, like a [public_key] (a RSA key, but encrypted with user_password) + ticket granting ticket (call it [TGT], encrypted with a password known only by server, currently it doenst expire, this [TGT] also contains some stuff, like these 2 timestamps: [TGT_creation_time_stamp] + [authenticator_creation_timestamp] (the one received in the Authenticator message))
• after receiving this OK message, client has procured a valid [public_key].. so nice!

保护agains重放攻击不是100％的保证，但我看到它的安全足够多的

protection agains "reply attack" is not a 100% guarantee, but I see it "safe enought":

• 在每下一个HTTP reaquest，我附上页眉这2名男子[new_request_creation_timestamp]（带有[PUBLIC_KEY]加密，上述采购）+的[TGT（不变，如上面所收到）



• 在服务器上我只需要验证[new_request_creation_timestamp] agains一些数学（明显[TGT]必须是有效的太）：

• on each next HTTP reaquest, i attach as headers these 2 guys [new_request_creation_timestamp] (encrypted with [public_key], procured above) + the [TGT] (untouched, as received above)

• on server I just need to validate [new_request_creation_timestamp] agains some math (obvious [TGT] needs to be valid too):

**我希望下面的变量几乎等于

** i expect that the following variables to be almost equal

DELTA1 = [TGT_creation_time_stamp] - [authenticator_creation_timestamp]

delta1 = [TGT_creation_time_stamp] - [authenticator_creation_timestamp]

DELTA2 = NOW（） - [new_request_creation_timestamp]

delta2 = now()-[new_request_creation_timestamp]

（其实我可以5秒它们之间的区别，但是从我的测试中，它只是一些10-20米利斯的问题，

(I actually allow a difference between them of 5 seconds, but from my tests, its just a matter of some 10-20 millis,

**所以初始delta（创建，以验证器OK响应时计算）应延续旁边的互动。

** So initial delta (calculated when creating OK response to Authenticator) should perpetuate on next interactions.

我觉得这种新方法很值得信赖的，但如果你有意见或看到一个BUG逻辑，请分享..谢谢

I do find this new approach quite trust-worthy, but if you have an opinion or see a BUG in logic, please share.. Thanks

推荐答案

是的，这是一个弱安全机制。

Yes, this is a weak security mechanism.

1. 任何人谁捕获发送到服务器的信息可以很容易地重播自己（重放攻击）进行身份验证。

1. Anyone who captures the information sent to the server can easily replay it to authenticate themselves (replay attack).

这很容易受到离线口令猜测 - 人谁（通过加密使用每个哈希观察到的用户名捕获发送到服务器，然后可以非常迅速地测试一个密码列表找到你的用户选择什么样的密码信息反过来密码）。哈希甚至可以pcomputed $ P $，进一步上升加快了进攻。

It is vulnerable to offline password guessing - anyone who captures the information sent to the server can then very quickly test a password list to find what password your user has chosen (by encrypting the observed username using the hash of each password in turn). The hashing can even be precomputed, speeding the attack up further.

基于密码的身份验证协议应该是抗重放攻击和离线密码猜测攻击。

Password based authentication protocols should be resistant to replay attacks and offline password guessing attacks.

只需使用HTTPS（TLS）连接到服务器并发送明文用户名和密码，通常会是一个更好的解决方案。

Simply using an HTTPS (TLS) connection to your server and sending the username and password in plaintext would normally be a better solution.

在响应您的更新1：

• 我强烈建议使用HTTPS。它无处不在使用是有原因的 - 它已经发生了巨大的安全审查和被认为是（主要）安全的 - 远远超过你可以通过一个SO后得到更好


• 我还没有考虑您的更新方案彻底，但因为它是基于Kerberos它也受到离线口令猜测攻击，因为我上面描述。


• 已经成功通过身份验证，不要忘了，然后实际上保护您的数据 - 你可能需要派生一个共享的对称密钥，然后使用您的数据...
验证+加密

这篇关于AES加密与;安全漏洞的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！