Home/ Questions/Q 8035463
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-05T02:19:08+00:00

For educational purposes I’m implementing a simple remote shell program, and I’m trying to

  • 0

For educational purposes I’m implementing a simple remote shell program, and I’m trying to wrap my head around how to make it somewhat secure. The first idea I had was to just require a password. If the client sends the password, it runs, if not, it quits. Then, I applied a simple hash function to the password, but I don’t think this really makes it any more secure. In either case, if the packets are intercepted, an attacker could just extract the password or the hashed password. What can I do to make this more secure Is there a way to use password/hashing that is safe from basic packet interception? I know that ssh uses public/private keys to encrypt and decrypt, but that is more advanced than I need.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    How about a challenge/response with digests? Say the server knows the password is "blah".

    The client connects, and authenticates:

    • Client: Let me in!

    • Server: I give you the challenge "12345", a number I generated just now!

      Server remembers that they gave the client "12345".

    • Client wants to authenticate with "blah", so they add it to the end of the server’s challenge, and then calculates the SHA-1 of the result "12345blah".

      Client: My response is "6910972fb3148a63df7fda34bd6fccf3013d8d93"!

    • Server knows the password is "blah", and issued the challenge "12345" to this client—hence it calculates the SHA-1 of "12345blah", and produces "6910972fb3148a63df7fda34bd6fccf3013d8d93". This matches the client’s response so …

      Server: Access granted!

    Important notes:

    • The server MUST be the one to choose the challenge. If the client gets to pick, then an attacker could just intercept one authentication attempt, and repeat the same challenge and response as that valid user.

      The fact that the server picks a different challenge every time means an attacker can’t replay authentication. This means the server needs to store the challenge against the client’s connection or session somehow, since you’ll need it when they respond.

    • You may want to use something stronger than SHA-1 (it’s a little broken IIRC). You may also want to do something other than just appending the password to the challenge, as the security properties depend on the underlying digest function.

    • I demonstrate this with a password "blah", but the nice thing is now, you can replace "blah" with the hash of "blah". The server never needs to store more than the hash, and then the client just hashes their password first before combining with the challenge and calculating the digest.

    • 0