i'm designing api uses application level encryption protect sensitive information in database.
a simple example of problem user table following fields:
- userid
- name
- address
- telephone number
- clientidentifier
in above table fields sensitive , should encrypted apart userid primary key of table. while primary key exists foreign key constraints actual identifying value record clientidentifier. id user controlled consumer of api.
when consumer of api wishes create user record pass details (including clientidentifier) store. when want retrieve details again pass clientidentifier. use case, cannot use userid.
it's clientidentifier public knowledge e.g. email address or account number , can traced real person. therefore have secure clientidentifier existence of record imply person exists on our system.
i see couple of options.
hash clientidentifier. downside clientidentifier follow fixed format , vulnerable brute force attacks.
encrypt data in case of clientidentifier use fixed iv. downside here attacker had access both api , database execute plain text attacks on system.
i'm leaning towards second option plain text attack can mitigated monitoring of encryption service, whereas hashing option broken reasonably if snapshot of database lost.
so question is, think i'm on right track or there better alternatives?
edit: it's possible have multiple records in database same clientidentifier. given plaintext id should able select records.
if you're set on encrypting both user id , password, might want take @ bcrypt. adaptive hashing algorithm, , can encryption complexity whenever want. you'll have use system-wide salt, still make vulnerable dictionary attack. best bet randomly generate account # (with numbers , letters) use client id, should negate dictionary attack. sure make long enough secure.
in general, user id isn't encrypted because there no way salt hash of user id, makes vulnerable attacks. before jump through flaming hoops, i'd make sure need encrypt both client id , password.
Comments
Post a Comment