Closed
Bug 691607
Opened 14 years ago
Closed 14 years ago
Alter verify receipt for apps
Categories
(addons.mozilla.org Graveyard :: API, defect)
addons.mozilla.org Graveyard
API
Tracking
(Not tracked)
RESOLVED
FIXED
6.2.6
People
(Reporter: andy+bugzilla, Assigned: andy+bugzilla)
References
Details
(Whiteboard: [t:muffin])
Alter verify receipt so that it will verify the hash sent in bug 691599.
Assignee | ||
Comment 1•14 years ago
|
||
Currently app receipts require you to be logged in so there's no need to add this. It's there if we need it though.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → WONTFIX
Assignee | ||
Comment 2•14 years ago
|
||
I remember why we needed this. It's ensure that as people change emails on AMO, we user the hash to verify which user it is and stop people "stealing" others receipts.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
Assignee | ||
Comment 3•14 years ago
|
||
https://github.com/jbalogh/zamboni/commit/c3474c
Asking mhanson about turning it on.
Status: REOPENED → RESOLVED
Closed: 14 years ago → 14 years ago
Resolution: --- → FIXED
Comment 4•14 years ago
|
||
I am concerned that this could allow an enumeration attack on our system, to determine whether an arbitrary user has purchased an arbitrary app.
The fix for that is to require that the signature is an input to the hash - which seems a little backwards. Better would be to verify the signature directly, since it's already a hash of the input data which has been signed with our secret, so an attacker can't spoof it.
So: I think that means that any hash-verification API needs to include the signature, and to refuse to verify a hash unless the signature is present and looks good.
Comment 5•14 years ago
|
||
(In reply to Michael Hanson from comment #4)
> I am concerned that this could allow an enumeration attack on our system, to
> determine whether an arbitrary user has purchased an arbitrary app.
>
> The fix for that is to require that the signature is an input to the hash -
> which seems a little backwards. Better would be to verify the signature
> directly, since it's already a hash of the input data which has been signed
> with our secret, so an attacker can't spoof it.
>
> So: I think that means that any hash-verification API needs to include the
> signature, and to refuse to verify a hash unless the signature is present
> and looks good.
Are there bugs (for the store and the client side) to adjust this?
Assignee | ||
Comment 6•14 years ago
|
||
We could use the signature for hash verification as opposed to our slightly weaker one.
The hash we are using for add-ons should make any enumeration attack a lot harder and we can do rate limiting on the verification. I haven't put any rate limiting on, since I'm not sure what a reasonable value would be.
Comment 7•14 years ago
|
||
Analysis of the identity verification requirements for apps, including changes to BrowserID and implications for AMO, are being discussed here:
https://etherpad.mozilla.org/browserid-apps-needs-2011-10
Updated•10 years ago
|
Product: addons.mozilla.org → addons.mozilla.org Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•