Hi & Thank you. So the way is like this: 1) user logs in at the client 2) user credentials will be sent to the server & server checks it 3) server creates database entry for the newly authenticated session 4) server tells client about this value 5) on each serverrequest, the client adds the sessionvalue to the request 6) server will handle the request if the value is correct
ok? when the client application is closed, and opened again sometime, how is the client able to communicate with the server without asking the user for credentials? Do i have to store the Sessionkey which i created on the server for authentication on the client? On Sep 7, 7:37 pm, Chris Palmer <[email protected]> wrote: > > From the first time the user "registers" himself he should be logged > > on permanently, except the user logs out explicitely.... > > What's the common approach for this? > > My intention is to store a simple value as SharedPreference when the > > user is logged in. > > On application startup this value will be checked and the "login > > activity" will be shown or not. > > Your problem is very similar to the web application authentication > problem. One common and good option is to have the server create a > database entry for the newly-authenticated session, and key the DB > entry with a large, unpredictable value. (16 bytes from > java.security.SecureRandom is the usual way to do it, and is secure.) > Then, tell the client the value. Then, ever after, the client sends > the value to the server on each request. The server does a DB lookup > on that key to see if the session is valid or not. > > This way, you can avoid storing a password on the client; on the > server, you store only a hashed password (a common approach is to use > bcrypt or a regular cryptographic hash function iterated thousands of > times). Don't store a plaintext password, and don't store a password > hashed only once. > > Then your main problem will be protecting the session identifier when > transmitting it over the network --- you need to keep it confidential. > HTTPS is generally sufficient for that purpose. The stronger your > HTTPS server authentication policy, the better. -- You received this message because you are subscribed to the Google Groups "Android Security Discussions" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/android-security-discuss?hl=en.
