0

I'm working on a small project that stores an encrypted password, using code from Simple insecure two-way "obfuscation" for C#. The password will be stored locally on the user's PC, and there is no database involved to store a second key.

I will need to share this code up to my team and, eventually, possibly to other teams. Since it's 2-way encryption, I don't want the key/vector information to be shared, and anyone be able to access the passwords generated with that key/vector.

I thought about using some mishmash of machine name/user SID to generate the key/vector on a per machine/user basis, but it would be easy enough to get that information if you wanted it.

I thought about having the user generate a random key to start with, but hey, you have to store that somewhere, too.

  1. Am I thinking too complicated about this?
  2. What are your suggestions to do this the most securely?
Community
  • 1
  • 1
SlowCoder74
  • 103
  • 12
  • You're not thinking too complicated. It's an unsolvable problem with normal hardware. – Artjom B. Jan 13 '15 at 13:07
  • I think you've jumped us all the way to a solution without telling us what *problem* you're trying to solve. What were you working on where you thought "encryption is the answer"? – Damien_The_Unbeliever Jan 13 '15 at 13:07
  • Damien_the_Unbeliever, the problem I'm trying to solve is protection of encrypted data, when the project source will be shared among my team, and possibly distributed to other teams, including the inbuilt key and vector. When I thought "encryption is the answer" is when I didn't want to store the user's password in clear text. – SlowCoder74 Jan 13 '15 at 14:20
  • No, encryption is a *solution*. The problem will be along the lines of defining a number of roles and what access to data those roles should have - maybe some of them should have no access to a particular piece of data. Maybe others should be able to *create* new pieces of data but not re-read there data (or should be able to re-read their *own* data but not that created by others). You need to define what data you're dealing with, where it resides, and who needs what access to it before you decide whether "this data should be encrypted" is part of the solution. – Damien_The_Unbeliever Jan 13 '15 at 14:39
  • I think I understand what you're asking, Damien. It is necessary that only the user has access to the data. They are not entering a password, then checking it against a hash. Rather, it is an automated login program, so the encryption needs to be reversible. What I perceive as a potential problem is this: the code is uploaded to our code management system. Other people would then be able to see the algorithm and key, be able to retrieve the user's encrypted password, and decrypt. – SlowCoder74 Jan 13 '15 at 18:05

0 Answers0