Introduction
这是这一系列作业的最后一部分了，这部分包括用户账户管理以及安全的实现，此外还有一些杂项和收尾工作。
User Accounts & Basic Security
Now it is time to add persistence to your server by creating user accounts. The user can then login and out of the server using a password. The server must be modified to contain a shared resource which holds user account information. Additionally, the login protocol must be updated to allow for account validation, eg. passwords.
You will replace the login protocol from Part I with the account login protocol.
Password Criteria
Passwords must meet the following criteria to be valid:
- Must be at least 5 characters in length
- Must contain at least 1 uppercase character
- Must contain at least 1 symbol character
- Must contain at least 1 number character
Example: Cool320!
When the user types in the password, use the gctpass function so the password is not displayed as it is typed.
Server
Usage updated:
./server [-hv] PORT_NUMBER MOTD [ACCOUNTS_FILE]
-h Displays help menu & returns EXIT_SUCCESS.
-v Verbose print all incoming and outgoing protocol verbs & content.
PORT_NUMBER Port number to listen on.
MOTD Message to display to the client when they connect.
ACCOUNTS_FILE File containing username and password data to be loaded upon execution.
The server will request a password when a user attempts to log in. Also, it will create a new password for new users when they identify themselves upon login. There should now be two data structures central to your program: a Users list and an Accounts list. The Users list is a list of the users currently logged into the server. The Accounts list is the persistent list of users and their passwords loaded and saved to a file on the server’s execution and termination respectively. If an accounts file is provided on the command line, your server should load this file into the accounts list upon start-up. If no file is provided, the server should start with no existing accounts.
Do not use an array for either of these data structures, it MUST be an extendable format such as a linked list within your server program.
Added Server Command
/accts
When /accts is typed into the server’s terminal it should dump a list of all user accounts and information. This printout should be similarly formatted to the output of the /users command.
Client
To add user authentication we will modify the client program to take an additional argument for creating a new user on the server. When the optional -c argument is included, the client will attempt to create a new user on the server. If the argument is not provided, the client will attempt to login to the server as an existing user with an account.
Usage updated:
./client [-hcv] NAME SERVER_IP SERVER_PORT
-h Displays this help menu, and returns EXIT_SUCCESS.
-c Requests to server to create a new user
-v Verbose print all incoming and outgoing protocol verbs content.
NAME This is the username to display when chatting.
SERVER_IP The ipaddress of the server to connect to.
SERVER_PORT The port to connect to.
User Authentication Protocol
The protocol for logging into the server will now additionally include user creation. We will introduce new verbs IAMNEW, HINEW, NEWPASS.
Remember when the client prompts the user to enter their password, use the getpass function so the password is not displayed as it typed.
Once a user account has been established with the server, on subsequent client connections the user must be validated. We will introduce new verbs AUTH, HINEW, NEWPASS.
User Authentication
Since you will be storing sensitive information, such as passwords, we should employ techniques to help protect the users login information. It is always bad practice to store an actual user password in your database, even if it is encrypted. Instead you should store a 1-way crytographic hash of the password. When a user attempts to login, the password is sent over the network, and is hashed by the server. Then the server will compare the stored hashed value with the hash value it just generated. If they are the same then the user is authenticated. If it is not, then authentication fails.
This of course only protects against attacks which dump the database. Its still possible for someone to intercept the plaintext password over the network, but this out of scope for this assignment.
Even though a hash should be a 1-way function, it is possible to reverse/crack a hash eventually with enough computation power and time. If a hash can be cracked quickly, this is bad because if multiple users in your database have the same password, then they will have the same hash. So once you crack that password for one user you crack that password for all users with the same password. This compounds for an attacker since many users use the same password over multiple user accounts. Say for example, that you use the same password for google and the 320 webform. If the password gets stolen from the 320 webform because we have bad security practices, the attacker can now compromise the google account by simply just testing to see if that password works.
To help defend against a cracked password compromising everyone else’s password, you should add what is called a salt to your account’s password before hashing it. This salt should be a value generated by a random function which is considered cryptographically secure.
Upon the creation of a new account you should generate the salt and store it in your authentication database. Then when you perform the hash, you should append the salt to the password before hashing. This will result in the same password being hashed differently for each user.
The combination of forcing the user to select a strong password, hashing, and salting will give you the time to alert your users of a possible breach and allow them to act accordingly.
Use the hash function sha256 available in openssl/sha.h
Install openssl and openssl-dev
sudo apt-get install openssl libssl-dev
Use the rand to generate the salt available in openssl/rand.h
Although not required for the assignment, you can still go one step further and do key streching to help defend against brute force attacks, by making the cracking process take more time.
You must use a shared resource, plaintext file or database (see extra credit) for storing the salt and hash per user.
Error Code Table
The following lists the error codes and associated messages.
| ERR Code | Message |
|---|---|
| 00 | USER NAME TAKEN |
| 01 | USER NOT AVAILABLE |
| 02 | BAD PASSWORD |
| 100 | INTERNAL SERVER ERROR |
The default error message should be used for any other conditions which were not characterized.
Extra Credit
- (15-20 pts) Create a user interface for the client and chat using ncurses. The points allocated will depend on the complexity of interface. Impress us, nothing trivial. You must not interfere with the assignment functionality and implementation.
- (10 pts) Make your server run on the OSX platform.
- (5 pts) Create the ability on the client to display the chat history per each user to user chat. When a chat window opens, display all previous messages exchanged before accepting new messages.
- (5 pts) Use sqlite3 to store the user information for authentication.
- (2 pts) Customize your xterm chat windows. Impress us, nothing trivial.