4 ms·

> "this action was authorised by a keyboard entry sequence matching the admin account prerecorded sequence" "keyboard entry sequence" is just a long-winded way

> "this action was authorised by a keyboard entry sequence matching the admin account prerecorded sequence" "keyboard entry sequence" is just a long-winded way of saying "password"; there's nothing wrong abbreviating. However, even this facetious example was useful, since it's exposed a security problem: you're storing passwords ("prerecorded [keyboard entry] sequence"). You should be storing password hashes instead (using a slow hash function). :)

mrtksn 4y ago
I don't store anything but it doesn't matter because it doesn't change anything. Simply modify the sentence to include the hash conversion. The storing password part is relevant for extraction of password from an already compromised system and fingerprints can be hashed just as well(and on Apple's implementation, they are). It's just irrelevant implementation detail that doesn't make difference for the security of the system in question. In fact, fingerprints are actually more secure because you don't have rainbow tables for hashed fingerprints but you have it for passwords.
- chriswarbo 4y ago
  > Simply modify the sentence to include the hash conversion. You seem to be missing my point: that it's better to think about security issues in terms of the components and actions that actually exist in the implementation (e.g. "when the given password agrees with the stored hash, then XYZ"), rather than the real-world concepts they're crudely trying to approximate (e.g. "when the administrator is present, then XYZ"). If you want to use fingerprint scanners as part of a security system, that's fine; I really don't care. What I do care about is that "fingerprint scanner says yes" does not imply "Alice is currently holding her thumb against the phone screen", or other such real-world scenarios. Alice holding her thumb against the screen might cause the fingerprint scanner to say yes; and it's perfectly fine to make that assumption when designing a UI (where failure is mostly an irritation). Yet security design should not make that assumption, since it may hide all sorts of vulnerabilities. As an analogy: a "Keep off the grass" sign is not the same as there being nobody on the grass. It's good enough for something inconsequential, like turning on a sprinkler system (if you get wet, you should've followed the sign; similar to a UI breaking if the user doesn't use their phone in standard ways); yet it's not enough to, say, store our valuables on the grass, in the hope that nobody can get to them.
  - FabHK 4y ago
    > "fingerprint scanner says yes" does not imply "Alice is currently holding her thumb against the phone screen" Which is why GP carefully qualified his statement that "administrator is present" with the appropriate assumptions.

mrtksn 4y ago

I don't store anything but it doesn't matter because it doesn't change anything. Simply modify the sentence to include the hash conversion. The storing password part is relevant for extraction of password from an already compromised system and fingerprints can be hashed just as well(and on Apple's implementation, they are). It's just irrelevant implementation detail that doesn't make difference for the security of the system in question. In fact, fingerprints are actually more secure because you don't have rainbow tables for hashed fingerprints but you have it for passwords.

chriswarbo 4y ago
> Simply modify the sentence to include the hash conversion. You seem to be missing my point: that it's better to think about security issues in terms of the components and actions that actually exist in the implementation (e.g. "when the given password agrees with the stored hash, then XYZ"), rather than the real-world concepts they're crudely trying to approximate (e.g. "when the administrator is present, then XYZ"). If you want to use fingerprint scanners as part of a security system, that's fine; I really don't care. What I do care about is that "fingerprint scanner says yes" does not imply "Alice is currently holding her thumb against the phone screen", or other such real-world scenarios. Alice holding her thumb against the screen might cause the fingerprint scanner to say yes; and it's perfectly fine to make that assumption when designing a UI (where failure is mostly an irritation). Yet security design should not make that assumption, since it may hide all sorts of vulnerabilities. As an analogy: a "Keep off the grass" sign is not the same as there being nobody on the grass. It's good enough for something inconsequential, like turning on a sprinkler system (if you get wet, you should've followed the sign; similar to a UI breaking if the user doesn't use their phone in standard ways); yet it's not enough to, say, store our valuables on the grass, in the hope that nobody can get to them.
- FabHK 4y ago
  > "fingerprint scanner says yes" does not imply "Alice is currently holding her thumb against the phone screen" Which is why GP carefully qualified his statement that "administrator is present" with the appropriate assumptions.