Answer the question
In order to leave comments, you need to log in
How secure are cookies against theft?
The site has a login system. I decided to give up passwords for the sake of security. On the authorization page there is a field for entering email. When you enter an email and send a request to the server, a confirmation code is sent to this email, which is a 6-digit number. The user is redirected to a page with an input field where a confirmation code is required. If the user enters an incorrect code, then the authorization key is not issued to him and the page asks to enter the code again. If someone enters the wrong code more than 10 times, then the account is blocked. If the code is entered correctly, two situations are possible. If the user did not check the Remember me box on the authorization page, then an object of the User class is stored in the session, through which you can get all the user data that is needed to use the site (id, email, etc.). Generally, the user is authorized, but after the browser is closed, the session will be destroyed. If a user checks the Remember me box on the page with authorization, then in addition to the session, an additional authorization key is stored in the cookie file. Why is it needed? It is needed for authorization after the session is destroyed. The authorization key is a confirmation code (sent to the mail), which, using concatenation, is glued together with a salt string (it is not stored on the server, no one knows the value). The salt is needed so that a third-party user does not manually create cookies with an authorization key that they just picked up (without salt, the key is just a number, it will take seconds to pick it up). Next, the glued string is encrypted using irreversible encryption. This key is stored in the database (in the user's cell) and in the cookie file. Now, after the browser is closed, the session will be destroyed, and the cookie with the key will remain. Further, when entering the site, on each page of the site, the hash is extracted from the cookie file and compared with the hash in the database of each user. If one of the users has the same hash, then the device with the cookie is given a session with the user's data, after which the user is authorized. Also, a cookie is needed for the Sign out from all devices function, upon activation of which the authorization key is deleted from the database. After that, as soon as the user with the cookie containing the access key refreshes the page, the function of comparing the key in the database and the key in the cookie is activated. If the keys do not match, then the user session is deleted (the account is logged out). Reauthorization required. The problem with the system is that if a third-party user receives a cookie with an authorization key, then he will gain access to the account. This raises the question, how secure are cookies against theft?
Answer the question
In order to leave comments, you need to log in
Not at all protected. Any stealer, even for $10, has the function of stealing cookies.
It is not entirely clear why such crutches with a key from the code that will come to the post office. Isn't it possible to just generate random bytes of the corresponding function in php?
Irreversible encryption is not encryption, but hashing.
Why lock your acc because of 10 wrong codes? Then any student who sniffed it will be able to ban any account on your site. How to avoid it? 1. Do not give information about whether the user is registered with such soap or not. 2. Hang captcha for entering the code. This almost completely protects against auto-selection. And it is better to make a code not only of 6 digits. You can increase its length. At least up to 8 digits. And it is even better to write letters there too.
To avoid stealing cookies, you need to do a couple of simple things.
1. Start using at least a self-written semblance of a normal token system. Look at JWT. There is a refresh and an access token. The access token lifetime should be set short. It is better that it was no more than 5 minutes. Since the logs from stealers and other rubbish are not checked immediately.
2. Store tokens not only in cookies. There is also localstorage. But there is already someone on what much. Someone makes not 2 tokens, but 3 or more. Consider an example with 4 tokens. 2 tokens for refresh and 2 tokens for access. One of the pair is stored in cookies on httponly, and the second token is stored in localstorage. During operations, both tokens are presented. Thus, by stealing only cookies, the attacker will not achieve anything. And it is also desirable to look not only at the tokens, but also at other details. For example, user-agent and IP address. The abrupt change of both in one session is rather strange. Yes, this is easily bypassed, but not every malware provides for this. Not every ordinary warrior is able to organize some kind of proxy through the victim's computer.
In general, this topic is rather difficult and it is better to stick to what has already been invented and successfully used.
Read about JWT. You can look at this https://deworker.pro/edu/series/http-basics/authen...
You can also use ready-made solutions in frameworks in your language.
Didn't find what you were looking for?
Ask your questionAsk a Question
731 491 924 answers to any question