Basics of string based protocol security

Question

I wasn't sure how to phrase this question, so apologies in advance if it's a duplicate of something else.

I wanted to sanity check how I've secured my twisted based application and think I've done a good job at it, but it's been over a decade since I've written anything that uses raw or managed sockets.

Authentication transaction: Client connects and immediately a challenge response is sent back with a 16 character hex string. Client side takes user name & password, password is converted sha1( salt + sha1(password)) and credentials are sent back to the server as { username, password }. On the server side, authentication does standard lookup pattern ( if user exists and has password equal to input then grant ).

If the connection between user & client is lost, the protocol class marks itself as dirty and disconnects itself from the user object. Any time after this point, to get access to the user object again, the client would have to repeat the authentication process with a new salt.

Am I missing something? Is there a better/more secure approach for a character stream based protocol?

Answer 1

Your authentication seems solid but prone to man in the middle attacks as it does not ensure the integrity of the connection to the server.

I'd suggest to implement the SRP 6 protocol instead. It is proven to be secure, ensures the integrity of the connection and even creates a common secret that can be used to establish some form symmetric encryption. The protocol looks a bit difficult at first sight but is actually quite easy to implement. There is also a JavaScript Demo available on the project website and links to several implementations in different languages.

Answer 2

The protocol you described addresses one attack, that is the a replay attack. However, you are very vulnerable to MITM attacks. The TCP connection won't drop when the attacker moves in on the protocol. Further more anything transferred over this system can be sniffed. If you are on the wireless at a cafe everyone in the area will be able to sniff everything that is transmitted and then MITM the authenticated session. Another point is that sha1() is proven to be insecure you should use sha256 for anything security related.

NEVER REINVENT THE WHEEL, especially when it comes to security.

Use SSL! Everyone uses SSL and it has a LONG history of proven secuirty, and that is something you can't build. SSL Not only solved Man in the Middle Attacks but you can also use Certificates instead of passwords to authenticate both client and server which makes you immune to brute force. The sun will burn out before an attacker can brute force a 2048bit RSA certificate. Father more you don't have to worry about an eve dropper sniffing the transmission.

Keep in mind that OpenSSL is FREE, generating certificates is FREE, and the singing of certificates is FREE. Although the only reason why you would want to sign a certificate is if you want to implement a PKI, which is probably not necessary. The client can have the server's public key hard coded to verify the connection. The server could have a database of client public keys. This system would be self contained and not require OCSP or CRL or any other part of a Public Key Infrastructure.