Timeline for Strategy for Public / Private API, Encrypted (or Hashed) Data, and Server Compromise
Current License: CC BY-SA 3.0
8 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jan 13, 2016 at 23:19 | vote | accept | Volomike | ||
| Jan 13, 2016 at 21:55 | answer | added | Dan Pichelman | timeline score: 5 | |
| Jan 13, 2016 at 20:56 | comment | added | Volomike | Okay, I posted a preliminary answer. Do you think this can work and is a best practice? | |
| Jan 13, 2016 at 13:46 | comment | added | Dan Pichelman | In that case, why does (A) need any knowledge of encryption at all? Just have (B) pass in the data already encrypted. | |
| Jan 13, 2016 at 7:36 | history | edited | Volomike | CC BY-SA 3.0 | corrected spelling - typo |
| Jan 13, 2016 at 1:51 | comment | added | Volomike | It's holding it for (B). The idea is that if a hacker hacks (A), without a private key from (B), he's going to be out of luck. And no amount of intercepting the web traffic on (A) is going to help. I'm just trying to do this in the most secure, industry-standard way. | |
| Jan 12, 2016 at 20:49 | comment | added | Dan Pichelman | Does (A) need to be able to access this secret identity information, or is it just holding it for (B)? | |
| Jan 12, 2016 at 20:39 | history | asked | Volomike | CC BY-SA 3.0 |