I am studying

Web Application Security, A Beginner's Guide Paperback – November 3, 2011 by Bryan Sullivan (Author), Vincent Liu (Author)

On pp 69, "Validating Credentials", they say you can validate credentials based on

  1. Comparison logic in application with plaintext passwords
  2. Comparison logic in database with plaintext passwords ....

I cannot understand the difference between logic in application vs database.

The text for "Comparison logic in application..." says:

The application sends a request (for example, SQL query or LDAP query) to the back-end database to retrieve the record associated with the username...

The text for "Comparison logic in database..." says:

This technique involves crafting a SQL query or LDAP request to the back-end system with a conditional statement that asks the back end to return any records with matching fields that correspond to the supplied username and the supplied password

I cannot grasp the difference between the two. I would think that the application also crafts an SQL query or LDAP request to the back-end system with a conditional statement.

How do I visualize this? Thanks!


Think about it this way:

Most system have multiple components. In a traditional set up this is usually a client that is distributed to the users, a server, and a database.

The database is usually a commonly used, highly optimized piece of software written by somebody else, whereas servers are very often custom software that is written by you specifically for the clients' needs

In this example, the server talks to the clients. If the database would talk directly to the clients it generally makes your system extremely insecure because the client (and therefore your users) has access to all your data.

The client sends a request to the server asking to verify the details that were entered with the database. Once the client is verified the server decides which information the client can see, for how long the client can request that data without having to be re-verified, the amount of data that is transmitted, etc.

Take for example google. When you google your search query, you open up a Web page (the client). The client talks to the server as you are interacting with google, the server sends you back suggestions and eventually gives you the answer to your question, but you as a client don't need access to all information in google, only google's servers should have access to all this information, and should only show you what you need to know.

Another analogy, when you're in a restaurant, you are the client, your waiter is the server, it understands what you need, and tells the kitchen (the database) what to cook you, and once it's ready it'll bring you the result. That's about exactly what a server does.

Feel free to ask further questions :-)

  • I like the restaurant analogy – Glowie Dec 2 '14 at 18:22

both methods in the questions deal with 'with plaintext passwords', which is a very bad idea. Yet , for illustrative purposes is can help to clarify things.

Comparison logic in application:

$result = sql_query('SELECT users.password FROM users WHERE userId = %i', $userId);
if ($result['password'] == $userPassword) {
    print 'access granted';
} else {
    print 'wrong credentials';

Comparison logic in database:

$result = sql_query('SELECT (users.password = %s) AS passwordOk FROM users WHERE userId = %i', $userPassword, $userId);
if ($result['passwordOk'] == 1) {
    print 'access granted';
} else {
    print 'wrong credentials';

There are several reasons why the second option is deemed less secure. A typical problem with sending a security sensitive query to a database server is that the query could very easily end up in a log file. Other issues come from the fact that most database servers do not implement strong password hashing algorithms (such as BCrypt) and only provide general purpose hashing algorithms instead.

Hope this helps

  • 1
    With LDAP the second option has several advantages. It keeps the passwords hashes centralised, and enforces a uniform password policy. – paj28 Dec 2 '14 at 12:57
  • @paj28, think I should remove the disadvantages? or should I add your comment as an advantage? – Monika Dec 2 '14 at 13:12
  • The disadvantages you mention are valid, so do keep them. I guess you could contrast them with the advantages I mention in my comment. The advantages apply when you have multiple applications using one credential stored, which is more common with LDAP than SQL, but not exclusive. – paj28 Dec 2 '14 at 13:19


The application supplies the credentials via the application code logic to the server as a payload of the application's data flow.


The connection directly connects to the database and issues database commands in order to confirm the credentials.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.