And also – the "users" in a so-called "user story" are not necessarily true application users, and they do not have to be. In the case of describing a "backend service," for example, the "user" would be the (whatever-it-is) that issues the SOAP-call to that service.
Furthermore: some things, like "implement hashing on passwords," might not correspond to any "user story" at all! After all, what does any "user," who merely proffered you a correct password, know or care of what you subsequently did with it, how you verified that it was correct, or how you stored it?
As Vicki very well put it, the wisdom of "user stories" is to cleanly separate "what and why" from the otherwise uninteresting drudgery of "exactly how." Indeed, IMHO it may well be said that the purpose of this entire exercise is to divorce the description of "what and why" from the "how" with which it is much-too-often conflated.