ntucker

That's a great point about rolling the mapping key. We would likely be dropping all the rows in the password hash table for such an extreme event anyway, though, since otherwise there's no way to garbage collect the orphaned ones.

Yes, but we currently have 2.1 million users, so that's still no small burden. And don't forget that's only after you brute forced the passwords.

Yeah, what I'm getting at is that those posts don't actually come right out and say your code should be calibrating itself regularly. They talk about selecting a work factor by benchmarking your current hardware, but they leave it there, and one might come to the conclusion that once they've measured their hardware, they put "13" in a config file and call it done. I'm advocating for advice like "Don't think about work factors, think about time. Your configuration should be a time value, and when your app starts up, it should compute its own work factor based on this time value." If your code does this, there's no need for rules of thumb like "11 is a good starting point for a bcrypt work factor."

We have an approach to this which doesn't modify the password hashing at all, so it can't possibly reduce the strength: we store users and password hashes (currently bcrypt * ) in two separate tables, and the key used to look up a given user's password hash is an encrypted version of their user id. The encryption key for doing this transformation is loaded dynamically at app startup and has some extra security precautions around storing it, so it's not baked into either the source code or a config file.

The upshot is that if you get a db dump and are able to brute force some bcrypt hashes, you won't know what usernames they go with. If you get a db dump and our source code, you're still out of luck. If you get ahold of an old server hard drive, you're out of luck. If you root a running server and inspect the process memory, you can obtain this key.

This scheme also allows the mapping key to be rolled, which would immediately invalidate all passwords in the system.

*we also version our password hash records so we can migrate from bcrypt to a new scheme fairly painlessly if it's warranted in the future.

Why do articles talking about this always talk about specific work factors and choosing a correct work factor, as if it's fixed? I thought good practice was to choose the work factor dynamically so it's calibrated to whatever hardware you're running today.

Easy enough to include a version number as another arg with the identifier, and include that in the hash. Then all you have to do is keep track of what version each of your passwords is on, which is not sensitive information and could be stored in greppable plaintext.

Me too. And on 34, "You'll see that when the item reaches its flex basis, it stops flexing and something else has to flex" doesn't actually seem to be true. Can't tell if there's a bug or if it's something I've done wrong.

Yeah, I look at it this way: Let's just focus on set B. You're staring at two doors. Some random process decided whether the things behind the doors are a goat and a car (2/3 of the time) or two goats (1/3 of the time). Someone privy to what's behind the doors deliberately opens one to reveal the goat. What changed? Nothing. The random outcome was decided before the door was opened and your odds don't change. That closed door now has a 2/3 chance of having a car behind it.

This looks really great. I watched the video and the rationale and tradeoffs they discussed sounded exactly like conversations we had back when building our system. The FUSE filesystem and agent panics are features that I wish I'd thought of.

> At this point you could have used ssh right away, no? Any reason you used TLS + checking SSH agent instead?

Yeah, using the SSH login method is actually quite slow for something you want to call at app startup on N instances during a push (at a minimum, your process responsible for whatever gatekeeping you do has to be respawned for every request, which necessarily puts a lower bound on the latency). I'm sure this could have been tracked down and optimized, but as jmillikin points out, another downside is that the additional per-user config can get kind of messy and error prone. Implementing logic like this at the .ssh/config level is (in my opinion) kind of easy to goof up and hard to test.

My company has an internal bit of infrastructure that I think is a somewhat novel approach that allows us to never have any secrets stored unencrypted on disk. There's a server (a set of servers, actually, for redundancy) called the secret server, and its only job is to run a daemon that owns all the secrets. When an app on another server is started up, it must be done from a shell (we use cap) which has an SSH agent forwarded to it. In order for the app to get its database passwords and various other secrets, it makes a request to the secret server (over a TLS-encrypted socket), which checks your SSH identity against an ACL (different identities can have access to different secrets) and does a signing challenge to verify the identity, and if all passes muster, it hands the secrets back. The app process keeps the secrets in memory and your cap shell disconnects, leaving the app unable to fetch any more secrets on your behalf.

The other kink is that the secret server itself reads the secrets from a symmetrically-encrypted file and when it boots, it doesn't actually know how to decrypt it. There's a master key for this that's stored GPG encrypted so that a small number of people can retrieve it and use a client tool that sends the secret server an "unlock" command containing the master key. So any time a secret server reboots, someone with access needs to gpg --decrypt mastersecret | secret_server_unlock_command someserver

There are some obvious drawbacks to this whole system (constraining pushes to require an SSH agent connection is a biggie and wouldn't fly some places, and agent forwarding is not without its security implications) and some obvious problems it doesn't solve (secrets are obviously still in RAM), but on the whole it works very well for distributing secrets to a large number of apps, and we have written tools that have basically completely eliminated any individual's need to ever actually lay eyes on a secret (e.g. if you want to run any tool in the mysql family, there's a tool that fetches the secret for you and spawns the tool you want with MYSQL_PWD temporarily set in the env, so you need not copy/paste it or be tempted to stick it in a .my.cnf).

I used to have my retirement accounts at Fidelity. One day I needed some assistance with something I was seeing on their web UI, so I called them up. The support person said (not an exact quote, but the gist), "in order to see what you're seeing, I'm going to need to log in as you. I need your permission in order to do that. Security precautions prevent me from being able to see your password, so I will need to change your password to a temporary password of '123456fidelity' to proceed. Is this ok?"

I was kind of speechless, but I said, no, that's ok, I've decided I don't need help anymore, and shortly thereafter I closed all of my accounts. I've moved to a smaller firm where I've specifically asked for my accounts to be inaccessible from the internet in any way, and I have a financial advisor assigned. If I need something done, I can call him or his assistant. I can't make big financial moves at the click of a button, which suits me just fine.

Oh man, I just discovered the magic of tapping on an unused instrument on the bottom. Build a sequence using no sax and then start wailing away on saxy bill. Wonderful.

This is great. I laughed out loud when I discovered that notes you throw upward off the screen eventually come back down if you throw them straight up. Definitely getting my toddler to play with this.

I have two suggestions: one is a tool/mode that lets you remove a bunch of stuff quickly, and the other is a simple undo mechanism. Since there isn't much instruction, you need to explore by touching, and e.g. when you're testing to see if a three finger gesture does something, you tend to create a lot of unwanted notes and potentially accidentally remove stuff that you overwrite.

If you know your passwords are strong without those requirements, you could always come up with a standard prefix that adds no security but serves only to satisfy those rules. For example, all your passwords could begin with "$A1a". Unfortunately, this doesn't help when you run into the truly bizarre (but fortunately rare) case of sites that disallow specific characters (e.g. '$', which I believe I discovered is disallowed on Seattle City Light's website).

Nope, but I've performed plenty of memory corruption over the years. :)

For the author's challenge about injecting code: I was able to get it to execute arbitrary code by making the compiled code longer than 128 bytes. When that happens, execution runs right into your data memory, which you can populate with the opcodes you want.

> A number of people spend significant time working for Google as 'visiting experts' (think professors on sabbatical) and that effort is hindered by the challenges of finding a nice place to stay, except there is housing for a few thousand people already at the airfield (formerly 'base housing') which could be repurposed for that.

I lived in that housing for about 5 years as a kid. I have lots of memories of the base (Hangar one, the movie theater, Baskin-Robbins, the community pool, McDonald's, the pea patches behind the housing), particularly since, as a Navy brat, that was one of the few places I lived for more than a year or two in my entire childhood. I like the idea of going on a trip to Google for some reason and being put up in the same townhouse I lived in then, or one of my friends' houses.