analogist

Security paradigms have been steadily moving beyond a hard-boundary-soft-center, to a defense-in-depth, distrust-your-own-services model. I was alarmed to learn last year, for example, that you use OpenVPN with fixed symmetric keys (--secret) rather than TLS with any forward secrecy (--tls-auth) for VPN between your NYI and AMS datacenters. https://blog.fastmail.com/2016/12/19/secure-datacentre-inter...

Presumably, running datalinks like this means you would have to have perfect trust in your long term key management and rotation. Is that something you plan on improving in the future?

Similarly -- I stumbled on this entirely by accident after your blog post about moving datacenters -- that your head of security ops & infrastructure tweeted "I will probably root my phone soon because Samsung's emoji set is worse than not having convenient OTA updates" https://twitter.com/robn/status/919194089920311296

I don't want to conflate anything -- a tweet on an engineer's own time about their personal devices isn't by itself a security problem. But it does reflect on the security mindset. If you had a BYOD policy, and this phone did end up being flashed to Lineage and be 3 patch levels behind (esp with Android's track record of RCE-via-media CVEs), this could definitely become a weakness on your entire infrastructure, and thereby on all of us as customers.

This is the type of thing I couldn't shake after learning about it. Of course, trust has to be placed somewhere. You have to be able to place trust on your ops and your infrastructure, but that's also a process, not a checkbox. People and devices can be trusted a little less in the overall security system, to provide redundant security. Could you clarify your position on how your staff is trained about the human weak points, security as a lifestyle if you're security and ops, and how your security mindset incorporates defense in depth?

https://tonyarcieri.com/4-fatal-flaws-in-deterministic-passw...

Certainly you’ve considered these points, and I’m interested in hearing your responses to these points if you’re using this scheme yourself and want others to use it.

I’m particularly interested in point 4 where, unlike traditional password managers like 1Password and Lastpass, where you need both the password and some form of data access, the leakage of my master password (say by a shoulder surfing security camera at any time) literally means every credential can be derived from scratch at any time.

[1] https://blog.agilebits.com/2015/11/11/how-1password-for-team... [2] https://1password.com/files/1Password%20for%20Teams%20White%...

Authentication is not done by sending them your encryption password, but instead the derivation of an SRP static secret (https://en.wikipedia.org/wiki/Secure_Remote_Password_protoco...) from your password (PBKDF, XOR'd with HKDF of the entropy-boosting pepper that they call the "Secret Key"), and performing a session key exchange handshake, basically like a (non-ephemeral) Diffie Hellman. They then encrypt all future communications (inside of TLS) with the transient session key.

This gets you three things in one swoop:

- Authentication of user

- Authentication of the server (if the remote server doesn't have the stored RSA counterpart of your derived SRP static secret, the exchange can't complete)

- An additional encrypted tunnel independent of TLS, so transport security isn't reliant solely on TLS (Cloudbleed, etc). (The contents being moved around are encrypted yet again)

And:

- User doesn't have to remember a separate password.

- The password and pepper never touch the network, only (non-reversible) session tokens do.

- Having access to traffic inside of TLS (corporate or malicious TLS endpoint interception, for example) still gets you nothing.

There are valid criticisms of 1Password, but you're literally criticizing them for something they've gone out of the way explicitly spent engineering hours solving in a way that not many services have even bothered thinking about.

If you look at the current cracking benchmarks of GPUs (https://gist.github.com/epixoip/a83d38f412b4737e99bbef804a27...), there is an easily quantifiable difference between bcrypt and MD5: 21 bits. (https://www.wolframalpha.com/input/?i=log2(200*%5E9)-log2(10...)

That means under current GPU architecture, bcrypt is basically like "adding 3-4 characters (or 1.5 diceware words)" for free to your password. Can you basically just add 3-4 characters to your password? Sure, but not without user friction, and certainly you can't think that way as the developer of the system, because you're trying to give a small leg up to even the most vulnerable by salting and bcrypt/PBKDF2/Argon hashing.

What about theoretical limits? Well, there is another way to approach this: Landauer's principle (https://en.wikipedia.org/wiki/Landauer%27s_principle), which considers the theoretical minimum energy of a bit flip of information - so this even covers future computing technologies. Even if you used up all available mass-energy in the entire sun, it is only theoretically possible to perform 2^225.2 operations (https://security.stackexchange.com/questions/6141/amount-of-...). 225 bits of entropy is roughly a 35-character (printable ASCII) password.

(Note that you can't do this with MD5 - it has only a 128-bit hash space, before preimage attacks, the best of which lowers it to 123 bits).

So the lesson is: use slow hashes to give some protection to the vulnerable and people whose password complexity is "on the edge". Use a password manager so that the rest of your passwords can be comfortably > 128 bits in complexity, without reuse. And then forget about passwords because after that, every other part of the security system becomes more important.

Besides blocking entire sections of the net outright (like Google address blocks), poisoning controversial domains, etc, even if it can't directly inspect the traffic due to good encryption (say in the instance of OpenVPN or IPSEC), it will slowly degrade and eventually null-route your traffic over the course of minutes, depending on its judgement of the likelihood (based on packet structure and history) that your activity isn't "normal" usage.

Currently the only functional ways of getting around the GFW is VPN through stunnel (TCP OpenVPN traffic re-wrapped in TLS, thus pretending to be https traffic, and incurring triple TCP performance penalties), similar convoluted protocols like Shadowsocks, obfsproxy, and other China specific tools.

https://ostif.org/the-openvpn-2-4-0-audit-by-ostif-and-quark...

Matthew Green/Cryptography Engineering audit direct link, which focuses more heavily on the protocol design, as well as a 2.2->2.4 changelog audit:

https://www.privateinternetaccess.com/blog/2017/05/openvpn-2...