Scribd
Upload
4 views1 page

Client-Server Authentication Protocols

The document outlines a problem set focused on implementing user registration and authentication protocols for a UDP-based client-server architecture. Teams of up to two people must submit their work by May 13th, 2025, with penalties for late submissions. Key tasks include handling user sign-up and sign-in requests, securely storing credentials, and managing client authorization based on their IP address and port.

Uploaded by

m.erd2001gfb
Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
4 views1 page

Client-Server Authentication Protocols

The document outlines a problem set focused on implementing user registration and authentication protocols for a UDP-based client-server architecture. Teams of up to two people must submit their work by May 13th, 2025, with penalties for late submissions. Key tasks include handling user sign-up and sign-in requests, securely storing credentials, and managing client authorization based on their IP address and port.

Uploaded by

m.erd2001gfb
Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd

Problem Set 2: Client – Server Communication

You can submit your work as a team (at most 2 people). Write down the names of the people in
your team.

Due date: 11:59PM, May 13th, 2025.

Late submissions will result in a 10% penalty per day (e.g., 2.5 days late result in 25% penalty)

TASK Description:
You will implement user registration (sign-up) and authentication (sign-in) protocols to securely
identify clients to the server. This must be integrated into the existing UDP-based client-server
architecture from Part 1.

1. Sign-Up:
• Clients must be able to register a new user account by sending a SIGNUP request with a
chosen username and password.
• The server must store user credentials securely in memory or a local file (you can use
hashed passwords).
• If a username already exists, the server must reject the request.
2. Sign-In:
• Clients must send a SIGNIN request with a valid username and password.
• If credentials are correct, the server should mark the client as authenticated and allow
them to continue using the messaging features from Part 1.
• Clients that have not signed in must not be allowed to send MESSAGE packets.
3. Authorization Handling:
• The server must keep track of authenticated clients based on their IP address and port.
• Clients must be re-validated after each restart (no persistent sessions).
Message Types and Format:
The following new message types should be supported:

SIGNUP:<username>:<password> From client to server. Used to create a new user.


SIGNIN:<username>:<password> From client to server. Used to authenticate.
SIGNUP_OK / SIGNUP_FAIL:<reason> From server to client. Acknowledgement of registration.
SIGNIN_OK / SIGNIN_FAIL:<reason> From server to client. Acknowledgement of
authentication.

Server should still support GREETING and MESSAGE, but only from authenticated clients.

Note: Before coding, describe (in 3–5 bullet points) your authentication protocol flow. Include
who sends what message when, and how failures are handled. Submit this with your code.

You might also like