I understand that there is a lot of information on authorization on the Internet, but still I will decide to ask one question. What are the key points you can not do while making registration on your site? Authorization through sessions. Asking this question, I look forward to the answer about here in this form:

  1. Password in the database stored in encrypted form.
  2. When logging in, save login time, IP, etc.
  3. Validation is not logged in / not only as isset ($ _ SESSION ['username']), but .. And by the way, how to do it?

PS No, I was not banned in the search engines, but I want to hear in words what needs to be done, and not understand the tons of someone else's code, wondering why it is needed ..
Thank you. ^^

UPD: nevertheless, who can briefly answer the question, how can a beginner, but, I hope, a promising project implement authorization on the site?

UPD: the question is closed due to the lack of new entries. I hope someone will emphasize from all these discussions something useful for themselves)

  • And there will be many visitors? And what server? Do you plan to install additional servers? This is what I mean by “Authorization through sessions.”. With several servers, it is no longer a ride, which means that another method is needed - the one that will be in step 3. And immediately the problem (or solution?) According to claim 2. How are you going to exchange information between servers? This, of course, if a bunch of people will be. Or a site just for study? All the same, then it will be necessary to do it as it should, but you don’t know how to do it; Maybe you should immediately pay attention to this? - BOPOH
  • one
    Now I didn’t quite understand it. Suppose a person entered, the database recorded what the login was. And how to continue to allow only this person to perform actions. The key to give him some? And where to store it? In the cookie? - sinedsem
  • one
    The session ID is stored in cookies. By which the server finds out what kind of user it is. Mechanism of sessions on php has file character. And the session mechanism through DB, can be configured by storing it in the server’s memory, which is incomparably faster and better. - istem
  • one
    Immediately in sight the newbies poured)) - Yoharny Babai
  • 2
    @ Yoharny Babai, but what didn’t like the question? As I understand, plus the question set, if it deserves attention. IMHO the question is formulated normally and in the presence of competent, detailed answers, a topic may be useful for many newbies (and maybe not only). Is the accumulation of such a "knowledge base" not the goal of this forum? So I added this question, wanting to draw attention to it (although, as a result, as a result, only comments). - avp

2 answers 2

Let me, for the time being, try to summarize what we have done, and then how it will turn out, maybe someone will provide us with another option ..
So, let's go, some general conclusions:

  1. Logging in with sessions is not good , as it will not work if the site is physically located on several servers (I don’t know myself, but @BOPOH said so ). Accordingly, if we expect that our site will be loved by thousands of people, we must immediately choose another way.
  2. Based on the first, we begin to look for another implementation. So there are a lot of options, options with DB and memcache were offered. (Again VORON). I decided for myself what I’m going to do now through the database, simply because for me at the moment it’s easier (I’m just starting to comprehend the basics of the web-dev).
  3. How to make authorization through a DB? Obviously, the algorithm simplified to a minimum is as follows: The user enters a username and password, the password is compared with the password on the server, if they are the same, the current login is entered into a special table. So far I don’t know exactly which data will be needed, but I think it will be: IP address of the user, login time , unique key of this session (from now on I will use this word in the meaning of "the process of user’s stay on the site in a logged in state" $ _SESSION has nothing to do with it). The same key will be stored in cookies . Further, when loading each page, the browser will access the server using this key, and from there return the login information.
  4. Now about safety . Naturally, the password itself cannot be stored in the database, but only its hash, that is, a string encrypted with a certain algorithm (preferably without the possibility of decryption), should be stored. The most common example is the md5 () function. It is only desirable to use it in this form: md5 ($ pass. $ Salt), since there are a bunch of decoder sites for regular md5 lines. Further, with the words @avp : the key must be recalculated independently by the server and the client at each exchange. And the server compares the key sent by the client with the expected one. Also for important information hash password can not be sent over the network. And yet, it is advisable to somehow check that the server from which you received the picture on the screen is not a setup . The decision on the need to use these tips, as well as the methods of implementation will be left to you, dear developers. For myself I will choose the first two points (my and the first point @avp ).

Complete me)

  • 1. I, in turn, appeal to my more experienced comrades, especially to our architect. I don’t know why they don’t like the session mechanism (even through the database, although they know about it), but apparently there are some difficulties. For my part, I don’t know how the sessions will behave through the database if the database fails. Maybe this is what stops my more experienced comrades. 2. Memcache does not guarantee the preservation of data, so it should be considered only as a last resort. 3. Why cookies? They can also be disabled. If the pages are generated by the server, then this AUTH can be added to each link. - BOPOH
  • about the second: it seems to me wrong, because if the address line fails, all authorization will go to hell .. - sinedsem
  • The parser broke my numbering ... 3. (continued) If the pages are almost a monolithic application, and the server has additional functionality, then AUTH can be transmitted through the POST parameters, and not through links, we have done so. 4. if cookies are stolen - access is still possible, even in a short period of time, you can’t do anything with it ... The same is true for the rest - if the data is intercepted, then you can create a stranger - "your server". You can also hack RSA. Therefore, re-authentication is necessary for important actions - BOPOH
  • > Cookies can be disabled, and they can not even go to the site at all ...> For my part, I don’t know how the sessions will behave through the database if the database fails. in most cases, the failure of the database leads to the failure of the site’s functionality, so it’s not normal. Sessions are normal, you can make a falback authorization server that accurately receives tokens from other servers (priority), to do tokens replication. keep for this nosql base. @ Are your experienced team mates familiar with google and facebook authorization systems? there is an authorization token (and not one), by the way, which is essentially a session. - zb '
  • the fact that the server is not set up - ssl can in principle authorize via ssl, but if there are thousands of users, then I do not advise. - zb '

(I'm just starting to comprehend the basics of the webdevice)

If you are a novice web developer, I advise you not to bother with all possible session handlers.

Use the standard work sessions (via cookies). In case cookies are disabled, then PHP itself will change the behavior of the session (via the GET parameter).

Directly about your question: 1. From a security point of view, it is better to keep the password encrypted. But with this approach, if the user forgets the password, you will not be able to remind him of his old password. you will have to generate a new one. 2. When logging in, save any information you need .. It can be not only time and ip, but also the referer (ie, from which site the user came to your site) There are no restrictions, only your flight of fantasy)) 3 For most cases, verification is enough

if(isset($_SESSION['is_auth']) and $_SESSION['is_auth'])...

Over time, when you "grow up" in terms of programming, you can look at how authentication is done with the "big ones" .. For example, Security Component in Symfony

  • I have such a check now, but it seems to me not quite reliable .. am I right? - sinedsem
  • quite reliable for most cases ..;) - draev