Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>I'd only suggest public key encryption if you want the ability to set a user's password without their interaction (this can be handy for resets and shared passwords).</p> <h1>Public key</h1> <ol> <li>The <a href="http://www.php.net/manual/en/book.openssl.php" rel="noreferrer">OpenSSL</a> extension, specifically <code>openssl_public_encrypt</code> and <code>openssl_private_decrypt</code> </li> <li>This would be straight RSA assuming your passwords will fit in key size - padding, otherwise you need a symmetric layer</li> <li>Store both keys for each user, the private key's passphrase is their application password</li> </ol> <h1>Symmetric</h1> <ol> <li>The <a href="http://www.php.net/manual/en/ref.mcrypt.php" rel="noreferrer">Mcrypt</a> extension</li> <li>AES-256 is probably a safe bet, but this could be a SO question in itself</li> <li>You don't - this would be their application password</li> </ol> <h1>Both</h1> <p><code>4</code>. Yes - users would have to enter their application password every time, but storing it in the session would raise other issues</p> <p><code>5</code>.</p> <ul> <li>If someone steals the application data, it's as secure as the symmetric cipher (for the public key scheme, it's used to protect the private key with the passphrase.)</li> <li>Your application should definitely be only accessible over SSL, preferably using client certificates.</li> <li>Consider adding a second factor for authentication which would only be used once per session, like a token sent via SMS.</li> </ul>
 

Querying!

 
Guidance

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