diff --git a/Site/2013-05/security.html b/Site/2013-05/security.html index 8e28554f..78255f7c 100644 --- a/Site/2013-05/security.html +++ b/Site/2013-05/security.html @@ -340,21 +340,21 @@
This trade-off is a direct result of the desire to create a stateless solution which is immune to data loss. The solution relies entirely on the master password you can remember, which means that the only point of failure is now entirely under your control.
The Master Password application however functions as a hybrid password manager, implementing both the Master Password algorithm and a vault-like password solution. In the second mode, Master Password uses your master key to encrypt custom passwords and store the encrypted result in a vault. Since we use the master key for this process, the result is a vault that is much harder to break into than that used by many other vault-based password solutions (specifically because the encryption key is a large key derived from your master password using scrypt key derivation). As a result, this trade-off has been mitigated.
This decision has been made in the interest of password recovery after a total loss scenario. Recovering the correct password for sites that use such custom templates would be extra difficult, since now you're forced to recall the specific custom template you drafted for this site. This problem becomes more difficult the more sites you've made custom templates for.
As a partial mitigation of this trade-off, we've created a set of password templates designed to cover nearly all use cases. The default template should work on nearly all websites. When this template fails, it's usually because the site imposes a low maximum-password-length restriction. This type of restriction is a serious red flag which almost always indicates a sloppy security implementation on their end. When you encounter it, you should @@ -362,7 +362,7 @@
A vault-based password manager is often considered two-factor, since it relies on your vault password as well as access to your vault file. Most security experts disagree, however. To be truly multi-factor, the security factors should come from separate categories:
diff --git a/Site/2013-05/sync b/Site/2013-05/sync index 0aa09492..cb65aefb 100755 --- a/Site/2013-05/sync +++ b/Site/2013-05/sync @@ -2,5 +2,5 @@ set -e cd "${BASH_SOURCE[0]%/*}" -s3cmd sync --exclude '.git/**' --delete-removed --follow-symlinks --preserve --acl-public --reduced-redundancy . s3://masterpasswordapp.com/ -rsync -avPL --no-group . satura.lyndir.com:/usr/local/www/masterpasswordapp.com/htdocs-secure/ +s3cmd sync --exclude '.git/**' --follow-symlinks --preserve --acl-public --reduced-redundancy "${@:-.}" s3://masterpasswordapp.com/ +rsync -avPL --no-group "${@:-.}" satura.lyndir.com:/usr/local/www/masterpasswordapp.com/htdocs-secure/