@prefix dcterms: <http://purl.org/dc/terms/> .
@prefix edu: <https://knobit.org/def/> .
@prefix owl: <http://www.w3.org/2002/07/owl#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix schema: <https://schema.org/> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .

<https://knobit.org/id/task/dsec-access-design/C1> a edu:Question ;
    rdfs:label "C1 (2 points)"@en ;
    dcterms:license <https://creativecommons.org/licenses/by/4.0/> ;
    owl:sameAs <https://bitbucket.org/reffa/ontology/id/task/dsec-access-design/C1> ;
    schema:hasPart <https://knobit.org/id/register/data-security#SE-350>,
        <https://knobit.org/id/register/data-security#SE-351> ;
    schema:identifier "C1" ;
    schema:position 1 ;
    schema:text "Masking that holds, 1 each. (a) MK-001 masks card_account.pan to the last four digits, but the daily agency file TR-001 carries card_account.pan in clear: the answer reports the clear copy and closes it - TR-001 carries no full PAN (the last four digits the agency's letters need, or a token), or MK-001 is applied to TR-001 too. (b) MK-002 'masks' party.personal_code with an unsalted, unkeyed SHA-256 hash: personal codes are 11 digits with a known structure (birth date, serial, check digit), so hashing every candidate code recovers them. The answer says so and replaces it with a keyed method (tokenisation, or HMAC with a secret key outside the analysts' reach) or an internal surrogate such as party_id - not with another unkeyed hash."@en .

edu:Question rdfs:label "Question"@en,
        "Küsimus"@et .

<https://knobit.org/id/register/data-security#SE-350> rdfs:label "dsec-access-design C1: the PAN masked in the mart and portal but in clear in the agency file"@en .

<https://knobit.org/id/register/data-security#SE-351> rdfs:label "dsec-access-design C1: an unkeyed hash of the personal code is recoverable and replaced by a keyed method"@en .