3 ms·
Use tokens issued for a user and IP combination. Use HTTPS to carry the auth for the user and return a token. Use the token with HTTPS or HTTP to continue tal
by kordless 16y ago
Use tokens issued for a user and IP combination. Use HTTPS to carry the auth for the user and return a token. Use the token with HTTPS or HTTP to continue talking to the server. Expire tokens after some reasonable time. Expired tokens indicate you need to reauth. If you lose a token, it could only be used by someone pretending to be you (and with your IP), so limit what a token can do via the service's API if you want.
Additionally, keeping a user's clear text password in a local datastore is usually a 'bad idea'. At least store the MD5 or SHA-2 of the password (MD5 is considered insecure now though) and then pass the hash along to auth the user before giving them a token.
- jacoblyles 16y agoDo cell phones keep the same IP address for any significant period of time?
- kordless 16y agoMine usually does for at least a few hours. You can check by going to whatsmyip.org!
- bitanarch 16y agoYes, that's basically the way to do it. If you're doing it on a mobile phone you can even add HMAC (via SHA-1 or SHA-2, MD5 is still ok for that but we all know it's possible to produce MD5 collisions now) on that token when you're talking on HTTP. That way, all messages on the network will be at least authenticated. The IP checking bit is probably not a good idea. A mobile phone user can be switching between 3G and a public Wifi hotspot as he goes. It can negatively affect user experience.
- k0ban 16y agoI agree don't use IP as a part of token - it will require user to re-authenticate very often. And don't forget about the salt. Store password something like SHA-1(MD5(password)+password)