Show HN: Portable Secret – How I store my secrets and communicate privately
This has some desirable security properties, but I would like to see more analysis on the security side (not just: is secure or is not secure).<p>Passwords:<p>- Easy to memorize. Pro: Does not rely on a device, can be recovered if devices stolen.<p>- Easy to phish. Con: Attacker can use a look-a-like page, click-jacking, and pixel extraction (frame stealing) attacks to get password &amp; secret.<p>- Easy to brute force. Con: Relies on human adherence to password best practices to maintain sufficient entropy. Learning from industry that this does not work in widespread adoption. This will work for certain power users.<p>Cryptography:<p>- Uses current state of art algos. Pro: Resistant to access by known methods.<p>- Will become obsolete. Con: Eventually the secrets will become exposed due to advances in crypt-analysis. Mitigation: Don&#x27;t store anything to remain secure for decades, shorter lived is okay.<p>- Secrets are encrypted once. Con: Any issue (there have been many) in WebCrypto implementation at time of encryption can not be fixed by browser upgrade (because of secret caching).<p>- Secrets can be extracted from page and cracked elsewhere offline. Note: Security features such as timers, throttling, guess limits can not be enforced. They must be implemented e.g. in PBKDF.<p>Client Side Security:<p>- Cached objects. Note: For example a web page with browser vulnerability can walk JS objects and get existing secrets. Browser may also cache secrets, passwords, inputs, images to disk where they are not protected.<p>- Web Browser WebCrypto and Same Origin Bypasses. Pro: Browsers have updates and are constantly being improved to enforce security model. Con: The direction the W3C goes in future (tens of years) is not certain and security model may change. Implementation issues in browser web APIs and Same Origin (common) can put secrets at risk.<p>- Secret hosting. Con: Hosting content on other servers (e.g. github) may not allow management of access control. For example hosting on one subdomain could now or in future allow JS on sister pages to interact with page and the resources loaded, enabling side-loading attacks in JS. This may not be in control of victim if they uploaded their secret to be hosted by another party.<p>- Trusted hosting. Con: Any untrusted source of HTML can steal the secrets, e.g. by serving malicious javascript along with the secret. This means the security of the hosting party and trust in the hosting party is required. (Note: this con was added in an edit)