Re: Basic login security/session management question
Andrey! I don't get why you're putting an exclamation point after my name. Are you shouting at me? I can't explain why you need cookies. I don't use them. I didn't write the FAQ either. Walden On Oct 26, 10:17 am, Andrey [EMAIL PROTECTED] wrote: walden! I also don't get why we need cookies. Can you please answer to this question? Why don't we store session id in JS variable? On 1 окт, 15:44, walden [EMAIL PROTECTED] wrote: Hi nogridbag, You might just want to begin at the beginning and read the HTTP Basic and HTTP Digest specifications. These will give you an indication of what is already built into browsers and web server for solving the mainstream of authenciation requirements on the web in a way that is orthogonal to application logic (a good thing). Realize that the FAQ your read is part of a departure from those standards. Part of the cost of that departure is the complexity you have stumbled on. Walden On Sep 30, 11:22 pm, nogridbag [EMAIL PROTECTED] wrote: Hi, I'm fairly new to web apps so I have a few basic questions about handling the user's securesession. I read the article onlogin securityhere: http://code.google.com/p/google-web-toolkit-incubator/wiki/LoginSecur... I understand everything up to the section How to remember logins. At the bottom of that section it states Remember - you must never rely on the sessionID sent to your server in the cookie header ; look only at the sessionID that your GWT app sends explicitly in the payload of messages to your server. I've numbered the questions below: 1) If we can't trust cookies, what's the point of using cookies at all? If it's just so the browser UI thinks the user is logged in, why not just store it in some local client side variable since GWT applications are contained within a single page. * Make RPC call with user/pass * Server says pass = OK * In User.java, call setLoggedIn(true) 2) That leads me to my next question, how should the sessionID be stored in the client? Do I just store it in some class, let's say User.java as a String or whatnot in plain text? 3) Then, in any RPC request that needs the user to be logged in, I pass thissessionID along with the rest of the objects? 4) How does the server then take this sessionId and authenticate it? Is the approach the same whether I'm using Java/RPC with Tomcat or JSON with php on an Apache server? Can you give an example (or a link to a page the explains this?) 5) Finally, is there any situation where you would store the username/ pass on the client in order to authenticate each RPC call? If so, what would be thesecurityimplications of this? Thanks. I'm sorry for the basic questions. This is all fairly new to me since my only experience with web appsecurityis academic and very minimal. It's obviously something I don't want to get wrong :)- Hide quoted text - - Show quoted text - --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com 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 -~--~~~~--~~--~--~---
Re: Basic login security/session management question
inline responses... On Oct 1, 4:22 am, nogridbag [EMAIL PROTECTED] wrote: 1) If we can't trust cookies, what's the point of using cookies at all? As a storage space to save the session ID between sessions. Users do sometimes close their web browsers, or at least the tab with your page on it. I know. Those bastards! Incidentally, those same blasted users get very miffed if they have to enter a password every time they revisit your page. 2) That leads me to my next question, how should the sessionID be stored in the client? Do I just store it in some class, let's say User.java as a String or whatnot in plain text? Yes. 3) Then, in any RPC request that needs the user to be logged in, I pass this session ID along with the rest of the objects? Well, usually you pass one object, which might contain a number of other objects, -and- the sessionID. Your server, in turn, looks only at that and completely ignores the cookie. In fact, if you want to get real fancy, you kill the cookie, and add a window closing hook, and re- add it, but because that hook doesn't get called with certainty when your page is going away, that's a bad idea. You could get fancy and kill the cookie, send your request AND start a 5 millisecond timer, and re-add it. I haven't tried this myself yet, seemed overkill given that my server is 100% SSL. 4) How does the server then take this sessionId and authenticate it? Depends on your framework. Don't let your framework run its own session id management; they stuff it and look at the cookie, or they add it to all generated URLs. (if they do this without you telling it to in a setting, get rid of this framework right now. It's a blatent security issue that's been known for years. If they haven't fixed that, I really wouldn't trust them with anything else). If your framework doesn't support manual session ID management, then you'll have to manually manage the entire session. Annoying. Consider mailing your framework authors to add the ability to manually manage just the session tokens. (e.g: two methods - one with: generate me a new session ID please, and another with: Here's a session ID. Fetch me the session object. Or, if session querying is built in, a method with: Here's a session ID. Consider that this request has been sent with this session ID from here on out). 5) Finally, is there any situation where you would store the username/ pass on the client in order to authenticate each RPC call? If so, what would be the security implications of this? They wouldn't be very good. Don't do this. First of all, its very inflexible: Without both SSL and a requirement to re-login everytime you revisit the page, you've got a serious security issue, for example. Maybe you want your webapp to work that way, but what are you going to do if your client says: Well, turns out we do want logins to persist, at least for a little while. Or even: We want the ability to open a link in a new tab (that's a new 'session' after all!) - then you need to hack in a session system. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com 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 -~--~~~~--~~--~--~---
Re: Basic login security/session management question
walden! I also don't get why we need cookies. Can you please answer to this question? Why don't we store session id in JS variable? On 1 окт, 15:44, walden [EMAIL PROTECTED] wrote: Hi nogridbag, You might just want to begin at the beginning and read the HTTP Basic and HTTP Digest specifications. These will give you an indication of what is already built into browsers and web server for solving the mainstream of authenciation requirements on the web in a way that is orthogonal to application logic (a good thing). Realize that the FAQ your read is part of a departure from those standards. Part of the cost of that departure is the complexity you have stumbled on. Walden On Sep 30, 11:22 pm, nogridbag [EMAIL PROTECTED] wrote: Hi, I'm fairly new to web apps so I have a few basic questions about handling the user's securesession. I read the article onlogin securityhere: http://code.google.com/p/google-web-toolkit-incubator/wiki/LoginSecur... I understand everything up to the section How to remember logins. At the bottom of that section it states Remember - you must never rely on the sessionID sent to your server in the cookie header ; look only at the sessionID that your GWT app sends explicitly in the payload of messages to your server. I've numbered the questions below: 1) If we can't trust cookies, what's the point of using cookies at all? If it's just so the browser UI thinks the user is logged in, why not just store it in some local client side variable since GWT applications are contained within a single page. * Make RPC call with user/pass * Server says pass = OK * In User.java, call setLoggedIn(true) 2) That leads me to my next question, how should the sessionID be stored in the client? Do I just store it in some class, let's say User.java as a String or whatnot in plain text? 3) Then, in any RPC request that needs the user to be logged in, I pass thissessionID along with the rest of the objects? 4) How does the server then take this sessionId and authenticate it? Is the approach the same whether I'm using Java/RPC with Tomcat or JSON with php on an Apache server? Can you give an example (or a link to a page the explains this?) 5) Finally, is there any situation where you would store the username/ pass on the client in order to authenticate each RPC call? If so, what would be thesecurityimplications of this? Thanks. I'm sorry for the basic questions. This is all fairly new to me since my only experience with web appsecurityis academic and very minimal. It's obviously something I don't want to get wrong :) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com 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 -~--~~~~--~~--~--~---
Re: Basic login security/session management question
You don't need cookies. The FAQ actually tells you not to rely on cookie data Store the session ID somewhere as a GWT field and send it with the rest of your data Ian http://examples.roughian.com 2008/10/26 Andrey [EMAIL PROTECTED] walden! I also don't get why we need cookies. Can you please answer to this question? Why don't we store session id in JS variable? On 1 окт, 15:44, walden [EMAIL PROTECTED] wrote: Hi nogridbag, You might just want to begin at the beginning and read the HTTP Basic and HTTP Digest specifications. These will give you an indication of what is already built into browsers and web server for solving the mainstream of authenciation requirements on the web in a way that is orthogonal to application logic (a good thing). Realize that the FAQ your read is part of a departure from those standards. Part of the cost of that departure is the complexity you have stumbled on. Walden On Sep 30, 11:22 pm, nogridbag [EMAIL PROTECTED] wrote: Hi, I'm fairly new to web apps so I have a few basic questions about handling the user's securesession. I read the article onlogin securityhere: http://code.google.com/p/google-web-toolkit-incubator/wiki/LoginSecur. .. I understand everything up to the section How to remember logins. At the bottom of that section it states Remember - you must never rely on the sessionID sent to your server in the cookie header ; look only at the sessionID that your GWT app sends explicitly in the payload of messages to your server. I've numbered the questions below: 1) If we can't trust cookies, what's the point of using cookies at all? If it's just so the browser UI thinks the user is logged in, why not just store it in some local client side variable since GWT applications are contained within a single page. * Make RPC call with user/pass * Server says pass = OK * In User.java, call setLoggedIn(true) 2) That leads me to my next question, how should the sessionID be stored in the client? Do I just store it in some class, let's say User.java as a String or whatnot in plain text? 3) Then, in any RPC request that needs the user to be logged in, I pass thissessionID along with the rest of the objects? 4) How does the server then take this sessionId and authenticate it? Is the approach the same whether I'm using Java/RPC with Tomcat or JSON with php on an Apache server? Can you give an example (or a link to a page the explains this?) 5) Finally, is there any situation where you would store the username/ pass on the client in order to authenticate each RPC call? If so, what would be thesecurityimplications of this? Thanks. I'm sorry for the basic questions. This is all fairly new to me since my only experience with web appsecurityis academic and very minimal. It's obviously something I don't want to get wrong :) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com 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 -~--~~~~--~~--~--~---
Basic login security/session management question
Hi, I'm fairly new to web apps so I have a few basic questions about handling the user's secure session. I read the article on login security here: http://code.google.com/p/google-web-toolkit-incubator/wiki/LoginSecurityFAQ I understand everything up to the section How to remember logins. At the bottom of that section it states Remember - you must never rely on the sessionID sent to your server in the cookie header ; look only at the sessionID that your GWT app sends explicitly in the payload of messages to your server. I've numbered the questions below: 1) If we can't trust cookies, what's the point of using cookies at all? If it's just so the browser UI thinks the user is logged in, why not just store it in some local client side variable since GWT applications are contained within a single page. * Make RPC call with user/pass * Server says pass = OK * In User.java, call setLoggedIn(true) 2) That leads me to my next question, how should the sessionID be stored in the client? Do I just store it in some class, let's say User.java as a String or whatnot in plain text? 3) Then, in any RPC request that needs the user to be logged in, I pass this session ID along with the rest of the objects? 4) How does the server then take this sessionId and authenticate it? Is the approach the same whether I'm using Java/RPC with Tomcat or JSON with php on an Apache server? Can you give an example (or a link to a page the explains this?) 5) Finally, is there any situation where you would store the username/ pass on the client in order to authenticate each RPC call? If so, what would be the security implications of this? Thanks. I'm sorry for the basic questions. This is all fairly new to me since my only experience with web app security is academic and very minimal. It's obviously something I don't want to get wrong :) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com 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 -~--~~~~--~~--~--~---
