The question is “where did the error message originate?”

If they are using a web-based application that talks direction to a database and sends the login information in plain-text, then they should be bent over and spanked.

If they are sending the queries through a web service that does the talking (to the database) then the error message might not do you any good unless you can find another way to get inside the network.

Or maybe the web server is just a dumb front-end that talks to an application server in another DMZ, which then calls a web service that connects to the database with the credentials.

It would certainly give an unethical (or grey hat) a good excuse to dig deeper into what other anomalies they could discover on someone’s site.

It is possible that they believe they are fully in compliance with the law and security standards if they think this message never leaves their protected internal network. It could be news to them that it is actually forwarded back up the chain all the way to the end-user presentation.

Somewhere along the development cycle, some piece of these applications was goobered.

“Duh,” you say. “That’s the point.”

I just wanted to point out that the actual weak link could be in many different places and finding it would take a bit more work. The average end-user getting that error message would probably just hit refresh and ignore it.