View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0006179 | Taler | specification | public | 2020-04-14 14:00 | 2024-01-12 13:03 |
| Reporter | oec | Assigned To | Christian Grothoff | Resolution deadline | |
| Implementer | Reviewer | ||||
| Release signed by | Deployed by | ||||
| Verifier | Communicator | ||||
| Data protection authority notification required | No | ||||
| CSIRT notification required | No | ||||
| Estimated effort (hours) | Actual effort (hours) | 0 | |||
| Fast-track | No | ||||
| Work package | none | ||||
| Priority | normal | Severity | minor | Reproducibility | have not tried |
| Status | closed | Resolution | won't fix | ||
| Product Version | git (master) | ||||
| Target Version | 0.7.1 | Fixed in Version | 0.7.1 | ||
| Summary | 0006179: Add authentication to /reserves/$RESERVE_PUB | ||||
| Description | The implementation in ... states: .. note:: The client currently does not have to demonstrate knowledge of the private key of the reserve to make this request, which makes the reserve's public key privileged information known only to the client, their bank, and the exchange. The knowledge of a reserve's public key should not be sufficient to get read access to the private data in the reserve. F.e. the exchange could require a reasonably recent timestamp and random value to be signed with the corresponding private key. | ||||
| Tags | No tags attached. | ||||
| Well, we considered which information one can get, which is basically 1) how much money was put into the reserve 2) how much money was taken out. The reserve_pub is only exposed to the bank (from the wire transfer), and the bank already knows (1). Leaking (2) to the bank seems pretty harmless, especially given that it will virtually always be the case that the wallet takes out all the money immediately. So which information loss exactly are you worried about here that would justify some crude authentication measure? (Note that signing timestamps is quite crude, as we then have to worry about replays and/or unsynchronized clocks, and if we want to guard against replays we'd have to keep extra state at the exchange. Also, this is an API for which we cannot charge fees, so one BIG worry is abusing it for DoS. So it is very important that the exchange has little work to do here (in particular no write access to the database!), and that we can easily add a caching proxy. Given the useless information returned to those with prior knowledge, I think adding authentication is not a good trade-off. | |
| Oh, yes, indeed, reserve != wallet. I agree that the knowledge of bank->reserve->wallet transactions is rather harmless and doesn't vindicate additional complexity. | |
| Ah, I see your (slight) confusion. No problem, will close the bug. | |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2020-04-14 14:00 | oec | New Issue | |
| 2020-04-14 14:00 | oec | Status | new => assigned |
| 2020-04-14 14:00 | oec | Assigned To | => Christian Grothoff |
| 2020-04-14 14:07 | Christian Grothoff | Note Added: 0015649 | |
| 2020-04-14 14:14 | oec | Note Added: 0015650 | |
| 2020-04-14 14:29 | Christian Grothoff | Note Added: 0015651 | |
| 2020-04-14 14:29 | Christian Grothoff | Status | assigned => closed |
| 2020-04-14 14:29 | Christian Grothoff | Resolution | open => won't fix |
| 2020-04-14 14:29 | Christian Grothoff | Fixed in Version | => 0.7.1 |
| 2020-04-14 14:29 | Christian Grothoff | Product Version | => git (master) |
| 2020-04-14 14:29 | Christian Grothoff | Target Version | => 0.7.1 |
| 2024-01-12 13:03 | Christian Grothoff | Category | exchange API (HTTP specification) => specification |