0

Excuse me for question name, but I couldn't find any other suitable title.

I want to validate client connecting to the server. My algorithm looks like that:

  1. Clients sends his login - plaintext
  2. Server sends random big integer AES encrypted with password corresponding to the login
  3. Client decrypt number using his password and sends his password encrypted with the same number for confirmation
  4. Server decrypts password using the same number and checks if it's valid.

Possible eavesdropper might know the password encrypted with integer and the same number encrypted with his password, and here is my question. Is that a possible threat? Is it possible to find password or the number?

What may I do to improve this solution?

Disa
  • 306
  • 2
  • 8

4 Answers4

6

Unfortunately you are doing it wrong by rolling your own cryptopgrahy scheme.

What may I do to improve this solution?

Do not roll your own scheme. Stick to the tried and tested solution for authentication. Use TLS/SSL to encrypt the traffic from the client to your server. Use a strong password hashing algorithm like PBKDF2, bcrypt or scrypt to hash the password for storage on the server.

  • @Disa what is your point? To only use standard, well-publicized and tested solutions? That is exactly what Terry said. – AviD Dec 23 '13 at 12:03
  • 1
    Posting isn't the problem, creating your own custom algorithm *is* the problem. – AviD Dec 23 '13 at 12:35
  • 1
    There's a sort of [canonical answer](http://security.stackexchange.com/a/2210/13239) regarding rolling one's own. – Jonathan Garber Dec 23 '13 at 14:26
1

There is a point of weakness in your algorithm because it is based on the hypothesis the server has all clients cleartext password.

There is a second point of weakness in your algorithm at the starting stage. When a client doesn't yet have a password, the server can't send a random integer crypted with the client password. This implies that this initial password is a preshared known one, known from both the server and the incoming client.

For these 2 reasons (at least), it was a good idea to have exposed your scheme…

and not to have used it ☺.

dan
  • 3,033
  • 14
  • 34
1

What you describe is very similar to the idea behind Kerberos, but it stops short of actually solving the problems Kerberos solves.

Knowing both AES(A,B) and AES(B,A) would certainly help an attacker by allowing them to authoritatively test for a valid decryption; if they knew neither, but found some candidates for A,B with m1=AES(A,B), they could test that AES(B,A)=m2 where m2 is the other intercepted message. However, this is really the least of your worries.

AES keys have to be a particular length. You haven't mentioned how your key derivation works, so I won't talk about that.

Really, the correct model for doing this kind of thing is to derive a key from the user's password on the client node. The server knows a key that can be used to encrypt data such that the client can decrypt it, and on request creates an authentication token which it sends to the requester thus encrypted. The token is useless to anyone who doesn't know the user's (private) key, so it's safe to send to whoever. The user then decrypts it and is authenticated.

The user doesn't need to immediately send this token back; the server can assume whoever can present it is authenticated as the user it was issued for.

Now, I'll solve some other problems by adding to the model: the thing sent from the server to the client is not a token, but another key. The user, provided they can decrypt the key, can use that key to sign requests. That way, nothing sensitive has to traverse the network in the clear and there isn't even much need for establishing a trusted channel.

Kerberos takes this a step further by allowing this key to be used to issue still more keys, and has some other concepts, which allow a user to sign in one place to authenticate to another. There are also some nonces to prevent replay attacks, and stuff. However, so far as your solution deviates from this model, it is suboptimal.

The highlight here is that you don't want the plaintext password anywhere, least of all on the server, and you really don't need to be sending it across the network or verifying it. But, instead of redesigning your system to match, just use one of the numerous challenge-response authentication methods already implemented and audited and available.

Attacks against your scheme are possible, but what attacks in particular depends on whether your token (the big number you refer to) is properly treated as an nonce, how big it is, how you derive keys from passwords (and nonces), how you treat the password on the server, how the nonce is generated, and some other things. The primary line of attack I would choose is to predict the nonce and use that to decrypt the password, validating against the traffic in the other direction.

Falcon Momot
  • 1,140
  • 6
  • 15
1

Here, for this scenario you can use asymmetric cryptography like RSA.

Now as per your problem, if you use same integer for encryption and decryption, accidently any eavesdropper comes to know, it will be a security issue.

So you can improve by using following way.

  1. Clients sends his login - plaintext
  2. Sever create private public key pair and send 1 of the key to client key exchange protocol, and will encrypt message by the key which is not shared by him and send it to client.
  3. As client receives any encrypted message it will be decrypted by the key which already send by server to him.
  4. In same way client encrypt message either by generating new pair or by using existing pair (recommended new pair) and send it to server.

The issue is this scenario is Man-In-Middle Attack so you should have proper security implementations for such things for solving Man-In-Middle Attack you can read this article.

But to solve your primary issue you should use Asymmetric cryptography

Community
  • 1
Rohit
  • 216
  • 2
  • 6