• PHP Help

  • Writing a basic user authentication/login system

Hello there everyone!

I would like to write a basic user login/authentication system and just need a bit better understanding prior to getting started. For a persistent login system, it seems I want a cookie that stores an identifier upon successful login. That cookie can get checked on any visit, even if the session has died and get the new session ID to attribute to the user for that visit.

I have some ideas for later use, like binding to an IP, obfuscating the cookie's data but I want to make sure I understand the basic underpinnings of a login system that lives on past PHP's session.

Am I misunderstanding how the system works or am I missing something basic that needs to be factored in?

Thanks for your time!

    Pretty much that.

    The cookie itself doesn't need to store any data per se; since you'll need to store user-identifiable stuff server-side anyway (to check the cookie request), you can store the cookie data there as well. At which point the cookie itself conveys no information beyond its existence and distinctiveness. A thoroughly random value (possibly hashed and salted with the username) is just as good for that as anything else would be since all it needs to do is compare equal to what has been stored for the user server-side. And more secure too, since it no longer by itself contains anything sensitive.

    Remember that a user may be logged in from several difference devices; each will have their own persistent cookie.

    Since there will also be a session cookie once login is successful, both should match.

    Once logged in, anything particularly sensitive should require the user to explicitly provide login details again.

    Are you concerned with cookie theft?

    Weedpacket Are you concerned with cookie theft?

    In this case, I'm not as the site is really not critical in any way. If the stakes were higher, is the solution pretty much just 2fa of some sort?

      schwim
      Well, you'd have a two-part cookie, both parts very random; one part stable and the other part changing after each successful login. If someone tried to log in with a cookie where the first part matched but the second didn't, it would indicate that either they're trying to use a stolen cookie that had already expired, or someone else used that first person's cookie while it was still good (and caused the legitimate owner's copy to go stale).

        Weedpacket I'm very sorry for the bother but could you give an example of how I would go about utilizing a two-cookie method? I think I understand the stable part, that would likely be what we already discussed with a hashed and salted user identifier but what would be the second cookie? Would that be a token that's created upon successful login and gets replaced with each subsequent successful login?

        If so, how would that keep someone from getting the two cookies instead of just the one and utilizing it to be logged in to the legitimate user's account? I can see that in my description, the second cookie would be useless when the legitimate user logged in again but in the event of grabbing the cookies and trying to use them right away would get them logged in, no?

        Would I use a binder, like an IP address or UA to destroy the cookie and make them log in again? If that's the case, it seems that this would work without the second cookie.

        I know for sure I'm missing something obvious but would greatly appreciate any added insight you could provide.

        Thanks for your time!

          schwim Would that be a token that's created upon successful login and gets replaced with each subsequent successful login?

          Yes.

          schwim but in the event of grabbing the cookies and trying to use them right away would get them logged in, no?

          It would, but at least the next attempt to log in (by the legitimate user) could raise a flag to alert them (have you ever been asked "There was a login attempt at .... - was this you?"). Which is why

          Weedpacket Once logged in, anything particularly sensitive should require the user to explicitly provide login details again.

          Remember, the attacker would not need to steal the cookie if they already have access to the user's device. No "Remember Me" functionality is going to prevent that attack.

                Weedpacket

                Do you think there would be a performance or usability impact by placing both values in one cookie instead of two separate cookies? In my mind, a single cookie would just carry both values separated by a pipe and then encrypted:

                username|token
                IbutP9byW2O5o23PQLo5DnPEqXh5+C0ooNlMS0GmCk0=

                then just decrypt and separate for use?

                It seems to me that the single cookie method would take more effort overall but just wonder if it's comparable use-wise to setting and retrieving data from two cookies.

                    Like I said; a two-part cookie. eWWQajpgNxVBNckdAutX28kuovPXGwrv455SkCDQRUnwcNwbunuSzqE5Z3IGLdB4. There are two parts there: each part consists of 24 random bytes base-64 encoded. The first part is therefore eWWQajpgNxVBNckdAutX28kuovPXGwrv and the second is 455SkCDQRUnwcNwbunuSzqE5Z3IGLdB4.

                    You could include a user identifier in that cookie as well. Not necessarily the username, since it would be hashed in the cookie. That would be an even more persistent component (because they're still the same user from one "Remember Me" to the next: remember that they might logged in on more than one device, and they might all have "Remember me" set). HvUVkw1DCT9+ZhlVsuhQcU9AfyzUSVygzwOiIQ==eWWQajpgNxVBNckdAutX28kuovPXGwrv455SkCDQRUnwcNwbunuSzqE5Z3IGLdB4.

                    Server-side, you'd have a cookies table; userid | useridhash | persistent | varying, and that cookie would be stored there as 42 | HvUVkw1DCT9+ZhlVsuhQcU9AfyzUSVygzwOiIQ== | eWWQajpgNxVBNckdAutX28kuovPXGwrv | 455SkCDQRUnwcNwbunuSzqE5Z3IGLdB4 as you'd be searching for particular parts.

                    Since you're storing the userid hash directly, you'd probably wish to salt it, rather than have user 42 identified by the hash of '42'.

                    Write a Reply...