Timeline for Where to store the private key?
Current License: CC BY-SA 3.0
22 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jul 18 at 16:23 | review | Close votes | |||
| Jul 23 at 3:09 | |||||
| Jul 18 at 16:04 | history | protected | gnat | ||
| Jul 18 at 10:49 | answer | added | Yash Patel | timeline score: -1 | |
| Dec 25, 2016 at 0:51 | vote | accept | Xophmeister | ||
| S Jan 3, 2014 at 18:36 | history | bounty ended | MetaFight | ||
| S Jan 3, 2014 at 18:36 | history | notice removed | MetaFight | ||
| Jan 2, 2014 at 19:08 | answer | added | BrianH | timeline score: 2 | |
| Jan 2, 2014 at 13:23 | comment | added | JeffO | If a particular user's key is compromised, the data access should be limited to that user's account. The way you protect your car is to protect your own keys. | |
| Jan 2, 2014 at 13:09 | answer | added | 9000 | timeline score: 2 | |
| Jan 2, 2014 at 12:23 | answer | added | Pieter B | timeline score: 5 | |
| Jan 1, 2014 at 23:27 | answer | added | polve | timeline score: -2 | |
| Jan 1, 2014 at 23:15 | answer | added | Davin Tryon | timeline score: 40 | |
| Jan 1, 2014 at 19:38 | history | tweeted | twitter.com/#!/StackProgrammer/status/418466394863575040 | ||
| S Jan 1, 2014 at 16:49 | history | bounty started | MetaFight | ||
| S Jan 1, 2014 at 16:49 | history | notice added | MetaFight | Draw attention | |
| Dec 11, 2013 at 9:11 | comment | added | CodesInChaos | The best you can do about malicious clients is restricting them to a well defined service API, not giving them direct access to the db. You can't really do anything beyond that, since you can't hide a secret in the client. | |
| Dec 11, 2013 at 0:17 | comment | added | Kevin | Amon's answer isn't limited to a user, but any client. DXM also raises a point that you cannot protect your system from someone who wants to tamper with it and you shouldn't expend the energy to make it difficult for them to do so. Instead expend the energy on the product so they have no interest in doing so | |
| Dec 10, 2013 at 23:52 | comment | added | amon | The only absolutely safe way to avoid having to trust a secret to the user is to avoid the need for such a secret. A common solution is to run the software on a server under your control, and only distribute an unprotected front-end through which the user can authenticate himself to the server, and then consume services from the server. | |
| Dec 10, 2013 at 23:40 | comment | added | DXM | unfortunately, there isn't very much you can do against a "malicious superusers". Since your software needs access to the keys, so will any superuser since they have the ability to alter/bypass just about any ACL that you may put in place. | |
| Dec 10, 2013 at 23:12 | comment | added | Carson63000 | What manner of software is your software? Is it an application being distributed to end-users? If so, what language/platform? Or does it run on a server e.g. a website? | |
| Dec 10, 2013 at 22:06 | comment | added | Brian | You may find various posts at Security.SE to be of interest. I will note that some frameworks and languages provide specialized support for this (e.g., encrypted configuration sections in .net). | |
| Dec 10, 2013 at 21:59 | history | asked | Xophmeister | CC BY-SA 3.0 |