[PHP] Re: a question on session ID and security
1. script for login process is located on a SSL-enabled server, so usernames and passwords are encrypted. https:// is an envelope encryption, so POST data, which is a part of the packet data, not packet headers, is encrypted. As long as you POST or COOKIE data that needs encryption, you're fine. GET is not secure. 2. upon successful login, user is relocated to a non-SSL-enabled server which hosts the scripts that contain the authenticated-user-only features. If this is what you're doing (header() or a meta-refresh html tag). So, while usernames and passwords are protected by SSL, the PHPSESSID is not. In other words, anyone who captures that HTTP GET packet can get the session ID. Is that true? There are a few different attack vectors with SESSION data. Needless to say, never store or authenticate by a PHP SESSION id only; use cookies or encrypt a page with script and include() the content per page, and force users to login every page change. Another question is while that session ID is valid only before an unset() and a session_destroy(). So the attacker who has the session ID must fake the session before the real user logout. Is that true? Before the session is destroyed and the temp file where it is stored is deleted from the harddrive. Do not store sensitive information or use a SESSION id to authenticate a user. -- Jared Farrish Intermediate Web Developer Denton, Tx Abraham Maslow: "If the only tool you have is a hammer, you tend to see every problem as a nail." $$
[PHP] Re: a question on session ID and security
On 5/29/07, Stut <[EMAIL PROTECTED]> wrote: What utter crud. An SSL connection encrypts the whole HTTP conversation, including headers and even the URL you are requesting. The response is also encrypted. It doesn't matter whether you're doing a POST or a GET request, it's all encrypted. The URL string is encrypted in HTTPS? Well, I was certainly under a different impression (same with headers). Since I can't say I know any better beyond a shadow of a doubt, I'll take your word for it. : ) Cookies are no more secure than the session ID. The general conclusion from many years of discussion in the web community is that the user experience is diminished so much by not trusting a session ID that the security improvements are not justified. So by storing sensitive information in a SESSION, you're safer? Only if the session doesn't get read... I don't know, I guess in the security sense, it should be seen as a part of the "conversation" as you put it, so if you can't trust SESSION, you probably shouldn't use it at all for secure applications. I still don't see the sense in storing sensitive information in a session, at least one that persists; if it is passed to a temp table in a database and destroyed across calls, I can see that as a better solution, as long as you have a strong database security configuration. If you're really concerned then your best bet is to reduce the session lifetime to 5-10 minutes. Another 'trick' people sometimes use is to store the user agent in the session and expire it if a request tries to use an existing session with a different user agent. Unfortunately you cannot rely on the IP address remaining the same throughout a session, so don't build that into your session validation. Well, if you use COOKIES, you can pass a secondary hash key that can be used to validate the actual key against a footprint for a visitor (from $_SERVER). Salt in a date/timestamp and SHA1 or other, and I feel like that's a pretty good way to check against a visitor. I just think it feels flimsy to validate a user on a SESSION key only. -- Jared Farrish Intermediate Web Developer Denton, Tx Abraham Maslow: "If the only tool you have is a hammer, you tend to see every problem as a nail." $$ -- Jared Farrish Intermediate Web Developer Denton, Tx Abraham Maslow: "If the only tool you have is a hammer, you tend to see every problem as a nail." $$
Re: [PHP] Re: a question on session ID and security
Jared Farrish wrote: 1. script for login process is located on a SSL-enabled server, so usernames and passwords are encrypted. https:// is an envelope encryption, so POST data, which is a part of the packet data, not packet headers, is encrypted. As long as you POST or COOKIE data that needs encryption, you're fine. GET is not secure. What utter crud. An SSL connection encrypts the whole HTTP conversation, including headers and even the URL you are requesting. The response is also encrypted. It doesn't matter whether you're doing a POST or a GET request, it's all encrypted. 2. upon successful login, user is relocated to a non-SSL-enabled server which hosts the scripts that contain the authenticated-user-only features. If this is what you're doing (header() or a meta-refresh html tag). So, while usernames and passwords are protected by SSL, the PHPSESSID is not. In other words, anyone who captures that HTTP GET packet can get the session ID. Is that true? There are a few different attack vectors with SESSION data. Needless to say, never store or authenticate by a PHP SESSION id only; use cookies or encrypt a page with script and include() the content per page, and force users to login every page change. Cookies are no more secure than the session ID. The general conclusion from many years of discussion in the web community is that the user experience is diminished so much by not trusting a session ID that the security improvements are not justified. If you're really concerned then your best bet is to reduce the session lifetime to 5-10 minutes. Another 'trick' people sometimes use is to store the user agent in the session and expire it if a request tries to use an existing session with a different user agent. Unfortunately you cannot rely on the IP address remaining the same throughout a session, so don't build that into your session validation. Another question is while that session ID is valid only before an unset() and a session_destroy(). So the attacker who has the session ID must fake the session before the real user logout. Is that true? Before the session is destroyed and the temp file where it is stored is deleted from the harddrive. Do not store sensitive information or use a SESSION id to authenticate a user. The session ID should be used for exactly what it says on the tin - identifying a session. PHP takes care of this for you by looking at the sessions it is maintaining for one matching the ID it's given. You can and should authenticate the continuation of a session based on the session ID (otherwise there's not much point having the session because the user will need to login for each page request), but you should not be storing the session ID anywhere because it's not a permanent value. To invalidate a session ID you just need to call session_destroy. There are people who do the following just to be sure that the data in a session is destroyed, but AFAIK it's not necessary... foreach (array_keys($_SESSION) as $key) unset($_SESSION[$key]); -Stut -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: a question on session ID and security
2007. 05. 29, kedd keltezéssel 10.09-kor Stut ezt írta: > Jared Farrish wrote: > >> 1. script for login process is located on a SSL-enabled server, so > >> usernames and passwords are encrypted. > > https:// is an envelope encryption, so POST data, which is a part of the > > packet data, not packet headers, is encrypted. As long as you POST or > > COOKIE > > data that needs encryption, you're fine. GET is not secure. > > What utter crud. An SSL connection encrypts the whole HTTP conversation, > including headers and even the URL you are requesting. The response is > also encrypted. It doesn't matter whether you're doing a POST or a GET > request, it's all encrypted. > > >> 2. upon successful login, user is relocated to a non-SSL-enabled server > >> which hosts the scripts that contain the authenticated-user-only > >> features. > > If this is what you're doing (header() or a meta-refresh html tag). > > > >> So, while usernames and passwords are protected by SSL, the PHPSESSID is > >> not. In other words, anyone who captures that HTTP GET packet can get > >> the session ID. Is that true? > > There are a few different attack vectors with SESSION data. Needless to > > say, > > never store or authenticate by a PHP SESSION id only; use cookies or > > encrypt > > a page with script and include() the content per page, and force users to > > login every page change. > > Cookies are no more secure than the session ID. The general conclusion > from many years of discussion in the web community is that the user > experience is diminished so much by not trusting a session ID that the > security improvements are not justified. > > If you're really concerned then your best bet is to reduce the session > lifetime to 5-10 minutes. Another 'trick' people sometimes use is to > store the user agent in the session and expire it if a request tries to > use an existing session with a different user agent. Unfortunately you > cannot rely on the IP address remaining the same throughout a session, > so don't build that into your session validation. > > >> Another question is while that session ID is valid only before an > >> unset() and a session_destroy(). So the attacker who has the session ID > >> must fake the session before the real user logout. Is that true? > > Before the session is destroyed and the temp file where it is stored is > > deleted from the harddrive. Do not store sensitive information or use a > > SESSION id to authenticate a user. > > The session ID should be used for exactly what it says on the tin - > identifying a session. PHP takes care of this for you by looking at the > sessions it is maintaining for one matching the ID it's given. You can > and should authenticate the continuation of a session based on the > session ID (otherwise there's not much point having the session because > the user will need to login for each page request), but you should not > be storing the session ID anywhere because it's not a permanent value. > > To invalidate a session ID you just need to call session_destroy. There > are people who do the following just to be sure that the data in a > session is destroyed, but AFAIK it's not necessary... > > foreach (array_keys($_SESSION) as $key) unset($_SESSION[$key]); or just simply $_SESSION = array(); greets Zoltán Németh > > -Stut > -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: a question on session ID and security
Zoltán Németh wrote: 2007. 05. 29, kedd keltezéssel 10.09-kor Stut ezt írta: Jared Farrish wrote: 1. script for login process is located on a SSL-enabled server, so usernames and passwords are encrypted. https:// is an envelope encryption, so POST data, which is a part of the packet data, not packet headers, is encrypted. As long as you POST or COOKIE data that needs encryption, you're fine. GET is not secure. What utter crud. An SSL connection encrypts the whole HTTP conversation, including headers and even the URL you are requesting. The response is also encrypted. It doesn't matter whether you're doing a POST or a GET request, it's all encrypted. 2. upon successful login, user is relocated to a non-SSL-enabled server which hosts the scripts that contain the authenticated-user-only features. If this is what you're doing (header() or a meta-refresh html tag). So, while usernames and passwords are protected by SSL, the PHPSESSID is not. In other words, anyone who captures that HTTP GET packet can get the session ID. Is that true? There are a few different attack vectors with SESSION data. Needless to say, never store or authenticate by a PHP SESSION id only; use cookies or encrypt a page with script and include() the content per page, and force users to login every page change. Cookies are no more secure than the session ID. The general conclusion from many years of discussion in the web community is that the user experience is diminished so much by not trusting a session ID that the security improvements are not justified. If you're really concerned then your best bet is to reduce the session lifetime to 5-10 minutes. Another 'trick' people sometimes use is to store the user agent in the session and expire it if a request tries to use an existing session with a different user agent. Unfortunately you cannot rely on the IP address remaining the same throughout a session, so don't build that into your session validation. Another question is while that session ID is valid only before an unset() and a session_destroy(). So the attacker who has the session ID must fake the session before the real user logout. Is that true? Before the session is destroyed and the temp file where it is stored is deleted from the harddrive. Do not store sensitive information or use a SESSION id to authenticate a user. The session ID should be used for exactly what it says on the tin - identifying a session. PHP takes care of this for you by looking at the sessions it is maintaining for one matching the ID it's given. You can and should authenticate the continuation of a session based on the session ID (otherwise there's not much point having the session because the user will need to login for each page request), but you should not be storing the session ID anywhere because it's not a permanent value. To invalidate a session ID you just need to call session_destroy. There are people who do the following just to be sure that the data in a session is destroyed, but AFAIK it's not necessary... foreach (array_keys($_SESSION) as $key) unset($_SESSION[$key]); or just simply $_SESSION = array(); I consider this is very bad practice, but I've just checked the manual page for session_destory and it recommends the following to completely destroy a session... -Stut -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: a question on session ID and security
Jared Farrish wrote: On 5/29/07, Stut <[EMAIL PROTECTED]> wrote: What utter crud. An SSL connection encrypts the whole HTTP conversation, including headers and even the URL you are requesting. The response is also encrypted. It doesn't matter whether you're doing a POST or a GET request, it's all encrypted. The URL string is encrypted in HTTPS? Well, I was certainly under a different impression (same with headers). Since I can't say I know any better beyond a shadow of a doubt, I'll take your word for it. : ) The only part of an SSL connection that's not encrypted is the handshaking that goes on to set it up in the first place. Everything after that, the GET/POST line, headers and the body as well as the entire response is encrypted. Cookies are no more secure than the session ID. The general conclusion from many years of discussion in the web community is that the user experience is diminished so much by not trusting a session ID that the security improvements are not justified. So by storing sensitive information in a SESSION, you're safer? Only if the session doesn't get read... I don't know, I guess in the security sense, it should be seen as a part of the "conversation" as you put it, so if you can't trust SESSION, you probably shouldn't use it at all for secure applications. I still don't see the sense in storing sensitive information in a session, at least one that persists; if it is passed to a temp table in a database and destroyed across calls, I can see that as a better solution, as long as you have a strong database security configuration. I never said it was safer to store sensitive information in a session - stop adding words! All I said was that the whole discussion of session security has been done to death and the conclusion is that you put the minimum possible on the client (the session ID) and store everything else on the server. If security is a big enough issue that you worry about data in the session being read then you need a dedicated server. If on the other hand you mean credit card information when you say sensitive data, there is no reason on earth why that should ever be *stored* anywhere on your server(s), even a "temp" table. As far as the relative security of cookies against sessions, they are basically as insecure as each other in most cases, but your cookies are at the mercy of the users setup which is something I'm just not willing to trust. The bottom line is that anything sent to or received from the user is insecure, and any security that can be added beyond SSL is easily worked around. If you're really concerned then your best bet is to reduce the session lifetime to 5-10 minutes. Another 'trick' people sometimes use is to store the user agent in the session and expire it if a request tries to use an existing session with a different user agent. Unfortunately you cannot rely on the IP address remaining the same throughout a session, so don't build that into your session validation. Well, if you use COOKIES, you can pass a secondary hash key that can be used to validate the actual key against a footprint for a visitor (from $_SERVER). Salt in a date/timestamp and SHA1 or other, and I feel like that's a pretty good way to check against a visitor. I just think it feels flimsy to validate a user on a SESSION key only. Indeed, you can validate a session by using certain information from the $_SERVER array, but bear in mind that none of it is necessarily persistant. I don't know of any examples, but I'm sure somewhere there is a crappy browser that changes its user agent for every request. However, of all the options I think the user agent is your best bet if you really feel you need to worry about it. In your comment above you seem to be suggesting passing that "secondary hash key" between requests via a cookie. Why not just store that in the session? Then it doesn't go outside your app. And as mentioned previously you have a lot more control over the session data than you do over cookie data. Here one final thought... if there was a reliable way to add security to sessions don't you think that one of the multitude of web development languages out there would have done it, including PHP? -Stut -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: a question on session ID and security
On 5/29/07, Stut <[EMAIL PROTECTED]> wrote: The only part of an SSL connection that's not encrypted is the handshaking that goes on to set it up in the first place. Everything after that, the GET/POST line, headers and the body as well as the entire response is encrypted. One of these days I'm actually going to run some tests so I can see what is actually happening. I would sound completely ignorant speaking of packets as if I knew them that well, so I won't! I never said it was safer to store sensitive information in a session - stop adding words! All I said was that the whole discussion of session security has been done to death and the conclusion is that you put the minimum possible on the client (the session ID) and store everything else on the server. If security is a big enough issue that you worry about data in the session being read then you need a dedicated server. If on the other hand you mean credit card information when you say sensitive data, there is no reason on earth why that should ever be *stored* anywhere on your server(s), even a "temp" table. I find the best way to advice people on SESSIONS is not to trust them, and thus not store any kind of sensitive information within them (SSN, credit card, even phone numbers and whatnot). Since I don't happen to use sessions or cookies that often (for this reason), maybe my advice is a little biased. I store user data in cookies... One thing that makes this all completely irrevelent is that, for someone with physical access to authenticated browser session (such as an co-worker), no amount of security will prevent misuse of a session. As far as the relative security of cookies against sessions, they are basically as insecure as each other in most cases, but your cookies are at the mercy of the users setup which is something I'm just not willing to trust. True. I should have a fallback to use SESSION if cookies are not available, but if I'm doing that, why not go whole-hog? The bottom line is that anything sent to or received from the user is insecure, and any security that can be added beyond SSL is easily worked around. And SSL is rendered moot for users who gain browser access to an authenticated session. Security, I believe, is a matter of pushing vulnerabilities into a corner. You can't ever make any system completely secure, as such a system would be virtually useless. Well, if you use COOKIES, you can pass a secondary hash key that can be > used > to validate the actual key against a footprint for a visitor (from > $_SERVER). Salt in a date/timestamp and SHA1 or other, and I feel like > that's a pretty good way to check against a visitor. I just think it feels > flimsy to validate a user on a SESSION key only. Indeed, you can validate a session by using certain information from the $_SERVER array, but bear in mind that none of it is necessarily persistant. I don't know of any examples, but I'm sure somewhere there is a crappy browser that changes its user agent for every request. However, of all the options I think the user agent is your best bet if you really feel you need to worry about it. What happens if someone is behind a proxy? Never tested that, but if someone were to make a proxy sanitizer that purposefully skewed what it reports in the headers, that approach could be difficult to troubleshoot. In your comment above you seem to be suggesting passing that "secondary hash key" between requests via a cookie. Why not just store that in the session? Then it doesn't go outside your app. And as mentioned previously you have a lot more control over the session data than you do over cookie data. The whole point of using a shared hash is to provide notional benefit by providing a secondary key, that is stored on the browser, which is used to build the authenticated token, which is then matched to the server token. This is a type of security hash similar to the one you suggested above (using $_SERVER variables), only stored in a cookie. Different approach for different folks... : ) Here one final thought... if there was a reliable way to add security to sessions don't you think that one of the multitude of web development languages out there would have done it, including PHP? I certainly don't think you're implying I thought I had given some new, "better" way of doing sessions that nobody had given before? Curious statement. -- Jared Farrish Intermediate Web Developer Denton, Tx Abraham Maslow: "If the only tool you have is a hammer, you tend to see every problem as a nail." $$
Re: [PHP] Re: a question on session ID and security
Jared Farrish wrote: On 5/29/07, Stut <[EMAIL PROTECTED]> wrote: The only part of an SSL connection that's not encrypted is the handshaking that goes on to set it up in the first place. Everything after that, the GET/POST line, headers and the body as well as the entire response is encrypted. One of these days I'm actually going to run some tests so I can see what is actually happening. I would sound completely ignorant speaking of packets as if I knew them that well, so I won't! Sniff an SSL connection and you'll see it. Most of the traffic is gibberish! I never said it was safer to store sensitive information in a session - stop adding words! All I said was that the whole discussion of session security has been done to death and the conclusion is that you put the minimum possible on the client (the session ID) and store everything else on the server. If security is a big enough issue that you worry about data in the session being read then you need a dedicated server. If on the other hand you mean credit card information when you say sensitive data, there is no reason on earth why that should ever be *stored* anywhere on your server(s), even a "temp" table. I find the best way to advice people on SESSIONS is not to trust them, and thus not store any kind of sensitive information within them (SSN, credit card, even phone numbers and whatnot). Since I don't happen to use sessions or cookies that often (for this reason), maybe my advice is a little biased. I store user data in cookies... You do? What sort of data? Nothing sensitive I hope. One thing that makes this all completely irrevelent is that, for someone with physical access to authenticated browser session (such as an co-worker), no amount of security will prevent misuse of a session. The best you can hope to provide is end-to-end security and security on the server end. Anything beyond the connection at the client is out of your control and not worth worrying about. As far as the relative security of cookies against sessions, they are basically as insecure as each other in most cases, but your cookies are at the mercy of the users setup which is something I'm just not willing to trust. True. I should have a fallback to use SESSION if cookies are not available, but if I'm doing that, why not go whole-hog? Fallback to sessions? That makes no sense to me. Aside from the fact that you are storing application data on the client machine (which could be in a library for all you know), you are also transferring all that data for every page request. I really do think you should reconsider this approach. The bottom line is that anything sent to or received from the user is insecure, and any security that can be added beyond SSL is easily worked around. And SSL is rendered moot for users who gain browser access to an authenticated session. Security, I believe, is a matter of pushing vulnerabilities into a corner. You can't ever make any system completely secure, as such a system would be virtually useless. "The only secure computer is one that's never switched on." Can't remember who said that, but it's completely true. However, the essence of a secure web application, for me, lies in not sending anything to the client that the client doesn't need to know about. Well, if you use COOKIES, you can pass a secondary hash key that can be > used > to validate the actual key against a footprint for a visitor (from > $_SERVER). Salt in a date/timestamp and SHA1 or other, and I feel like > that's a pretty good way to check against a visitor. I just think it feels > flimsy to validate a user on a SESSION key only. Indeed, you can validate a session by using certain information from the $_SERVER array, but bear in mind that none of it is necessarily persistant. I don't know of any examples, but I'm sure somewhere there is a crappy browser that changes its user agent for every request. However, of all the options I think the user agent is your best bet if you really feel you need to worry about it. What happens if someone is behind a proxy? Never tested that, but if someone were to make a proxy sanitizer that purposefully skewed what it reports in the headers, that approach could be difficult to troubleshoot. This is precisely my point. At some point you have to ask yourself whether it's worth worrying about? If you're dealing with high-value transactions then you probably need something more akin to a client-server solution than a web-based solution. That way you can control the client-side a lot better than you can in a web-based application. In your comment above you seem to be suggesting passing that "secondary hash key" between requests via a cookie. Why not just store that in the session? Then it doesn't go outside your app. And as mentioned previously you have a lot more control over the session data than you do over cookie data. The whole point of using a shared hash is to provide notional benefit
Fwd: [PHP] Re: a question on session ID and security
On 5/29/07, Stut <[EMAIL PROTECTED]> wrote: Don't get me wrong, I don't want to discourage anyone from thinking about ways to improve it, but personally I consider this issue done to death. Well, I think the difference is that you send one key (a session identifier) and hash on user agent report, while I send an authentication key and a secondary hash key stored in cookies. I'm sending only nominally more information than you are, so I don't think there's THAT much difference between what we're saying here. As a lot of users would store session id's as cookies, and fall back to a query string id, like I said, I don't see much of a difference in our approaches, except you don't seem to think mine is acceptable since it's not a "session" id. If you supply the salt (instead of relying on it being provided, vis a vis, user agent report), and store that in a cookie on the client, and then that client can't reproduce an accurate, unchanged version of that cookie, what change in either the salt and/or the auth id would make this approach unacceptable (and not break the authentication)? I see major web firms use cookies all the time, so I'm not sure why there is a bias against cookies, besides a user that doesn't support cookies in the first place (which is a real concern, I admit). I remember a poster on a wall of a tech dept my friend worked for that had a faux-advert for a "security dongle" for a computer. Essentially, it was a rubber stopper that was put on a power cable that provided a "100% secure air gap." Whether it's been settled or not, I'm not nearly as played out on discussing it (especially if I'm not getting aspects correct) as I am about browser bickering, OS wars, and all the other "dispassionate" discourse currently "enlightening" the internet. At least with security, there's some known benefit to discussing it! -- Jared Farrish Intermediate Web Developer Denton, Tx Abraham Maslow: "If the only tool you have is a hammer, you tend to see every problem as a nail." $$ -- Jared Farrish Intermediate Web Developer Denton, Tx Abraham Maslow: "If the only tool you have is a hammer, you tend to see every problem as a nail." $$
Re: [PHP] Re: a question on session ID and security
That's not what I'm saying. My basic question is why send the "secondary hash key" to the client when it doesn't need it? Use the authentication key to identify the users data, then get the "secondary hash key" from that data. The browser never needs to see the hash, and from a purist security point of view it could potentially reveal more about your security methods than you need to. The idea is that the secondary hash key replaces the user agent sniff. But the point here is that both pieces of information required to authenticate that client are stored on the client. If someone can get one of them they can get the other, so it's no more secure than just accepting the one cookie without bothering to authenticate it in any way. The token isn't any more secure than tokenizing a user agent and salting it into a digest. The client still knows what their user agent string says, and this string can also be guessed (how random can they be?), but at least you can manipulate a secondary hash key per day/hour, week, whatever. I have nothing against cookies at all, but I think the line between cookies and session data is pretty clear. I would just ask where? (No, really.) If it was clear, then a link to a tutorial on PHP session security is helpful. Cookies should be used to... a) remember a user between sessions (but not authenticate them) b) remember a session ID during a session c) remember user preferences for anonymous users, or where there is no such concept as users on the site I agree 100% on everything except the logic on authentication. How would you finish the following: Sessions should be use to... a) ? b) ? c) ? Sessions should be used for everything else. If you're finding that you're storing huge amounts of data in cookies, switch to using sessions. If you find that you're storing so-called "sensitive" information in cookies, switch to sessions. I don't store anything in cookies that are meant to be useful on the server-side, save an auth string and a corresponding generated salt. This will probably change on my next big project, but for the moment, I'm not much of a fan of SESSIONS that persist. This is based on limited experience and anecdotal evidence, so opinions may very. I'm more than happy to discuss it, but please tell me you got the point about whatever extra security is possible is likely to have been added by the majority of web application platforms, including PHP. Of course. We're talking methodology (implementation of what is available), so I'm not sure why you feel the above is necessary. I'm all for talking about it and seeing if there is a better way, but I also know that people far smarter than me have been talking about it for over 20 years, and what we have is what they've come up with. Ignoring the other possibilities like client certificates there's not really anything more you can do without introducing the possibility or even likelihood that the user experience will be shafted. If it's an accepted methodology, please describe the entire methodology. If you think it's obvious, it should be easy, and a link is beneficial. I do think the stated best practice of SESSIONS, at this point, probably does need to be described to be further useful as a topic of discussion. I've been a little unclear in some things, so I get the feeling we've got the same point of view, with one slight deviation (I think it's slight...).
Re: [PHP] Re: a question on session ID and security
On 5/29/07, Jared Farrish <[EMAIL PROTECTED]> wrote: I do think the stated best practice of SESSIONS, at this point, probably does need to be described to be further useful as a topic of discussion. I've been a little unclear in some things, so I get the feeling we've got the same point of view, with one slight deviation (I think it's slight...). Just thought I'd post this: Primer on PHP session security: http://www.php-mag.net/itr/online_artikel/psecom,id,513,nodeid,114.html -- Jared Farrish Intermediate Web Developer Denton, Tx Abraham Maslow: "If the only tool you have is a hammer, you tend to see every problem as a nail." $$
Re: [PHP] Re: a question on session ID and security
Jared Farrish wrote: That's not what I'm saying. My basic question is why send the "secondary hash key" to the client when it doesn't need it? Use the authentication key to identify the users data, then get the "secondary hash key" from that data. The browser never needs to see the hash, and from a purist security point of view it could potentially reveal more about your security methods than you need to. The idea is that the secondary hash key replaces the user agent sniff. But by doing that you're exposing how your app validates the authentication key, leaving it open to being transferred to another machine. But the point here is that both pieces of information required to authenticate that client are stored on the client. If someone can get one of them they can get the other, so it's no more secure than just accepting the one cookie without bothering to authenticate it in any way. The token isn't any more secure than tokenizing a user agent and salting it into a digest. The client still knows what their user agent string says, and this string can also be guessed (how random can they be?), but at least you can manipulate a secondary hash key per day/hour, week, whatever. It's actually less secure than using the user agent because someone looking at the cookies on the client gets no indication that you're using the user agent to verify that it's the same client making the request. I have nothing against cookies at all, but I think the line between cookies and session data is pretty clear. I would just ask where? (No, really.) If it was clear, then a link to a tutorial on PHP session security is helpful. I've asked the internals list why PHP doesn't natively validate the session ID by using the user agent or other variables because I actually don't know the reasoning behind it. I'll let you know what they say. Cookies should be used to... a) remember a user between sessions (but not authenticate them) b) remember a session ID during a session c) remember user preferences for anonymous users, or where there is no such concept as users on the site I agree 100% on everything except the logic on authentication. How would you finish the following: Sessions should be use to... a) ? b) ? c) ? a) Store data between requests b) There is no B That's the definition of a session. It's a server-side store of data related to a single user of a web application. Sessions should be used for everything else. If you're finding that you're storing huge amounts of data in cookies, switch to using sessions. If you find that you're storing so-called "sensitive" information in cookies, switch to sessions. I don't store anything in cookies that are meant to be useful on the server-side, save an auth string and a corresponding generated salt. This will probably change on my next big project, but for the moment, I'm not much of a fan of SESSIONS that persist. This is based on limited experience and anecdotal evidence, so opinions may very. By "sessions that persist" do you mean sessions that live on between visits by a user? If so then that's a totally different kettle of fish and IMHO should be avoided at all costs. I'm more than happy to discuss it, but please tell me you got the point about whatever extra security is possible is likely to have been added by the majority of web application platforms, including PHP. Of course. We're talking methodology (implementation of what is available), so I'm not sure why you feel the above is necessary. Look at the session facilities provided by any web development platform. They all work the same was as PHP sessions, that is to say storing a session ID in a cookie or passing it in URLs. I'm not aware of any system that uses extra validation, and the reason for that is that there is no guaranteed method. But you're right, the everybody-else-does-it-that-way argument is never very strong, but I think it's worth noting. As mentioned earlier, I have asked the internals list to give a reason why the session extension does no additional validation. I'm all for talking about it and seeing if there is a better way, but I also know that people far smarter than me have been talking about it for over 20 years, and what we have is what they've come up with. Ignoring the other possibilities like client certificates there's not really anything more you can do without introducing the possibility or even likelihood that the user experience will be shafted. If it's an accepted methodology, please describe the entire methodology. If you think it's obvious, it should be easy, and a link is beneficial. 20 years was an exaggeration given the age of the web, but the need to persist data related to any given user of a website between requests has been an issue for well over 10 years. The first "solution" was cookies. The problem with cookies is that they're very inefficient and insecure. Inefficient because they get transferred with eve
Re: [PHP] Re: a question on session ID and security
But by doing that you're exposing how your app validates the authentication key, leaving it open to being transferred to another machine. True. Although I'm only exposing a part of the auth chain, not *how* that is constructed to produce the actual authentication token. It does not, however, tie the session to a specific browser instance on a remote machine; this is a problem. Of course, if the hash token uses the reported UA when created... :P It's actually less secure than using the user agent because someone looking at the cookies on the client gets no indication that you're using the user agent to verify that it's the same client making the request. But as you said, it's a reasonable thing to guess that it's being used as a salt or verifier, and may be spoofed using semi-random UA strings if you are testing for remote session hijacking weaknesses. If my salt changes according to a time/date/other, or is produced at random (somehow), even if it is transferred, it should still expire and be invalid by my own control. I've asked the internals list why PHP doesn't natively validate the session ID by using the user agent or other variables because I actually don't know the reasoning behind it. I'll let you know what they say. I would think it's because browsers are flaky and you can't really rely on them, and that means you can't build it into the system check. That's the definition of a session. It's a server-side store of data related to a single user of a web application. I think this is another reason why the internals don't support authentication of sessions. Is it up to a session to authenticate itself? Should it be? What if you wanted to override that behavior? By "sessions that persist" do you mean sessions that live on between visits by a user? If so then that's a totally different kettle of fish and IMHO should be avoided at all costs. I agree. :D Look at the session facilities provided by any web development platform. They all work the same was as PHP sessions, that is to say storing a session ID in a cookie or passing it in URLs. I'm not aware of any system that uses extra validation, and the reason for that is that there is no guaranteed method. Ah, so. You are right... But you're right, the everybody-else-does-it-that-way argument is never very strong, but I think it's worth noting. I don't mind "this is standard practice," but EXPLAIN what you mean. What standard practice? This is an area that I want my knowledge to overlap others... Bruce Schneier, in all his glory, makes this point about roll-your-own security solutions: Bruce Scheier, http://www.schneier.com/essay-031-ft.txt The submission document for the algorithm I submitted with my colleagues at Counterpane was the length of a book. This [make hashing algorithms] is hard to do. But even normally rational people tend to be blinded by a bright shiny new algorithm. It seems so easy. The unfortunate truth is anybody can design an algorithm that he himself cannot break. It's actually profound. Anyone out there, from the best cryptographer to the random person on the street, can sit down with a pencil and paper, design an algorithm and say, "I can't break it." And then here's the fallacy—because you can't break it, you make the following assumption: "Therefore, it must be secure." So we end up with lots of proprietary algorithms. We have a lot of amateur cryptanalysts who will design the algorithms, do some work and then say, "Look I can't break it, therefore it's secure." My feeling is that if the designers haven't proven themselves by breaking several published algorithms, why should I look at their designs? The odds of them being secure are pretty negligible. Indeed, the top five AES candidates—this is top five based on a formal poll of cryptographers—were actually designed by teams that have cryptanalysts on them. They seem to be the fastest, the most elegant, the best performing, the ones that seem to be the most secure. Still, nobody trusts them—give us a couple of years to stare at them. Eventually, we're going to have a new standard. There's no reason that I can think of ever to use a new and unanalyzed algorithm. There's never any benefit. There might be the personal pride of the designer. Other than that, you might as well use a known algorithm. So the moral there is "never, ever trust a proprietary algorithm." I have to admit that some of this back-and-forth comes from my desire to get what I want out of your responses, which I know is probably a little frustrating. How do people who know little about PHP know what session best practices are, spelled out? I'm not a noob, but I've still learned a good deal from your responses that I didn't know before. What about the OP? 20 years was an exaggeration given the age of the web, but the need to persist data related to any given user of a website between requests has been an issue for well over 10 years. Sure, but referring to how l
Re: [PHP] Re: a question on session ID and security
Jared Farrish wrote: I've asked the internals list why PHP doesn't natively validate the session ID by using the user agent or other variables because I actually don't know the reasoning behind it. I'll let you know what they say. I would think it's because browsers are flaky and you can't really rely on them, and that means you can't build it into the system check. I'm not sure how much closer to the horses mouth I can get... http://marc.info/?l=php-dev&m=118046750523448&w=2 That's the definition of a session. It's a server-side store of data related to a single user of a web application. I think this is another reason why the internals don't support authentication of sessions. Is it up to a session to authenticate itself? Should it be? What if you wanted to override that behavior? Seeing as how the session functionality is provided through an extension, overriding it is simplicity itself. Plus there is already a way to implement a session handler in user space. I don't mind "this is standard practice," but EXPLAIN what you mean. What standard practice? I'm sorry, I had assumed you knew how PHP sessions work. When a session is created it is assigned a unique ID. That ID is transported between the client and the server on each request. The server uses that ID to identify which session it is, get the data and make it available to the scripts. I have to admit that some of this back-and-forth comes from my desire to get what I want out of your responses, which I know is probably a little frustrating. How do people who know little about PHP know what session best practices are, spelled out? I'm not a noob, but I've still learned a good deal from your responses that I didn't know before. What about the OP? If there's anything you want me to go into in more detail please just ask. I certainly don't think I know it all, but I've been around this block more than a few times. On the other hand I'm always open to the possiblity that there's a better way(tm). In all reality, I actually agree with you about sessions in my heart-of-hearts (maybe a little more now after this thread), as they are the simplest to implement, and the checks performed on authentication are as robust as any involving cookies (which can become hopelessly bogged down in checks, digests, and rechecks), although I posit the SAME thing can be achieved with instances of cookies. However, simplicity should be the operative word, and the complexity of the approach I have described is more than a little troublesome. The same "functionality" can be achieved with cookies, just like the functionality of a calculator can be achieved with an abacus. I appreciate that you posted the historical information on sessions and cookies. Whether it's accurate to reality, I don't know, but it makes sense, not lemons, so for now, it's good enough for me! It was definitely abridged, but that's the jist of how sessions evolved. p.s. Maybe everyone wasn't around when that history occurred... Don't throw your youth at me, it's unlikely to help. -Stut -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: a question on session ID and security
On Tue, May 29, 2007 7:42 am, Stut wrote: > Here one final thought... if there was a reliable way to add security > to > sessions don't you think that one of the multitude of web development > languages out there would have done it, including PHP? Several reliable security additions have been discussed in this thread; But they are not "general purpose" to be built-in to PHP. -- Some people have a "gift" link here. Know what I want? I want you to buy a CD from some indie artist. http://cdbaby.com/browse/from/lynch Yeah, I get a buck. So? -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: a question on session ID and security
On Tue, May 29, 2007 10:36 am, Jared Farrish wrote: >> But the point here is that both pieces of information required to >> authenticate that client are stored on the client. If someone can >> get >> one of them they can get the other, so it's no more secure than just >> accepting the one cookie without bothering to authenticate it in any >> way. > > The token isn't any more secure than tokenizing a user agent and > salting it > into a digest. The client still knows what their user agent string > says, and > this string can also be guessed (how random can they be?), but at > least you > can manipulate a secondary hash key per day/hour, week, whatever. The token is LESS secure, because it's obvious what you are doing -- You are sending out a clear red flag to a Bad Guy that they need this extra token to get back in. If they can get the first cookie, they can get the second just as easily. You've added zero extra security. -- Some people have a "gift" link here. Know what I want? I want you to buy a CD from some indie artist. http://cdbaby.com/browse/from/lynch Yeah, I get a buck. So? -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: a question on session ID and security
On 5/30/07, Richard Lynch <[EMAIL PROTECTED]> wrote:> If they can get the first cookie, they can get the second just as easily. I thought this said "just as weasily" at first, and I thought, "Ain't that the truth..." -- Jared Farrish Intermediate Web Developer Denton, Tx Abraham Maslow: "If the only tool you have is a hammer, you tend to see every problem as a nail." $$
Re: Fwd: [PHP] Re: a question on session ID and security
Jared Farrish wrote: On 5/29/07, Stut <[EMAIL PROTECTED]> wrote: Don't get me wrong, I don't want to discourage anyone from thinking about ways to improve it, but personally I consider this issue done to death. Well, I think the difference is that you send one key (a session identifier) and hash on user agent report, while I send an authentication key and a secondary hash key stored in cookies. I'm sending only nominally more information than you are, so I don't think there's THAT much difference between what we're saying here. As a lot of users would store session id's as cookies, and fall back to a query string id, like I said, I don't see much of a difference in our approaches, except you don't seem to think mine is acceptable since it's not a "session" id. That's not what I'm saying. My basic question is why send the "secondary hash key" to the client when it doesn't need it? Use the authentication key to identify the users data, then get the "secondary hash key" from that data. The browser never needs to see the hash, and from a purist security point of view it could potentially reveal more about your security methods than you need to. If you supply the salt (instead of relying on it being provided, vis a vis, user agent report), and store that in a cookie on the client, and then that client can't reproduce an accurate, unchanged version of that cookie, what change in either the salt and/or the auth id would make this approach unacceptable (and not break the authentication)? I see major web firms use But the point here is that both pieces of information required to authenticate that client are stored on the client. If someone can get one of them they can get the other, so it's no more secure than just accepting the one cookie without bothering to authenticate it in any way. cookies all the time, so I'm not sure why there is a bias against cookies, besides a user that doesn't support cookies in the first place (which is a real concern, I admit). I have nothing against cookies at all, but I think the line between cookies and session data is pretty clear. Cookies should be used to... a) remember a user between sessions (but not authenticate them) b) remember a session ID during a session c) remember user preferences for anonymous users, or where there is no such concept as users on the site Sessions should be used for everything else. If you're finding that you're storing huge amounts of data in cookies, switch to using sessions. If you find that you're storing so-called "sensitive" information in cookies, switch to sessions. I remember a poster on a wall of a tech dept my friend worked for that had a faux-advert for a "security dongle" for a computer. Essentially, it was a rubber stopper that was put on a power cable that provided a "100% secure air gap." Whether it's been settled or not, I'm not nearly as played out on discussing it (especially if I'm not getting aspects correct) as I am about browser bickering, OS wars, and all the other "dispassionate" discourse currently "enlightening" the internet. At least with security, there's some known benefit to discussing it! I'm more than happy to discuss it, but please tell me you got the point about whatever extra security is possible is likely to have been added by the majority of web application platforms, including PHP. I'm all for talking about it and seeing if there is a better way, but I also know that people far smarter than me have been talking about it for over 20 years, and what we have is what they've come up with. Ignoring the other possibilities like client certificates there's not really anything more you can do without introducing the possibility or even likelihood that the user experience will be shafted. -Stut -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
