digitalfabrik / entitlementcard

App for 'Digitale Berechtigungskarten', generally benefit card for volunteers or socially vulnerable groups in Germany. App for Android & iOS + Backend + Administration Web Portal – 100% Open Source.
MIT License
35 stars 3 forks source link

Limit activations #1367

Open michael-markl opened 3 months ago

michael-markl commented 3 months ago

Is your feature request related to a problem? Please describe. Currently, an activation code can be used arbitrarily often to activate a device. This enables owners of a card to "share" the same card with others by simply sharing the activation code: Whenever one of the non-owners wants to benefit from the shared card, they can simply activate the card using the activation code before walking into the accepting store. With the introduction of the deep link activation workflow this is as easy as clicking on a link. This type of systematic abuse should be avoided.

Describe the solution you'd like Base solution: We can simply limit the number of allowed activations, e.g. a maximum of 5 activations are allowed per year per activation code.

Possible extension: After human review, the number of allowed activations can be raised for a specific activation code (e.g. for cases when the user switches his phone often or deleted and reinstalled the app often)

Describe alternatives you've considered (none)

Additional context

1244

f1sh1918 commented 3 months ago

Sounds reasonable. We should definitely implement some limitation. Since we don't have a testing scheme for the mobile app i actually have to reactivate my card quite often if i do some local tests on my device. I think we should add some interface in the administration where this amount of allowed activations can be set and also cards can be revoked. I think the effort is not that high and we could offer this feature at some point and for now limit the usage Probably we also might need some test scheme as we have in integreat

f1sh1918 commented 3 months ago

On the other hand copying a pdf is even not a big deal (which can be done atm). I think we should display the message "Please check also for a valid id card/passport" (which we do only for static cards at the moment) in any case. So i think we should talk about that issue with the customers but its not super urgent in my opinion. Its up to the verifiers to verify the card correctly.

michael-markl commented 3 months ago

Please check also for a valid id card/passport

This is already what we communicate so far. For 100% certainty, an "amtlicher Lichtbildausweis" must be checked (we even have this hint in the 3-step instruction of the verification dialog). But we know, that in most cases this check will not happen (as often the discounts are not huge and it's "not worth" the effort). So, imo, we should try to make it as hard as possible for the users to abuse it.

I think we should display the message "Please check also for a valid id card/passport" (which we do only for static cards at the moment) in any case.

Imo, we should save this for the static codes, as these can copied super easily, and it is even more important to check the Ausweis.

On the other hand copying a pdf is even not a big deal (which can be done atm).

Yes, it is currently possible, but it's not as easy as clicking on a link. You'd have to scan a qr code (so you need at least a second screen or a physical copy of the PDF). But yes, the "problem" already exists here in a slightly milder variant.

f1sh1918 commented 3 months ago

@dkehne we should maybe also talk to the customer about this and discuss the amount of activations I think we should give this a quite high priority

f1sh1918 commented 3 months ago

Maybe it could be also an option to store the "LastActivationDate" and limit it to a particular time period @michael-markl ?

michael-markl commented 3 months ago

@f1sh1918 Can you elaborate on that? I do not get it yet.

f1sh1918 commented 3 months ago

As we set a firstActivationDate , we could also set a lastActivationDate and then we can say you can just activate once a week for example the card and have to wait, so the abuse would also be limited.

michael-markl commented 3 months ago

So you propose to allow at most one activation per week (or a similar time period). (Let's not get lost in technical/implementation details for this discussion.)

I think a slightly higher number of activations in a substantially longer period (e.g. 5 activations per year) could be more effective when it comes to preventing abuse while at the same time allowing to reactivate in the case of a phone switch / app reinstall / other activation problems without having to wait for a week until the next activation is allowed.

dkehne commented 2 months ago

As the entitlementcard is only valid together with an ID card i don't see a big problem from the non-technical perspective. I would discuss that limitation earliest we have a practical abuse case...

michael-markl commented 2 months ago

@dkehne Taking this perspective, a dynamic element on the screen would be completely unnecessary. The idea of the dynamic element is to increase the reliability of "Ah I see the dynamic element on the app, so I can be relatively certain that this (wo)man has a valid entitlementcard without scanning it". This certainty was higher before, because to achieve the "activated" screen, a fraudulent user would have to scan the activation qr code every time they switch the phone (a tedious thing to do every time, as you would have to carry the activation qr code with you to be able to scan it). With deeplinking, this scenario gets a lot more comfortable.

I agree, there is formally no necessity to do it (as we say the card is only valid with a passport), but I think not doing it questions the dynamic element alltogether.

[Also, currently, we cannot detect whether there is any abuse. Maybe we can implement some detection mechanism (e.g., count the number of activations per card and check for outliers) before we implement a limit]

dkehne commented 2 months ago

Yeah sounds good as well. maybe we count the amount of activations first and in a second step we implement some kind of alert if it becomes a three digit number or sth. like that