Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>If we're talking about <strong>not possible</strong> then the second part to S.L. Barth's answer will achieve this with the exception that the key exchange must be done by some other means. This can be the phone or email or even another website but if it's done via your website then it's open to a <a href="http://en.wikipedia.org/wiki/Man-in-the-middle_attack" rel="nofollow">man-in-the-middle attack</a>. You can tell your users to do this, you just can't actually help them do it.</p> <p>There is probably a javascript library somewhere that will implement GPG encryption so that all you have to do is make sure that every message is encrypted in the browser before it's sent to your web server. You can store the messages as long as you like, they're encrypted. Only the user with the correct private key will be able to decrypt it.</p> <p>SSL and TLS as they are used by websites everywhere are vulnerable to man-in-the-middle attacks. The reason we don't hear much about these sorts of attacks is that most of the people in the middle are trustworthy so the attacks simply don't happen. The recent revoking of the CA certificates of <a href="http://en.wikipedia.org/wiki/DigiNotar" rel="nofollow">DigiNotar</a> and others was precisely because the Iranian Government were caught acting as a man-in-the-middle and decrypting their own citizen's SSL traffic.</p> <p>If you're happy with preventing casual snooping by curious sysadmins, the key exchange can be done through your website as well.</p> <p>One more thing: Security is hard.</p> <p>Even if you do this with well-known encryption techniques, the chances of there being a flaw in the implementation will be very close to 1. This doesn't mean that those curious sysadmins will be able to accidentally read messages but it does mean that a determined and skilled adversary will be able to find a way in. As soon as you can afford it you should hire an expert to redesign or at the very least examine your protocol and implementation.</p>
    singulars
    1. This table or related slice is empty.
    1. POCiphertext on server
      singulars
      1. PTQuestion
    1. PTAnswer
    1. This table or related slice is empty.
    1. USLadadadada
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    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. VTUpMod
    1. CO+1 even though I'm not that pessimistic about flaws in crypto implementations. Also I think that SSL and TLS are not vulnerable to man-in-the-middle attacks by design. It's all about who you trust.
      singulars
      1. PO
      1. USMBober
    2. CO@MBober SSL/TLS are designed for client-server communication, not client-server-client without the server reading anything. Of course, you could tunnel SSL over a pair of normal socket connections, but still the clients need some way of identifying each other.
      singulars
      1. PO
      1. USPaŭlo Ebermann
 

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