When the user log in via the frontend, the login and password are sent in clear (I will recommand the use of HTTPS). The backend will try to connect to the database, if it's successful, it will encrypt the login and password using MD5 && SALT, and return them to the frontend.
互联网服务离不开用户认证。一般流程是下面这样。
1、用户向服务器发送用户名和密码。
2、服务器验证通过后，在当前对话（session）里面保存相关数据，比如用户角色、登录时间等等。
3、服务器向用户返回一个 session_id，写入用户的 Cookie。
4、用户随后的每一次请求，都会通过 Cookie，将 session_id 传回服务器。
5、服务器收到 session_id，找到前期保存的数据，由此得知用户的身份。
有些时候会看到有网页把密码先在前端加密后再发送给服务器，感觉这个操作意义其实不大。想象一下如果加密后的数据在传输的时候被窃听了，那窃听者在伪装成用户的时候，把这个字符串同样地发送给后端，是不是还是可以达到欺骗的效果。换句话讲，对后端服务器而言，无论传输过来的密码实际上是否有进行加密，都只是它后续操作的原文而已。
一、加密
我们先不谈加密，而是先纠正一个误区，有些朋友会认为 Base64 可以加密，甚至有 Base64 加密的说法。
Base64 主要不是加密，它主要的用途是把二进制数据序列转化为 ASCII 字符序列，用以数据传输。二进制数据是什么呢？计算机上存储的所有数据，都是二进制数据。
Base64 最常见的应用场景是 URL，因为 URL 只能是特定的一些 ASCII 字符。这时需要用到 Base64 编码，当然这也只是对二进制数据本身的编码，编码后的数据里面可能包含 +/= 等符号，真正放到 URL 里面时候，还需要URL-Encoding，变成 %XX 模式，以消除这些符号的歧义。其次就是将图片转为 Base64 的字符串。
因此，Base64 只是一种编码方式，而不是加密方式。
好了，现在回到我们的主题，先说登录和注册之间的关系，这 3 个模块需要做什么事情呢？
· 注册：将用户输入的隐私数据，发送给服务器，服务器进行保存；
· 登录：将用户输入的隐私数据，发送给服务器，服务器进行比对，确认是否有权限登录；
· token：确保用户在登录中；
我们把用户输入的隐私数据再具象一些，比如账号和密码，结合我们上面提到的安全原则，那么分解开来，实际我们要做以下几件事：
· 服务器-注册接口：接收客户端传来的账号和密码，将其保存在数据库中；
· 服务器-登录接口：接收客户端传来的账号和密码，与数据库比对，完全命中则登录成功，否则登录失败；
o 登录成功后，生成或更新 token 和过期时间，保存在数据库， token 返回给客户端；
o 服务器定期清除 token；
· 客户端-注册模块：向服务器注册接口发送账号和密码；
· 客户端-登录模块：向服务器登录接口发送账号和密码；
o 登录成功后，保存 token 到本地；
o 退出登录后，清除 token；
· 发送的账号和密码需要加密；
· 数据库中需要保存的是加密后的账号和密码；
· 请求敏感数据时，将客户端传来的 token 和服务器验证，不通过则提示客户端登录；
剩下的无非是加密算法的不同，我最常用的是 md5，那么我们经过 md5 加密以后，其实还是不太安全，为什么呢？因为 md5 本身就不安全。虽然 md5 是不可逆的 hash 算法，反向算出来虽然困难，但是如果反向查询，密码设置的简单，也很容易被攻破。
比如我们使用 md5 加密一个密码 123456，对应的 md5 是 e10adc3949ba59abbe56e057f20f883e，找到一个 md5 解密的网站，比如 cmd5.com/，很容易就被破解了密码…
二、加盐
加盐，如果是固定盐值就不优雅了，我接触到的是用来保存用户密码，每次修改都会随机一个盐值.随机的盐值与密码不可逆编码保存到数据库。盐值是为了提高不可逆编码后密码被批量碰撞解开的难度。
三、HTTPS
总而言之，Web 前端发送密码等数据给服务器这个阶段的传输安全，应该由 HTTPS 协议保证，而不需要提前对某些值应用加密算法。