Hacker News Reader

Comment by yjftsjthsd-h | Hacker News Reader

I thought audits were usually of the form "I looked for vulnerabilities in this code, and found the following", which isn't really a value assesment. I mean, yes, the point of doing that is to have the basis on which to form an opinion about "is this software safe/secure?" which is absolutely a value judgment and at least partially subjective, but I didn't think the audit itself tended to concern itself with that?

View on HN

IMHO an audit should always report about how readable a codebase is, because it's a dependency for the quality of the audit. E.g when the 1st kubernetes audit pointed out that the (side-)effects of certains operations are too complex to understand, this gives some insight about the height of the possibility for uncaught bugs and the possibility to introduce new bugs.

Most important any audit should state methodology and assumptions and report findings based on this.

My big problem with KeepassXC is that the threat model is not well documented. It does a lot of fuzz around memory randomisation but it might be much easier to extract the secret key of the browser extension when unlocked. So I guess it mostly provides security for data at rest, but afaik this is not documented. A general security audit is IMHO difficult if nobody states any guarantees.

If the browser extension allowed leakage, I'd expect it to come from prepared pages and a JS exploit that can fake other origins, or from some stupid DOM information leak of the injected popups.

From each other, WebExtensions are sandboxed pretty well as far as I know.

I guess you're safe if you stick to always manually allow the password request and of course, practise the same amount of scrutiny regarding phishing as when entering passwords manually.

Or are you talking about the IPC between the browser and the KPXC app?

Reply on news.ycombinator.com