I was just wondering if this would be a reasonable way to write a custom authentication method for a RESTful API. It seems moderately secure, but perhaps I'm way wrong here.
1) Email and Password are sent over HTTPS to my server.
2) Server stores the email, and runs the password through a SHA512 hash with a 256 bit random salt. The hashed and salted password is stored in the database.
So now we have:
email = email@example.com
password = OHqhuewQclakufEjUbZMbowJKEGcvEBz,51c6a3cb58e10754f76e334de064a9dede7875141e1ce0233e3ff14fd7be98a4d5b8fc1c5ab871cb3b1d6b0c9f8073bc3558308511fc4fd6bd049aed5e58a9a4
3) Generate a random token with a lifetime (very random and large), store it the database, and then link that random token to that specific authenticated user.
4) I send the token back to the client through HTTPS (web, Android, or iOS), whereby it's stored in cookies or SharedPrefs or what have you.
5) Now, the client sends the token with every request. The server can then check the cached token value with the one it's receiving each time to make sure that the server always knows who's making requests.
Does this seem reasonable and secure? The issue I think that arises here is if the tokens data becomes compromised. Is there perhaps anyway to toughen that one part up?
答案 0 :(得分：-1)
you must know that there is nothing 100% secure,
you can store the ip of the user recent logged, if you receive another login from the same user from diferent ip, you can send back a response indicating that user is already connected