G
G
GoldFox20152020-07-06 02:31:27
PHP
GoldFox2015, 2020-07-06 02:31:27

How to implement competent PHP authorization?

There was a serious question on protection at authorization. At the moment, I threw in the following authorization skeleton:


1. After clicking on the authorization button, create a session and cookies.
2. We enter the user id into the session, we enter the specially generated hash and user id into the cookies.
3. Next, save the hash in the database.
4. After authorization, we check the hash against the database and id from the session, if they are equal = we give access. If the id does not match the hash, or the hash matches the id, then we don't grant access.


Is this implementation correct?

Answer the question

In order to leave comments, you need to log in

3 answer(s)
A
Andrey, 2020-07-06
@andreyk0

You can store id, user zone in cookies, the encryption password itself is irreversible encryption with salt and ip in the same format. When you access any page, you get everything you need. When you change ip, clear the cache and throw a form on the login. ☕

A
alpeg, 2020-07-06
@alpeg

Competent authorization is done like this:
We generate a token, put it in cookies for the user and write it to the database. When the request came, we check if the token is active, and if it is rotten, if everything is OK, we give access, if not, we send it for authorization.
The session is by the way optional. And, well, another token, for CSRF. its also just in cookies.
and here and there cookies are secure + httpOnly.
Everything else is a variation on a theme. It is not recommended to fence your bikes because they always lead to holes.
Session, so as not to pull the database every time - it is possible, but at the same time it is necessary to program the ability to forcibly log out an evil user who has already been deleted from the database or access has been denied, and the session is still alive.
A specially generated hash is a bad idea, just a completely random token.
Encrypting password and stuff in a cookie is a very bad idea, forget it.
Encrypt userid and rights - only in the form of JWT, do not fence your bike, do not give eternal and long tokens (let them update, this is mandatory).

S
Stalker_RED, 2020-07-06
@Stalker_RED

1. After clicking on the authorization button, create a session and cookies.
you can create a session earlier
2. We enter the user id into the session
OK
... in cookies we enter a specially generated hash and user id.

why? Extra potential vulnerability.
3. Next, save the hash in the database.
What for?
4. After authorization, we check the hash against the database and id from the session, if they are equal = we give access. If the id does not match the hash, or the hash matches the id, then we don't grant access.
Why compare? It is assumed that an attacker hosts your server and changes data in sessions?

Didn't find what you were looking for?

Ask your question

Ask a Question

731 491 924 answers to any question