regardless of the JWT and SESSION mechanisms, let me discuss the issue of network security. It may be wrong. You are welcome to correct it.
suppose your computer is now insecure, and Trojans are installed on your computer, and there is also a middleman in the gateway:
- No matter whether your web page is encrypted or not, any data you enter on the keyboard will be monitored by the Trojan horse, which is listening at the operating system layer.
- the requests you type in the web page and the responses you receive will be intercepted by the middleman through the gateway, which is monitored by the routing layer.
therefore, the encryption password must be hashed rather than symmetrically encrypted; otherwise, since the middleman can intercept all requests and responses, and js is plaintext, how can you ensure that the key of symmetric encryption will not be seen by the middleman?
you may ask that the encrypted password will also be seen, and the middleman can bypass the web page and send a simulated request directly. Yes, it is; encrypting passwords is designed to keep your password from being disclosed in clear text, so that the middleman cannot use your account password to hit the library in other applications.
but the hash algorithm cannot be used in the main content of the transmission, because both parties must know the specific content, which causes the middleman to see the contents of the plaintext; (simple JS symmetric encryption is useless because the HTML is plaintext, and the middleman can also see the symmetric encryption key)
HTTPS solves the problem of symmetric encryption, prepares the certificate in advance, and prevents the middleman from forging the certificate through the pre-installed root certificate of the browser, which fundamentally solves the secret key problem of symmetric encryption.
and JWT I think that fundamentally, it is not to solve the web security problem, but to solve the server-side SESSION problem in a distributed and stateless way.
as long as I intercept your encrypted value, it can still be used.
suppose your account is ABCDE, encrypted and EDCBA,. I don't need to decrypt your account at all. I just need to pass the encrypted value to your backend to get permission.
as you say, it was intercepted. Any encryption at the front end is useless.
token has been intercepted, just like your QQ and password have been given to someone else, then ask how to prevent others from logging in to my account?
unplug its network cable
has previously used a front-end encryption, which I hope will be useful to you. After the front end directly encrypts the password value entered by the user using md5, val=md5 (value); Passing the value of val to the background will solve your problem. There are no restrictions on using other encryption methods
"if the request is blocked, the user can get the account password"
the password is encrypted before it is sent, the password stored at the backend is encrypted, and the backend cannot decrypt the password, and there is no need for
to be intercepted with the password. It's your own business to divulge. The server only needs to verify that the password conforms to the rules. As long as the authentication rules are correct, the user
is recognized as to what kind of non-matching encryption.
- https should be a simple and effective method.
- if you do not solve the problem of eavesdropping on the transmission, then you must solve the problem of "replay"
for example, if you encrypt your password with md5 and then transmit it, someone else can intercept your md5 password and replay it. Even if your password is not only md5 encrypted, but also wrapped in asymmetric encryption, others will also intercept your final encryption result to replay.
the user's password is unchanged. How to make a "password" valid only once is the key idea to solve the problem of replay. Generally, you can experiment with the blacklist and whitelist, and you can try it yourself.
in addition, when using JWT after a successful login, note that JWT must have a judgment of "valid time". Otherwise, once jwt is intercepted and stolen, it will remain valid until you change secret
.
token is intercepted. If you get the token, you can't crack the token without key. Jwt is only here to show the user's identity information, and generally does not put the password information into it. The client handles it in an insecure way
.
