search

bytedreamer / Aporta

Aporta is an open source physical access controller. The main purpose of the software is to secure doors from unauthorized access. This is accomplished by determining if a person is authorized to enter a door. The door is unlocked momentarily by the software when authorized credential are presented.
Eclipse Public License 2.0
53 stars 6 forks source link

Person Details does not show card number #37

Closed rsgmodelworks closed 4 months ago

rsgmodelworks commented 10 months ago

request for enhancement. could you display the cardholder number somewhere (anywhere actually.) I suggest it be added as line in the "Person Details" subscreen. (typo - UI actually says Person details)

mistial-dev commented 10 months ago

This is going to relate to the wiegand data protection mentioned in a different issue.

If the data is shown, then attackers who get web ui access can encode cards. At that point there’s not much point in protecting it.

Ultimately, they are two different paths: security, or usability.

it could be possible to split the difference by making it an option. Allow display to be toggled, but wipe the card database when it’s turned on, or only make it visible for users added after that setting is changed. That way, an attacker couldn’t use that mechanism to get around any protection.

rsgmodelworks commented 10 months ago

In a secured scenario the mechanism to get to the screen with this display would have a protection mechanism (https, role based login, etc.) So this message would only be visible under conditions where it conforms to the security policy. It seems to me this mimics the situations where you can or cannot expose a credit card number in PCI. So I meant to be assuming this happens under best-possible secure conditions. And the alternative is the vendor fails the eval and doesn't get deployed and that's an existential crisis for an implementation.

mistial-dev commented 10 months ago

Any PACS attack not rooted in PKI (PIV) is going to have two parts: getting the data, then sending the data to the panel.

This does unfortunately make the panel a great place to steal the data all at once, which is a security concern if your panel has 10,000 cards enrolled because it is networked and supports the entire organization. This is where a TPM or HSM can provide protection, as long as the card number doesn't have to be visible.

The flip side, of course, is usability. A lot of workflows want that ability to login, see user card numbers, check the audit log with the card number and user, and edit the numbers. This is objectively easier to work with, but unfortunately makes protecting the card number against database attacks, certain exploits, etc. impossible.

rsgmodelworks commented 10 months ago

For troubleshooting enrollment issues you need to see the card number. It causes existential issues (i.e. your gear gets thrown out) if you can't get card reads working. This is in a maintenance situation, I'm not saying the card numbers have to be lying around in the clear all the time.

mistial-dev commented 9 months ago

For troubleshooting enrollment issues you need to see the card number. It causes existential issues (i.e. your gear gets thrown out) if you can't get card reads working. This is in a maintenance situation, I'm not saying the card numbers have to be lying around in the clear all the time.

Does being able to search and confirm work, or do you need to be able specifically to go into the person and see the number?

bytedreamer commented 4 months ago

You can see the card number on person details and from hovering over the access event. Both PIV and PKOC credentials should not be storing private keys in the database. It wouldn't matter that the card number is visible.