Allowing this sort of database access from a website is a COMPLETE no-no. Ignore whether the passwords were encrypted or not, that's not an issue.
But a website that allows modification of SQL queries in the URL string... you might as well just turn the machine off for the good it'll do.
Seriously, what's hard about submitting the page query data to the server (NOT as an SQL query, but as form entries), having the server scripting language sanitise that information down to the invididual elements on the submitted form and building its *own* SQL query from pre-defined stanzas that it concatenates based on the form data. If you have a brain, you even make correlate the form data against the login/form accessed to ensure it has access BEFORE you build the SQL query. In this way, it's impossible for someone to turn SELECT ALL FROM... into DROP TABLE or anything else equally as dangerous, such as accessing private fields with passwords in them. The worst that'll happen is they might find some concatenation of the pre-defined stanzas that reveals a *little* more information than you wanted them to.
This is like having a DOS command prompt in every page of your website, and the commands typed in are tacked onto the URL and executed as-is by the server-side. It's *that* dangerous and, yes, *that* stupid.
http://www.theregister.co.uk/?deltree_C:\*.* <-- would you allow that to even be POSSIBLE, let alone likely to actually execute (even if running on a read-only filesystem)? No. So don't embed ANY form of direct SQL in GET/POST queries.