Hacker News Reader

Comment by DuskStar | Hacker News Reader

Why on earth would you store user passwords with AES locally and then use a hardcoded key to encrypt them???

$employer has recently been acquired by a big international corp. As part of the acquisition they have been "auditing" (really checkbox ticking and superficial API scans) our applications. One of the issues that came up is that we were using bcrypt as password hashing algo and our new overlords had a whitelist policy that only included sha2 variants and perhaps ripemd or something like that. We argued that their whitelist was totally inadequate for password hashing and pointed to multiple national standards bodies. The people doing the audit just ignored everything we explained to them and repeatedly pointed at the policy (which they weren't in charge of themselves).

Several people on my team were opining to just comply because it's the easiest way to do and they were concerned about their job security if they would go "against security".

My takeaway from that experience was that the people in charge of corporate security policies and audits are not experts in security, they are experts in reshuffling responsibility and covering asses. And many developers are easily cowed by them.

The result is compliant software, not secure software.

Compliance is really the biggest source of bullshit jobs. All the paperwork you need to get certified, the manhours spent reviewing it, all for marginal benefits.

Many (most) processes like that started because someone got burned by something, and the people ultimately responsible said "make a process so it doesn't happen again".

Often times companies go through this with internal processes as they grow, and some grow out of that phase.

Other times (especially at even larger companies) processes are adopted "from the industry". While not necessarily bad, it also requires flexibility from feedback. In parent's case, auditing to ensure sensitive data is encrypted to a minimum standard is reasonable , auditing to ensure any encryption is limited to a very narrow set of algorithms is not.

I worked on a project once that contracted out security audits to HP and those were distressingly not good security audits, just vague automated checkbox-checking of a list put together with zero context.

The loss of efficiency is still probably worth it. At least, it's worth it for systems where failure has severe consequences. You wouldn't want to ride an elevator where they skipped all the paperwork, for example.

Could you hash using both, your preferred algorithm first then theirs? That would make everyone happy.

bcrypt(sha256(pw)) works I believe, but it might not be enough to satisfy the policy.

It's actually better than plain bcrypt because you can allow long passphrases.

Is it better? The suggestion is vulnerable to a sha256 collision attack.

Except that for a collision attack to be a thing, you need to know the value you're trying to collide with - and that requires reversing bcrypt.

'Cause a whole bunch of people don't know how to do security.

You'd be surprised how many people come up with this then don't think any further.

This is the kind of solution I see from new grads with no crypto/security experience, but whom with a quick frown, think about it a little more and suggest why this is a bad idea. Many can do that even when they don't know how exactly to do it correctly.

This was just lazy/rushed or dare I say it, negligent.

The policy person at head quarters said, "systems must encrypt sensitive data". The local security office classified passwords as 'sensitive data' and sent a memo to all staff (sensitive data must be encrypted at rest). The devs encrypted the passwords. The auditors 'checked the box' as the passwords were now encrypted. Everyone moved on and forgot about it. At the time, a few people complained about the details... something about one way hashes. But they complain about everything, so no one listened to them.

I guess they were proud for using encryption instead of hashing, hence, more secure!

Definitely they didn't follow the one and only rule of security: don't roll your own.

Hashing is not an option for locally saved passwords. Some kind of token-based Auth scheme could work, but not hashed passwords.

That said, the much greater problem is the idea of using a hard-coded key, instead of generating a unique key for each device/installation.

Unique keys don’t help much. It only takes one person to write a script and put on github so that it can dynamically find the key and unencrypted stored password.

Again it's a grad level thing, but many smart grads can work out why encrypting isn't better. At least of the many I've interviewed, even ones I didn't hire could figure this much out.

> and then use a hardcoded key to encrypt them

Ask this question instead: Why bother to encrypt them in the first place?

What is the attack scenario you are trying to defend against? This is local software - it need to be able to decrypt the key and use it to login.

So at the end of the day it's the same machine with the password and the key to decrypt the password. It seems pretty pointless to even encrypt them in the first place.

So why do it? I don't know, maybe just to make it marginally harder to see the password. If that's the entire goal, there isn't really any reason no to use a hardcoded key - it accomplishes that goal just fine.

Ask yourself this: What attack scenario would a different key per machine defend against that a hardcoded key would not?

So that that if you're browsing your registry and someone looks at your screen, that person doesn't get your password.

It was the quick thing to do. I bet the have a "technical debt" story on the backlog that they're never able to get to.

Maybe. But does every teamviewer instance everywhere need to use the SAME AES key?

Yeah, that was what got me. (But at the same time, I don't think there's a trivial way for teamviewer to securely store that per-install key. "Trivial" meaning "can be implemented with no dev time and work on all versions of Windows")

That’s probably fair. IDK. I mean, the solution here was to not store plaintext at all and do token/cookie/whatever. But yea, I get your point.

Reply on news.ycombinator.com