-3

I was answering a question here suggesting the usage of .NET's cryptographic libraries (e.g. AesManaged) when I wondered: “but where the key used by the application should be placed?”.

I have a secret I need to store inside my application which should be used by the application but not known by the user, and I don't know how to do it.

The kind of secret I'm talking about is not something user-related (e.g. a user's password to a third party service) but womething application- or developer-related which should not be known by the user (e.g. if a user knows an application's OAuth client secret he can impersonate the developer against the third-party service).

I know of Window's Credential Manager, Data Protection API and such, but they don't help in this scenario because they're meant to protect users' secrets, moreover most of them are run-time solutions while what I need to protect is “constant” and “compile-time”.

I'm fully aware any kind of action I will take will only delay a skilled and detemined user in accessing the secret since if the application must have access to it in its plaintext form the user too can, somehow. What I'm looking for is to prevent casual users from opening the application “in Notepad” and getting the secret.

I'm fully aware that any kind of measure is only temporarily stopping a skilled and determined user from accessing such secret, I'm not asking for a bullet proof solution to the problem, I'm interested in which choices I have besides writing var myClientSecret = "MySuperSecretClientSecretKey"; to store such information.

Is var myClientSecret = Encoding.UTF8.GetBytes("MySuperSecretClientSecretKey") the only alternative?

Does the framework provide anything helping me accomplish this task?

Community
  • 1
  • 1
Albireo
  • 10,977
  • 13
  • 62
  • 96
  • 3
    This is too broad, and "best practices" makes it opinion-based as well. Also, plenty of existing questions on this subject exist already, try searching. http://stackoverflow.com/questions/4967325/best-way-to-store-encryption-keys-in-net-c-sharp, http://stackoverflow.com/questions/16957492/c-sharp-securely-storing-a-password-locally, and so on. Also, "not visible to the user" and "required by the application to function properly" are mutually exclusive. – CodeCaster Dec 14 '15 at 09:50
  • What about the cryptography store in Windows? https://msdn.microsoft.com/en-us/library/windows/desktop/aa380242%28v=vs.85%29.aspx?f=255&MSPPError=-2147217396 – Patrick Hofman Dec 14 '15 at 09:50
  • If its compile time and not gonna change later in the user machines, then just save them in the *Resources* – Ghasem Dec 14 '15 at 09:50
  • _"what are the best"_ arguably implies opinion and if so is off-topic for SO sadly –  Dec 14 '15 at 09:53
  • @CodeCaster the questions you liked are (unless I'm mistaken) about protecting run time data (e.g. `ProtectedData` class). – Albireo Dec 14 '15 at 09:54
  • @Micky I'm not asking what *you* think is the best way to do it, but what is (if there is) considered a [best practice](https://en.wikipedia.org/wiki/Best_practice) by the industry. E.g. "Do not store plain text passwords in a database" is a best practice, not an opinion. – Albireo Dec 14 '15 at 09:57
  • at best it gets reopened and closed immediately. Read around: http://stackoverflow.com/q/20741811 – Drew Dec 14 '15 at 10:06
  • @CodeCaster at al, after reading http://meta.stackoverflow.com/q/265928 I slightly rephrased the question, is it OK or it should be revisited more? – Albireo Dec 14 '15 at 10:11
  • @Drew I've read the question you linked, but it's different from the one I'm asking: in the linked question you have control of both ends of the channel, while here you need to store what you have “as is” because you can't change the other side (think of saving your Google Maps API secret key, or anything similar). – Albireo Dec 14 '15 at 10:13
  • 1
    all the more reason for it to be too broad and closed, or unclear and closed. It simply is going nowhere. Why not focus on your requirements, and find the answer on the stack. It is there. – Drew Dec 14 '15 at 10:15
  • 1
    You also have made no mention of any of this in your question. Asymmetric or block ciphers or the control of other systems. It is wildly broad, unclear, and opinion based. Remember how you got to where you are in your tag. Research. – Drew Dec 14 '15 at 10:17
  • @Drew your last comment has been useful in trying to fix the question, I think. What do you think of it now? – Albireo Dec 14 '15 at 10:29
  • check out http://stackoverflow.com/a/17747020 There are literally hundreds of ways it can be cutting edge secure. Including `impersonation` through a windows service as a user account. We simply don't know the details of your implementation. It is wildly broad, and you can solve it – Drew Dec 14 '15 at 10:39
  • 1
    You need to step back and remember that answers on the stack are best delivered in a relatively short worded answer and not pages. – Drew Dec 14 '15 at 10:40
  • @Drew I'm sorry, but I don't see how the question you linked or your proposals can help in my scenario: in that question the developer is asking how can he access the [Credential Manager](http://windows.microsoft.com/en-us/windows7/what-is-credential-manager) which is used to store *user's* credentials (and can be accessed freely by the user), in my scenario such “credentials” are issued by a third party (e.g. Google, Twitter, imgur) to *the developer*, not the user, and the user *should not* (emphasis on “should”) be able to access them as it will allow to impersonate the developer. – Albireo Dec 14 '15 at 10:48
  • 1
    I am saying do research. If you want your passwords to, or not to, be available, to any given party, you can have that happen through storing passwords in vaults. You need to read up on what impersonation means. And I am done here, because I am spread across other questions right now – Drew Dec 14 '15 at 10:49
  • This is just another reason why [Oauth sucks](https://tools.ietf.org/html/rfc6819#section-4.1.1). So they tried to solve the Oauth security and complexity shortcomings by [adding more complexity](https://tools.ietf.org/html/draft-ietf-oauth-assertions-18). Very sorry that you have to implement this rubbish. – TheGreatContini Dec 15 '15 at 02:12

1 Answers1

0

Store the secret in a smart card. Send the user the smart card when they buy the software.

A key stored in a smart card cannot be read or cloned.

Neil McGuigan
  • 46,580
  • 12
  • 123
  • 152