Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>It's not such a problem to implement a remember-me. What you need to do is to keep the session alive for long (and set the cookie to last long). Even Gmail will log you out after certain period (I think it's two weeks or a month). However, you need to realize that keeping the same session open longer increases the possibility to hijack into it. As a countermeasure, you need to increase the strength of your session identifier. Session identifier is the one that is in the cookie (or in the URI as commonly seen in some software as "file.php?PHPSESSID=1234...").</p> <p>The key is to maintain a strong session identifier. For example, in Gmail, you have a cookie GX with a value similar to </p> <pre><code>DQAAAJoAAAA8mnjaAwgkS7y8Ws5MYCl-PAQLp9ZpMXpGKR47z4L9mlBH-4qEyApAtFbnLkzv1pPqxua1hOWMGiKYpBZr-h7Icyb-NUUg2ZW_nUFIymvw9KjmjSECYTowbCsDerkAxCzSDa83b5YC1mykPv1a9ji4znt6Fsna-AKgNTntvmUxeJ92ctsSlg9iGySEmXnisVyyJiQvI8jzbZqSpE_N2RKZ </code></pre> <p>The reason why Session Hijacking is pretty much impossible is, because the session identifier is so strong, and because the site utilizes HTTPS everywhere. No one can guess or otherwise get your session identifier (thus can't hijack into your session). On a quick look, the session identifier above seems to have somewhat ~1250-bits of strength, 1*10^376 different possibilities. No one can guess that.</p> <p>Obviously there will be always potential ways to still hijack into the session. For example, XSS vulnerabilities open the door way to get your cookies and therefore your session identifier, but this isn't your sessions fault in any way, and has nothing to do with a "remember-me".</p> <blockquote> <p>I'm concerned of the fact that even if the login process happened under a https connection, on every subsequent http request the cookie will be sent unencrypted on the net.</p> </blockquote> <p>If you set the cookie secure flag to true while in HTTPS, the cookie will never be sent when accessing the site via HTTP. It is a must to do for HTTPS-only sites.</p> <p>In general, people seem to only use HTTPS for the log-in page, which is wrong. If one really cares, he should use HTTPS all over the page. Otherwise, it's impossible to prevent all Session Hijacking attempts.</p> <p>Why do many still use HTTPS just for the log-in part? Probably because they don't realize what's in the stakes, or because it's too CPU heavy to use HTTPS everywhere. However, it's still better to use HTTPS for the log-in than not to use it anywhere - because it encrypts the credentials (thus only the session identifier can be stolen later on, not the actual credentials during log-on).</p> <blockquote> <p>Maybe not facebook(I don't care of it) but with Gmail if you don't set 'Use always https' an http connection will be used and it will send your unencrypted tokens over internet. What do you think?</p> </blockquote> <p>I think the value should default to HTTPS in all cases if possible. The only real reason as to why not use HTTPS is money (=performance/hardware).</p>
    singulars
    1. This table or related slice is empty.
    1. PO'Remember-me' authentication feature, does it always mean 'Unsecure' Website?
      singulars
      1. PTQuestion
    1. PTAnswer
    1. This table or related slice is empty.
    1. USTower
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. PO'Remember-me' authentication feature, does it always mean 'Unsecure' Website?
      singulars
      1. PTQuestion
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTDownMod
    3. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. COAny identifier sent in plain text, no matter how long, isn't secure if I can just steal it via man-in-the-middle with a hostile router and use it in my own requests. A stolen token doesn't need to be decrypted to be used in a replay attack. It might make guessing an authentication token hard / impossible, but that's not what was being asked.
      singulars
      1. PO
      1. USRobert Paulson
    2. COAs I said, if one doesn't use HTTPS, it's impossible to prevent all Session Hijacking attempts.
      singulars
      1. PO
      1. USTower
    3. COSo, I'm now logged-in here in SO. If I click 'Ask a question' I'll post my new question over plain Http. Basically everybody can intercept the request's Cookies and reuse them to send new questions as 'al nik'... is this correct?
      singulars
      1. PO
      1. USmickthompson
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload