> 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.