Hi Cresteb, I have a couple of things to add to what others have said.
1 - I presume all of the session talk in this thread is in regards to non-Java languages for the server-side. If you are using a J2EE application on the back end you don't need to worry so much about passing session IDs since the app server will pretty much handle that for you once authentication has been established. In fact, you are encouraged not to. 2 - When generating a password hash to store in a DB, regardless of what hash algorithm is used I will typically hash the (username +password) and place that in the password field. This offers a couple of advantages. a) you get a single "ticket" by which a user can be looked up if both values are known. b) if your data gets compromised, even the passwords of users who stupidly use the same common password (i.e. "password", "secret", etc...) won't show up the same in the database. To make it even better you can add another element to the mix (secret+username+password) so that the same username+password in different applications shows up differently in the database. On Aug 19, 10:11 pm, cresteb <[EMAIL PROTECTED]> wrote: > Hello! > > I have some basic questions on the Register + Login + Keep session > alive process described on the Login Security FAQ. > > I know this is a little bit offtopic, but it would be really helpful > for me and other newbies if anyone can clarify some issues. > > This is how I see the process with some questions attached, please > correct it where necessary! > > Register: > > 1) Send username and password from client to server. > Q: I guess all the sites make this step over https so anyone can sniff > the password, right? > > 2) Store in the DB the username and the hash of the password. > > Login: > > 1) Send username and password from client to server (again over SSL). > > 2) Calculate the pasword's hash and look for a register in the DB that > contains that username and hash combination. > > 3) Return a session ID from server to client. > Q: Is this also done through https? If not, can't it be this session > id intercepted and used later to make a query as if you were other > user? > > During the session: > > 1) For every request from the client, include the session id, so the > server knows which user is sending the request and it is able to check > if the session is still active. > Q: Is secure enough just sending the session ID in order to identify > the user? > Q: The same as above...should it be sent through https? > > 2) Check if the session ID is valid or not. If its valid, send the > response with the data of the associated user. > Q: Is it also recommended to send a new session ID on each request so > we increase the security? > > Please, feel free to suggest me any document related with this topic. > > Thanks is advance! --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" 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/Google-Web-Toolkit?hl=en -~----------~----~----~----~------~----~------~--~---
