StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<p>For login, SSL should be your option, even at this point. If it's just for login, you don't need an expensive SSL farm, but at least you protect the (use-for-everything-kind) password, even though it's clear, that the remaining communication isn't secured <sup>[*]</sup>. This may mean, that you need to buy a certificate for just one login server, which can again save you a lot of money, depending on the certificate vendor.</p> <p>For GWT, if you can't afford to encrypt all communication, you'll have to put the login on a separate page due to Same Origin Policy constraints.</p> <p>If that still isn't an option, you can think about logging in via <a href="http://en.wikipedia.org/wiki/Openid" rel="noreferrer">OpenID</a>, just like stackoverflow does.</p> <p>There can't be <em>any</em> secure communication over insecure media without <em>some</em> pre-shared secret - usually provided by the root certificates that are installed in a browser (BTW, it's funny/scary that browsers and even entire operating systems are usually downloaded via HTTP). Other systems, e.g. PGP, rely on previously established trust in a <a href="http://en.wikipedia.org/wiki/Web_of_trust" rel="noreferrer">"Web Of Trust"</a>, but this is just another form of pre-shared secrets. There's no way around it.</p> <p><sup>[*] Using SSL for everything - unfortunately - comes with additional practical problems: 1) Page loads are a lot slower, especially if you have many elements on the page. This is due to SSL-induced round trips and the resulting latency, which you can't counter with even the fastest SSL farm. The problem is mitigated, but not fully eliminated by keep-alive connections. 2) If your page includes elements from foreign, non-HTTPS sites (e.g. images inserted by users), many browsers will display warnings - which are very vague about the real security problem, and are therefore usually unacceptable for a secure site.</sup></p> <p><strong>A few additional thoughts (not a recommendation)</strong></p> <p>Let's assume the worst case for a moment, i.e. that you can't use SSL at all. In that case, maybe surprisingly, hashing the password (with a salt) before transmitting it, may actually be a bit better than doing nothing. Here's the reason: It can't defeat Mallory (in cryptography, a person who can manipulate the communication), but at least it won't let Eve (a person who can only listen) read the plaintext password. This may be worth something, if we assume that Eves are more common than Mallorys (?) But note, that in that case, you should hash the password <em>again</em> (with a different salt), before comparing it with the database value.</p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

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