Comment by doctor_eval | Hacker News Reader

Comment by doctor_eval | Hacker News Reader

I actually have had the reverse experience.

My company was acquired 18 months ago. We were the smaller company, about 1/4 the size, and as the founder/CTO, I expected the acquiring company to be all over us. I mean, we had a pretty tight operation but there was only so much 16 people could achieve. There were plenty of things we could improve, and I was looking forward to the resources and experience of this bigger company to help us.

Was I in for a shock!

While their software dev practices were OK (certainly no better than ours), what hit me hardest was their secops. It was a nightmare. And these guys service some brand name clients.

As an example, not only was the corporate wifi password memorable - not actually “P455w0rd” but similarly bad - but it was written on a whiteboard in view of the whole office! Service passwords are still stored in clear text in the corporate wiki, and few people understand why this is terrible. It’s like a 90s IT shop, where people used to ask me “why would anyone care about our password?”

Kicking the can down the road is fine for a while, but without strong technical leadership, kicking the can becomes how things get done, and that’s been my experience here.

I’m not long for this place.

> Service passwords are still stored in clear text in the corporate wiki.

I know this painfully well :(. Can you recommend some good solution? Ideally open source and self hosted, instead of cloud password manager.

While I’ve not personally used it, I’m happy with 1Password Teams, bitwarden has a pretty well received project. If you want self hosted teams, though, you will need to purchase a license (it’s one of their money makers, and I think that is completely fair). Most of their product is otherwise open, afaik.

Bitwarden is fully open source and audited. You can self host the server and client if you want without additional cost (they charge small per user).

Bitwarden derives its keys using SHA256 on the passphrase and a hilariously low iteration count.

The developer refuses to acknowledge it as a security risk, and actually caps the max iterations you can configure, both on the client and the server.

https://github.com/bitwarden/jslib/issues/52

https://github.com/bitwarden/server/issues/589

“It was audited” is meaningless if the audit missed this, or reported this and the dev dismissed it. Either way, it is unsafe.

It looks like people are getting confusing between using SHA256 directly as a key stretching mechanism, and what PBKDF2-SHA256 is.

https://crypto.stackexchange.com/a/61306

Django, uses PBKDF2-SHA256 with 216000 iterations, for example https://github.com/django/django/blob/master/django/contrib/...

Given Bitwarden allows almost 10x that, not sure I see the issue.

Bitwarden’s auth protocol allows the server to tell the client that the iteration count is 5000, regardless of the actual iteration count, and the client will send 5000-iteration passphrase-derived material to the bitwarden server (run by the developer in the usual case).

PBKDF-SHA256 is far too fast, even with the HMAC step.

In the Audit they pointed this out, but didn't see it as a huge issue.

I'd rather they use Argon2id to be as safe as can be.

However, I've not yet seen a fully cross-platform javascript-only implementation of Argon2 at all, which is problematic for an extension.. :-/

UPDATE: There actually exist an Argon2 implementation that's used by another vault, https://www.npmjs.com/package/argon2-browser

Errr...most systems (like Django) send passwords in plaintext to the server! (Over SSL of course).

The point of PBKDF-SHA256 is to protect the secrecy of passwords if the server is compromised and its password hash db is dumped.

Django’s auth system is for a single site. Bitwarden’s master passphrase protects the key that decrypts my password for every single site I use.

This is not some random webapp. It is a password manager.

So use a longer password with BitWarden.

Think about it.

Disagree about the Cloud requirement.

Because: in this scenario you need to drive adoption first,if it is any complicated the humans will not use it. so you need the easiest tool possible.

when everybody is using it, THEN go for the real security move.

(you can try to find a non-cloud one that is super easy, but...)

You may be correct, but in current mindset u would get "What do you mean store all our password with someone else? No." answer. No amount of explaining can fix it.

> Because: in this scenario you need to drive adoption first ...

Be careful: that sort of behaviour can get you fired and potentially land your company in hot water from a legal and/or compliance standpoint, as well as lose them customers.

Compliance is often as much, or more, about having and following documented processes, as it is about having good processes. This can include an approved list of software and services. If you step outside this you are likely breaching your compliance regime.

In the specific case of passwords you may have policies and procedures around secret management that would be violated by storing this information in the cloud, even with a service specifically designed for this. As stupid as it is, the quality (or lack thereof) of your current solution is not the key point here.

If you decide to get all subversive and start using a cloud service then, at the very least, if discovered you're going to get into trouble. At worst, if customers become aware they might leave, and as I've already said, the company might find themselves in legal difficulties.

https://github.com/gopasspw/gopass

Crossplatform, git versioning, gpg security (allows you to integrate with smartcards and tokens that you might already have in place for your employees).

Decent UX too, works with clipboard, supports totp.

Reply on news.ycombinator.com