Jump to content


  • Posts

  • Joined

  • Last visited

Profile Information

  • Gender
    Not Telling

mds1256's Achievements

Advanced Member

Advanced Member (4/5)



  1. Hi all I have been looking though loads of tutorials regarding log in method for websites (not APIs), and cant help find that they are outdated. So I am asking what is the correct way to create a log in system using php? Modern websites use JavaScript for asynchronous web requests so this requirement should also be catered for. APIs and mobile apps use access tokens which is very secure if implemented correctly. Can we use the token principle for websites? As the way I see it that most php log in systems use php sessions and they create a session and save some data in this session when the user successfully authenticates, however the session id is held in a cookie so if the cookie is stolen then they have access to your account. API access tokens are expired and refreshed periodically so is there such a implementation method for web sites too?
  2. Hi The front end is load balanced across servers so need to store session in db and not use php sessions
  3. Thanks but I don’t want to use php sessions, I just need a random unique string to use as an id. I think we have gotten off topic slightly.
  4. But I don't want to have a cookie at all, sessions also create a session file on the server......
  5. It is for a REST api and they should be stateless in respect of not sending cookies etc and I believe using php sessions generates a session on the server and sends a cookie?
  6. In the mysql sessions table I will be storing session data for a limited timeframe, (login sessions), these last no more than 1 hour max. There will be lots and lots of login sessions and I need to pass back a session ID to the client but not using an incremental number e.g. session id 1, session id 2, session id 3. I want to pass back a totally random session id, it also allows me to not worry about ever running out of numbers from auto increment (although using an unsigned bigint will give me over 18 quadrillion possible session address row ids). I will have a process that clears out stale sessions every hour.
  7. I don't mean in a traditional sense, they are more like a temporary identifier that I want to use instead of an auto increment INT in the database.
  8. I am trying to generate a unique ID that I can store in the database and use as a session ID. I could URLEncode but I have never seen session IDs with %20 etc in the ID.
  9. Hi Looking to create an ID which only contains alpha-numeric (no special chars). I looked to generate random bytes and then encode in base64 but base64 contains = + /. The below seems to do it but not sure if bin2hex can return non alpha numeric? bin2hex(openssl_random_pseudo_bytes(18));
  10. Thanks for the reply. I would always be storing them in the database. Each time the user logs in they get a new session (they can just resume a session if they haven’t logged out), so they way I have it is that each session has its own refresh token. Then when the access token has expired for that session it uses the refresh token for that session to generate a new access token (and refresh token as well). however if a users session is dormant for 15 days and they try to resume a session then the refresh token has expired so they will need to fully log in again. so do I need to hash the token values in the database when I store them or can they just be left as plain text as they both have a limited lifetime anyway?
  11. Hi Is it necessary to hash stored access and refresh tokens that are stored in a database. Both these tokens have limited lifespan (access token - 20 minutes but refresh token is 14 days). The reason I ask is I have hashed the tokens using the password_hash function but a user can have multiple active sessions if they want (so there is a sessions table with user id (not username), access token, token expiry date/time, refresh token and refresh token expiry date/time. So in order to refresh the access token I have to do a look up to see which session it relates to, what I have found is that I must retrieve all rows where the refresh token hasn't expired and then run password_verify against the tokens stored with the tokens provided to check each session to see if they match. What I have found is that it takes a while to run the password_verify function (by design I think) for each row (could be many if the users has been silly and logged in lots of time) which would cause an unacceptable delay when calling an API with an access token that needs refreshing (my tests resulted in times upwards of 30 seconds for a user who has around 10 active sessions). If both tokens were not hashed the same action to refresh a token for a user who has 10 active sessions takes less than a second which is much more acceptable.
  12. Hi It is an authorisation token which is sent to the user once (when they login and then only when it expires and they get a new token after it has refreshed). a Worked example might be: User auth token: cb1d797808ad9cd9a67e6657398b9199 with an expiry of 15 minutes and has only just logged in The brute forcer is currently running an ongoing incremental attempt and is up to cb1d797808ad9cd9a67e6657398b9191 - (8 more attempts to get to a valid token) So because it will get to the correct value in 8 more goes which takes seconds to try then it will stumble upon a valid token which they can then use for another 10 or so minutes.
  13. Yeah but if the brute force attack was just changing the access token incrementally then it 'may' stumble upon a working token value?
  14. I am working on a simple authentication system and something has came to light regarding the access token and potential brute force. For the access token there is an expiry date/time where the client will need to send a refresh token to get a new access token. However, what is stopping an attempt to run a brute force attack against an endpoint and firing lots of random values for the access token? I know it will be a guessing game but potentially if you have a few million users all with valid tokens then there is a possibility that it could guess it after a few days/weeks of trying?
  15. Perfect! using a link to the json page and then using the backwards button and clicking the link again causes it to use be cached page, if you continue just clicking the link and then pressing back over and over until the cache time expires, on the next load it pulls the new data. This is exactly what I was expecting and it working ok using this method. thank you for your help.
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.