8 ms·

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

alias_neo 7y ago
'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.
- professorTuring 7y ago
  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.
  - alias_neo 7y ago
    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.
  - tsimionescu 7y ago
    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.
    - d1str0 7y ago
      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.
- _wldu 7y ago
  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.
chooseaname 7y ago
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.
- SlowRobotAhead 7y ago
  Maybe. But does every teamviewer instance everywhere need to use the SAME AES key?
  - DuskStar 7y ago
    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")
    - SlowRobotAhead 7y ago
      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.
the8472 7y ago
$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.
- yread 7y ago
  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.
  - zdragnar 7y ago
    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.
  - 7y ago
ars 7y ago
> 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?
Thorrez 7y ago
So that that if you're browsing your registry and someone looks at your screen, that person doesn't get your password.

'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.

professorTuring 7y ago
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.
- alias_neo 7y ago
  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.
- tsimionescu 7y ago
  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.
  - d1str0 7y ago
    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.
_wldu 7y ago
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.

chooseaname 7y ago

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.

SlowRobotAhead 7y ago
Maybe. But does every teamviewer instance everywhere need to use the SAME AES key?
- DuskStar 7y ago
  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")
  - SlowRobotAhead 7y ago
    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.

the8472 7y ago

$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.

yread 7y ago
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.
- zdragnar 7y ago
  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.
- 7y ago

ars 7y ago

> 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?

Thorrez 7y ago

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