Jeebus, it's just meant to show that you could do a select in one go without having to do them one at a time cascading to the next one if no match. I don't know what you need to select, that's up to the reader. That's the point of psuedo code. You saw select and made the connection to "it's a database query". Boom. point made. Again, I understand the concept of user provided pass and a hash with a salt. If you can't really put 2+2 together to see that you're taking the 3 different options then I'm sorry for you.
Look, whatever it’s meant to show, it also looks like a security nightmare that implies a lack of understanding. Are we supposed to ignore that because it’s pseudo code? Clearly some of us think not.
It’s not the select that’s the problem, it’s the clause, so your explanation also seems to imply that misunderstanding on your part is real.
You have to calculate at least one hash and you only have to perform one query (as it can grab multiple hashes at once), and that query should not choose what to return based on the content of the hash(es).
Pseudo code is supposed to strip away details that might distract from fundamentals, yet your pseudo code and subsequent replies suggest that your understanding is contrary to the actual fundamentals of checking a password securely. Start with limiting the set by choosing by user, never by hash.
Jeremy Evans goes over many of the fundamentals[1], including why restriction of the selection is important, and why restriction of access to hashes (i.e. not sending them from the initial machine) are important. In his own framework (Rodauth) he doesn’t even allow selects of the hashes to be returned to app, let alone used as part of the where clause. Note the clause in each of the functions he defines (12:53 and 14:05).
