I think the core issue behind this is the complexity of managing SSH keys across your infrastructure. Have a look at https://bastio.com

JackDB: I like that the service keeps an audit trail on database transactions transparently, it is a big thing for companies that have to be compliant to a set of standards (i.e., health sector, financial sector, etc.) Good job!

Thanks. I've previously worked in technology in the financial services industry so a lot of the ideas for auditing/compliance come from meeting the expectations of that market. Our logic is that if it's seamless enough for them to use it and satisfies their compliance requirements, it should be good for most other industries as well.

Regarding SSH, it has the advantage that you can (and should!) have multiple authorized keys for the same account. For example for the bastion host to connect to our VPC of servers we use individual SSH keys tied to the same proxy account. Databases generally don't allow that type of access.

Some allow using client certificates to login (which nobody uses). Some allow integration with external LDAP/AD (which very few use). The vast majority uses standard username/password based authentication that hopefully is going over SSL (seriously go and check ... for most DBs by default it's sent over plaintext).

Some places try to have per user database accounts (possible tied to AD/LDAP) but that usually devolves to the same app password sharing as the privileges aren't kept in sync or it's just too much of a pain to provision vs just giving someone the app password.

I couldn't agree more; client certs are too much work and come at a non-trivial maintenance cost, same goes for AD/LDAP. So JackDB also acts as authentication provisioning front-end for a DBMS so users don't have to do that themselves and suffer the maintenance cost/overhead. Interesting.

I'm curious, your VPC bastion; how do you make managing SSH keys scalable given that setup? And why not separate accounts which in fact help with keeping sane logs of who did what, and distribute the risk of compromise across several accounts?

> So JackDB also acts as authentication provisioning front-end for a DBMS so users don't have to do that themselves and suffer the maintenance cost/overhead.

Yep. Couple of mouse clicks and a user no longer has access to one or more data sources (grants are role based). Similar effort for provisioning new users.

If the level of effort for a secure system is on par with emailing a password to a co-worker then people will actually use it. Plus with JackDB nobody other than the system admin even has the DB passwords so a normal user can't even send an email out if they wanted to.

> I'm curious, your VPC bastion; how do you make managing SSH keys scalable given that setup? And why not separate accounts which in fact help with keeping sane logs of who did what, and distribute the risk of compromise across several accounts?

At the moment things work for us as we're a very small team. Obviously something more scalable would be needed once you have a large number of people involved. The single proxy account is for convenience. That way the SSH keys to log into the other servers (accessible only through the bastion) can be shared. All servers (bastion included) log the public keys used to connect so we do have a trail of who/what/when. It would just be a bit more involved to filter it. Given our relatively small size it feels like a good tradeoff of security and convenience.

As we grow it's definitely something to (repeatedly) revisit, as is true about any security procedures.

Hi, one of the creators here. We got some really great feedback last time and went back to implement a daemon-based service. We are interested to know what server admins think of this tool, and what they find most useful about it. Also, we are adding a bastion-as-a-service soon. Thanks.

I think they have a bigger fish to fry given all the higher profile attacks that have been showering the place for quite sometime. Maybe you're right and they are just after many low-profile kids instead of that one big fish to make some noise and show that they have been doing something.

Yeah the SSL cert part is the irony since darkode has been infiltrated long ago now. It's amusing that they are seeking people out like that, I guess they are expecting very low profile catch.

This is a very complicated/dense question that depends on a lot of factors so I'll be making some assumptions.

First let's address the case where it is a large corporation:

- The risk of the 3x-dev leaving wouldn't be much as it is a large corporation and hence there are mechanisms at place that are ready to fill the 3-devs gap he will make if he left at any particular time.

- It is very economical to pay 3x salary for the 3x-dev as it saves on managerial costs.

- Promoting the 3x-dev to a team leader or a senior position is a good strategy as it will increase retention chances with him and also promotes sharing experiences and knowledge.

* Hiring 3-devs is rather a tedious task and have a significantly higher managerial cost, and the risk of them leaving is even higher as they won't feel that much special, hence no early rewards and the eventuality of them looking for other options out there.

* I daresay there is a statistical certainty that the 3-devs won't be on the exact same knowledge/experience level which will result into communication overhead that includes the assumption that they are good at communicating in the first place.

Office politics will make things even harder if you promote one of those 3-devs - that you hired at the same date - to reward a personal achievement of sorts.

Now in a small company/startup:

- Hiring the 3x-dev involves a high risk if he's not rewarded often with more than just a bonus or a salary increase, like a piece of the company that he helps building.

- Hiring him will cut down on managerial expenses greatly, and will result in a much smoother development process.

- There's no body that of concern to compete with head to head and even if there were, they are supposedly experienced and professional enough to keep things light between them and focus on delivering results.

Hiring the 3-devs have a very high risk if they _are_ rewarded equally - which you hired them at the same date - simply because you are normalizing their efforts and hence creating a class of sorts which can and in fact will backfire. Now if you decided to pay attention to every developer separately, that might create jealously, which can be a positive thing, but it largely depends on the company culture/atmosphere you have and it is quite tricky to maintain.

* There's a managerial overhead that won't be easy to maintain since this is a small company and you yourself have things to do better than maintaining logistics/communication and team spirit.

* The fact that this is a small company by definition will require a diversified skill set, flexibility, and not just willingness to learn but rather knowing how to consume knowledge fast and turn it into an actionable skill, while this is questionable although highly likely, your 3-devs will find it difficult - and quite overwhelming - to take over the many tasks that require different skills in the tight time window and stress that comes with all small companies. But this also depends on how you structure your company culture/political-atmosphere, and yes there will always be company politics whether you like it or not, even if you intentionally and consciously try not to develop them.

All in all, I believe that every environment and work place is quite unique. But from personal experience over multiple quite different industries, quality comes before quantity.

So my short summarized answer is to go with the 3x-dev and give him 2.0x-2.5x if it were a large company with short period rewards, or give him 1.5x-2.0x if it is a small company with emphasis on long term benefits/interests coupled with exciting/teasing short term rewards.