Jump to content


  • Posts

  • Joined

  • Last visited

Everything posted by mds1256

  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.
  16. Hi Using the method of expires (to see if i can get it working) the Response headers are returning an Expires with a date in the future (around 5 minutes to test). However when I refresh (either by clicking the refresh or by just pressing enter on the address bar (to reload the page) it seems to give the new data (that I changed in the database using the back end). Expected results is to return the same data until the expiry has passed and then on the next reload to bring the new data back. How should I be testing if it is being cached?
  17. Even if I use Expires it still doesn't seem to cache using anything even though the header is sent in the response. Any ideas?
  18. Hi I am developing a rest API using PHP and returning a ison response, I am setting the headers of the response as below: header('Content-type:application/json;charset=utf-8'); header('Cache-Control: public, max-age=60'); However if I use Postman or Google Chrome or Safari or any web browser the response isn't caching. the url is something like https://www.mysite.com/contacts and it responds with a json response of all contacts What I am expecting is that response to be cached for 60 seconds, but if I update the table in the database from the backend and then refresh/press enter on the address bar to re-load I get the new value straight away. I am expecting the same value to be returned until the 60 seconds has lapsed. Any idea where I am going wrong? Thanks
  19. Thanks for that, yeah that is what I thought. The controller is the business logic which can involve different models, the model is for structuring the data and performing validation and formatting the data (whether it is stored in a database or not). Thanks again
  20. Just trying to get my head around what should be in a model and controller. So I have currently the model class as a data structure for an entity (person) which performs validation on the data held using the set methods, e.g. making sure Age is > 0 etc The controller creates the model (Person) and has the business login in for a process e.g. retrieve/insert person from/to database. Is the way I am using this correct as I have read that the model should handle the save / retrieve to/from the database. I have also read that the model should have no login in there at all and that it should just be a structure for holding an entity. Just wanting to know the correct way of using MVC.
  21. Thanks, just wanted to check the method I was going to use.
  22. Hi I am wanting to create a login for a portal I have created and want to use access tokens. These tokens expire after 60 minutes when they need to refresh (refresh token will also be sent to the client). How do I achieve this, when the authentication request succeeds (e.g. login with username and password) do I set a client side cookie that has the access_token and refresh_token values along with a cookie expiry? Thanks
  23. So I have been thinking about this a little more. If when generating the token I prefix the token with userid. E.g. ‘2.abcde’ would be returned to the client as the token I then store the hash of the ‘abcde’ actual token in the database, then substring the numbers to the first period and make sure that when verifying the token that the user id and period is stripped and run what is left of the actual token through password verify but also make sure the user id also matches?
  24. This is exactly the question but better explained which like you say that a unique constraint doesn’t help. @gizmola I wasn’t been funny about saying you don’t understand, but you just weren’t getting what I was trying to get across where as @kicken has got it spot on
  25. Sorry but you are missing what I am saying. The scenario above meant that in the database the users still had unique tokens at that point in time as the token had changed for user 1 but then User 2s authentication caused it to pick a token for user 2 that was the same as what user 1s token was before it was changed, so any tokens that was stored on the stale client would then now authenticate against user 2s access token instead of user 1 (as user 2s token is the same as what user 1s token was before it was changed, so a unique constraint wouldn’t help here as the two tokens are different)
  • 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.