Closed Bug 691607 Opened 14 years ago Closed 14 years ago

Alter verify receipt for apps

Categories

(addons.mozilla.org Graveyard :: API, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

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.
Blocks: 690143
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
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 → ---
https://github.com/jbalogh/zamboni/commit/c3474c Asking mhanson about turning it on.
Status: REOPENED → RESOLVED
Closed: 14 years ago14 years ago
Resolution: --- → FIXED
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.
(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?
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.
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
Product: addons.mozilla.org → addons.mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.