Return to Question

I need to communicate over an insecure TCP sockets where SSL/TLS is not available. Does the following solution provide a secure means of authentication and encryption?

-

1. Client sends: username
2. Server generates a random token (31 bytes).
3. Server retrieves a password salt and hash (bcrypt) from the database for the given username.
4. Server encrypts the random token by the password hash.
5. Client receives: passwordSalt + encryptAes(token, passwordHash)
6. Client gets the passwordHash by using bcrypt on the password and the received password salt.
7. Client gets the token by decrypting the encrypted token with the password hash.
8. Client generates a random 'validation' salt (15 bytes).
9. Client generates a hash of the token using the validation salt and encrypts it with the token.
10. Client sends: encryptAes(validationSalt + md5(token + validationSalt), token)
11. Server gets the hash by decrypting it with the token.
12. Server compares if the received hash is equal to md5(token). If they are the same, the client has authenticated.
13. Server generates a hash of the password hash using the validation salt, pads it with 15 random bytes, and encrypts it with the token.
14. Client receives: encryptAes(randomBytes(15) + md5(passwordHash + validationSalt), token)
15. Client gets the hash by decrypting it with the token.
16. Client compares the hash with md5(passwordHash + validationSalt). If they are the same, the server has authenticated.

All data will now be encrypted with the token generated by the server.

-

The server is in Java, the clients are in C++ (UE4).

Public key encryption is currently not available.

-

Is there any flaw or weakness in this solution?

I need to communicate over insecure TCP sockets where SSL/TLS is not available. Does the following solution provide a secure means of authentication and encryption?

-

1. Client sends: username
2. Server generates a random token (31 bytes).
3. Server retrieves a password salt and hash (bcrypt) from the database for the given username.
4. Server encrypts the random token by the password hash.
5. Client receives: passwordSalt + encryptAes(token, passwordHash)
6. Client gets the passwordHash by using bcrypt on the password and the received password salt.
7. Client gets the token by decrypting the encrypted token with the password hash.
8. Client generates a random 'validation' salt (15 bytes).
9. Client generates a hash of the token using the validation salt and encrypts it with the token.
10. Client sends: encryptAes(validationSalt + md5(token + validationSalt), token)
11. Server gets the hash by decrypting it with the token.
12. Server compares if the received hash is equal to md5(token). If they are the same, the client has authenticated.
13. Server generates a hash of the password hash using the validation salt, pads it with 15 random bytes, and encrypts it with the token.
14. Client receives: encryptAes(randomBytes(15) + md5(passwordHash + validationSalt), token)
15. Client gets the hash by decrypting it with the token.
16. Client compares the hash with md5(passwordHash + validationSalt). If they are the same, the server has authenticated.

All data will now be encrypted with the token generated by the server.

-

The server is in Java, the clients are in C++ (UE4).

Public key encryption is currently not available.

-

Is there any flaw or weakness in this solution?

I need to communicate over an insecure TCP sockets where SSL/TLS is not available. Does the following solution provide a secure means of authentication and encryption?

-

v1:

1. Client sends: username
2. Server generates a random token (31 bytes).
3. Server retrieves a password salt and hash (bcrypt) from the database for the given username.
4. Server encrypts the random token by the password hash.
5. Client receives: passwordSalt + encryptAes(token, passwordHash)
6. Client gets the passwordHash by using bcrypt on the password and the received password salt.
7. Client gets the token by decrypting the encrypted token with the password hash.
8. Client generates a random 'validation' salt (15 bytes).
9. Client generates a hash of the token using the validation salt and encrypts it with the token.
10. Client sends: encryptAes(validationSalt + bcrypt(token, validationSalt), token)
11. Server gets the hash by decrypting it with the token.
12. Server compares if the received hash is equal to bcrypt(token, validationSalt). If they are the same, the client has authenticated.
13. Server generates a hash of the password hash using the validation salt and encrypts it with the token.
14. Client receives: encryptAes(bcrypt(passwordHash, validationSalt), token)
15. Client gets the hash by decrypting it with the token.
16. Client compares the hash with bcrypt(passwordHash, validationSalt). If they are the same, the server has authenticated.

All data will now be encrypted with the token generated by the server.

-

v2: (changed unnecessary bcrypts to md5, for improved performance)

1. Client sends: username
2. Server generates a random token (31 bytes).
3. Server retrieves a password salt and hash (bcrypt) from the database for the given username.
4. Server encrypts the random token by the password hash.
5. Client receives: passwordSalt + encryptAes(token, passwordHash)
6. Client gets the passwordHash by using bcrypt on the password and the received password salt.
7. Client gets the token by decrypting the encrypted token with the password hash.
8. Client generates a random 'validation' salt (15 bytes).
9. Client generates a hash of the token using the validation salt and encrypts it with the token.
10. Client sends: encryptAes(validationSalt + md5(token + validationSalt), token)
11. Server gets the hash by decrypting it with the token.
12. Server compares if the received hash is equal to md5(token). If they are the same, the client has authenticated.
13. Server generates a hash of the password hash using the validation salt and encrypts it with the token.
14. Client receives: encryptAes(md5(passwordHash + validationSalt), token)
15. Client gets the hash by decrypting it with the token.
16. Client compares the hash with md5(passwordHash + validationSalt). If they are the same, the server has authenticated.

All data will now be encrypted with the token generated by the server.

-

The server is in Java, the clients are in C++ (UE4).

Public key encryption is currently not available.

-

Is there any flaw or weakness in this solution?

I need to communicate over an insecure TCP sockets where SSL/TLS is not available. Does the following solution provide a secure means of authentication and encryption?

-

1. Client sends: username
2. Server generates a random token (31 bytes).
3. Server retrieves a password salt and hash (bcrypt) from the database for the given username.
4. Server encrypts the random token by the password hash.
5. Client receives: passwordSalt + encryptAes(token, passwordHash)
6. Client gets the passwordHash by using bcrypt on the password and the received password salt.
7. Client gets the token by decrypting the encrypted token with the password hash.
8. Client generates a random 'validation' salt (15 bytes).
9. Client generates a hash of the token using the validation salt and encrypts it with the token.
10. Client sends: encryptAes(validationSalt + md5(token + validationSalt), token)
11. Server gets the hash by decrypting it with the token.
12. Server compares if the received hash is equal to md5(token). If they are the same, the client has authenticated.
13. Server generates a hash of the password hash using the validation salt, pads it with 15 random bytes, and encrypts it with the token.
14. Client receives: encryptAes(randomBytes(15) + md5(passwordHash + validationSalt), token)
15. Client gets the hash by decrypting it with the token.
16. Client compares the hash with md5(passwordHash + validationSalt). If they are the same, the server has authenticated.

All data will now be encrypted with the token generated by the server.

-

The server is in Java, the clients are in C++ (UE4).

Public key encryption is currently not available.

-

Is there any flaw or weakness in this solution?

I need to communicate over an insecure TCP sockets where SSL/TLS is not available. Does the following solution provide a secure means of authentication and encryption?

-

v1:

1. Client sends: username
2. Server generates a random token (30 bytes).
3. Server retrieves a password salt and hash (bcrypt) from the database for the given username.
4. Server encrypts the random token by the password hash.
5. Client receives: passwordSalt + encryptAes(token, passwordHash)
6. Client gets the passwordHash by using bcrypt on the password and the received password salt.
7. Client gets the token by decrypting the encrypted token with the password hash.
8. Client generates a random 'validation' salt (16 bytes).
9. Client generates a hash of the token using the validation salt and encrypts it with the token.
10. Client sends: encryptAes(validationSalt + bcrypt(token, validationSalt), token)
11. Server gets the hash by decrypting it with the token.
12. Server compares if the received hash is equal to bcrypt(token, validationSalt). If they are the same, the client has authenticated.
13. Server generates a hash of the password hash using the validation salt and encrypts it with the token.
14. Client receives: encryptAes(bcrypt(passwordHash, validationSalt), token)
15. Client gets the hash by decrypting it with the token.
16. Client compares the hash with bcrypt(passwordHash, validationSalt). If they are the same, the server has authenticated.

All data will now be encrypted with the token generated by the server.

-

v2: (changed unnecessary bcrypts to md5, for improved performance)

1. Client sends: username
2. Server generates a random token (30 bytes).
3. Server retrieves a password salt and hash (bcrypt) from the database for the given username.
4. Server encrypts the random token by the password hash.
5. Client receives: passwordSalt + encryptAes(token, passwordHash)
6. Client gets the passwordHash by using bcrypt on the password and the received password salt.
7. Client gets the token by decrypting the encrypted token with the password hash.
8. Client generates a random 'validation' salt (16 bytes).
9. Client generates a hash of the token using the validation salt and encrypts it with the token.
10. Client sends: encryptAes(validationSalt + md5(token + validationSalt), token)
11. Server gets the hash by decrypting it with the token.
12. Server compares if the received hash is equal to md5(token). If they are the same, the client has authenticated.
13. Server generates a hash of the password hash using the validation salt and encrypts it with the token.
14. Client receives: encryptAes(md5(passwordHash + validationSalt), token)
15. Client gets the hash by decrypting it with the token.
16. Client compares the hash with md5(passwordHash + validationSalt). If they are the same, the server has authenticated.

All data will now be encrypted with the token generated by the server.

-

The server is in Java, the clients are in C++ (UE4).

Public key encryption is currently not available.

-

Is there any flaw or weakness in this solution?

I need to communicate over an insecure TCP sockets where SSL/TLS is not available. Does the following solution provide a secure means of authentication and encryption?

-

v1:

1. Client sends: username
2. Server generates a random token (31 bytes).
3. Server retrieves a password salt and hash (bcrypt) from the database for the given username.
4. Server encrypts the random token by the password hash.
5. Client receives: passwordSalt + encryptAes(token, passwordHash)
6. Client gets the passwordHash by using bcrypt on the password and the received password salt.
7. Client gets the token by decrypting the encrypted token with the password hash.
8. Client generates a random 'validation' salt (15 bytes).
9. Client generates a hash of the token using the validation salt and encrypts it with the token.
10. Client sends: encryptAes(validationSalt + bcrypt(token, validationSalt), token)
11. Server gets the hash by decrypting it with the token.
12. Server compares if the received hash is equal to bcrypt(token, validationSalt). If they are the same, the client has authenticated.
13. Server generates a hash of the password hash using the validation salt and encrypts it with the token.
14. Client receives: encryptAes(bcrypt(passwordHash, validationSalt), token)
15. Client gets the hash by decrypting it with the token.
16. Client compares the hash with bcrypt(passwordHash, validationSalt). If they are the same, the server has authenticated.

All data will now be encrypted with the token generated by the server.

-

v2: (changed unnecessary bcrypts to md5, for improved performance)

1. Client sends: username
2. Server generates a random token (31 bytes).
3. Server retrieves a password salt and hash (bcrypt) from the database for the given username.
4. Server encrypts the random token by the password hash.
5. Client receives: passwordSalt + encryptAes(token, passwordHash)
6. Client gets the passwordHash by using bcrypt on the password and the received password salt.
7. Client gets the token by decrypting the encrypted token with the password hash.
8. Client generates a random 'validation' salt (15 bytes).
9. Client generates a hash of the token using the validation salt and encrypts it with the token.
10. Client sends: encryptAes(validationSalt + md5(token + validationSalt), token)
11. Server gets the hash by decrypting it with the token.
12. Server compares if the received hash is equal to md5(token). If they are the same, the client has authenticated.
13. Server generates a hash of the password hash using the validation salt and encrypts it with the token.
14. Client receives: encryptAes(md5(passwordHash + validationSalt), token)
15. Client gets the hash by decrypting it with the token.
16. Client compares the hash with md5(passwordHash + validationSalt). If they are the same, the server has authenticated.

All data will now be encrypted with the token generated by the server.

-

The server is in Java, the clients are in C++ (UE4).

Public key encryption is currently not available.

-

Is there any flaw or weakness in this solution?