\chapter{Encryption for communication}
Data need to be encrypted. Otherwise, anyone who hacks to the communication system or spying on the internet gate would be able to get what you just said to your colleague.

Even worse, if you are a boss of a company. you definitely don't wanna leak your secret of running a business. Because it'll about billions of dollars or more loss of you.

\section{Level One: HTTPS}
By simply transferring the password through the network without any protection is not safe. Anyone who has the network physical access has the chance to steal your user's password.

That's why we need to use HTTPS\cite{https}.

As long as we can assure the communication device in our hands is safe, we can assure that the HTTPS level encryption was safe.

HTTPS is made for protecting the packet transferring levels safety.


\section{Level Two: Sha256}
But what if the communication device in our hands is not safe, what if the data that stored in our device can be read by any application that we have installed? That can be a big problem.

And even more, what if a hacker hacks to the server computer?

It can be a disaster for saving our user's password in plain text at the server or local device.

In this case, I would like to introduce my own way of encrypting the user's password: use sha256 \cite{sha256}.
    
    
\subsection{What the server needs to do}
\begin{enumerate}
    \item Define a user data structure
        \begin{lstlisting}
{
    username:,
    sha256_password:,
    temp_token:,
}
        \end{lstlisting}
    \item Whenever a user logged in, we give the user a temp-token, the token is a random string.
    \item Whenever a user wants to send or receive a message, he must provide the temp-token that the server gave him before.
    \item Any transmission should work under https, and the password should be a hash string of real passwords.
\end{enumerate}


\subsection{What the client needs to do}
\begin{enumerate}
    \item Get the sha256 code of its password. Add some salt would be better. ('Salt' refers to a random string, which can make it more difficult for hackers to crack)
        \begin{lstlisting}
import hashlib
m = hashlib.sha256()
m.update(b"password")
print(m.hexdigest())
        \end{lstlisting}
    \item Send its username and hashed password to the server to get a temporary token.
    \item Communicate with the server with that temporary token, so the server would know it is him.
\end{enumerate}


\subsection{Server.py}
\lstinputlisting[language=Python]{data/codes/8/user_management.py}


\subsection{Client.py}
\lstinputlisting[language=Python]{data/codes/8/test_user_management.py}


\subsection{Conclusion}
After the above operations, we can successfully authenticate users without worrying about data leakage, because of neither the local-side nor the server-side stores any plaintext passwords. Even if the hacker gets the sha256-password, they still can’t calculate the real password, nor treat the sha256-password as the replacement of real password, because we added salt.

And if the hacker got all data at the server, all we have to do is change a server, change the salt, verify our user by email address, then move on, everything would be fine.

Why use email for account recovery? Because the email is managed by a third-party, the hacker can't get access to it. (Or it is unlikely that a hacker could also hack a third-party email system at the same time)

After a data leak, some companies would like to ask its user to change their password. it's not necessary. 