Hacker News new | ask | show | jobs
by ComputerGuru 3415 days ago
Shamless plug: SecureStore, our .NET secrets manager: https://neosmart.net/blog/2017/securestore-a-net-secrets-man...

I'm drafting a writeup and will post it to HN when that's ready. Other secrets managers I've seen posted to HN seem far too overcomplicated, at least for our company's needs. This is a step up from reading secrets from a plain text file, but not so complicated that you need a separate docker image running a service dealing out passwords to your webapps or similar.

EDIT: rationale for use, as requested:

Using this approach, you can better manage your secrets since you can actually commit the passwords file in your code base, and the API lends itself to easily switching between dev and production ids/secrets. You can track revisions to the secrets file, rolling back your commits rolls back the secrets as well. You can also include the deployment of secrets in your deployment script - typically, the encryption key for your vault is only generated and distributed to the production servers once, while secrets may be added, changed, and removed continuously during the development and product lifecycles.

Using a simple secrets manager like NeoSmart's SecureStore lets you embrace the benefits of deployment automation, revision control, and more, without sacrificing safety and security in the name of productivity or ease-of-use.

EDIT2: what the heck, just took 10 minutes off to write it up and publish it: https://news.ycombinator.com/item?id=13654005

2 comments

What hashing algorithms are you using? Are you updating that hashing algorithms as cipher-suites are being broken? Are we as a user required to set a random seed? Just because it is encrypted doesn't mean it is impossible to decrypt. Especially if default settings in the hash are being used and someone uses a poor password found in another breach. Its a great idea, but I would still worry about security issues around publishing a password hash.
High level APIs are used for all crypto. The user does not have to generate their own seed. You can use your own key file or stretch a secret phrase once to create one with the library. Passwords are otherwise not hashed, only encrypted.
I think you need to add a sentence giving one good reason to use anything other than a plain text file.
Thanks, good idea.

I just did, though I may have gone overboard as it is more of a paragraph than a sentence. We developed SecureStore out of necessity, believe me, KISS all the way.

The fundamental trade-off for any new tool is that devs have finite capacity to learn new tools. That's why we like to learn a few tools really well and then reuse the heck out of them. However, we are open to warning-stories - that if you do it the naive way, at some point you'll get bitten by X, Y and Z. And even then we might not acre until we actually get bitten!