An Authentication hole in 2-tier Applications
This is probably the oldest hole in authentication, and it’s still floating around.
How should a 2-tier application verify the password entered by the user? Three common approaches are:
- Invoke a database stored procedure, pass it the username/password - let the stored procedure verify the credentials.
- Execute a dynamic SQL statement that checks if a row exists with the username/password combination
- Get the password of the user from the database and compare it at the client.
The first is a relatively safe approach. The second, with dynamic SQL statements, is a candidate for SQL Injection. If the input validation is weak, an adversary could mess with the dynamic query’s logic.
The third, however, is the most insecure, and that’s what I saw in a test last week. When the user entered his username/password, the client fetched the right password from the database and compared it with the input. If they matched, the client considered the user authenticated.
Why is the third approach so unsafe?
One, with a sniffer, I could see the password of any user: all I had to do was type in any valid username, say admin, with a wrong password and the client would fetch the right password to compare. My sniffer could see the right password. Network layer encryption like IPSEC does not help - an adversary could intercept the data when it was in plain-text by using WPE Pro, a packet editor that intercepts socket calls in memory.
Second, the client verified the user - not the server! The client checked the response from the server to decide if the user is authenticated and enabled all the menus accordingly. An adversary could now fool the client into accepting any password by modifying the response from the server. It’s easy: tools like Interactive TCP Relay (ITR) provide a GUI environment to edit requests and responses.
Plynt provides penetration testing and code review services to clients worldwide. If you are interested, please contact us for a quote. We’ll get back to you within one working day.Add yours.closed for this post.
Agree totally with Guruprasad, though example is very elaborative but cannot be justified in reality.
Nobody would be stupid to use the third design, it similar to a parctise of displaying password in clear text, rather than masking it when user enters the same in any form/field.
Monthly Archives
- September 2008
- August 2008
- July 2008
- May 2008
- April 2008
- March 2008
- January 2008
- December 2007
- November 2007
- April 2007
- March 2007
- February 2007
- January 2007
- August 2006
- July 2006
- June 2006
- May 2006
- April 2006
- March 2006
- February 2006
- November 2005
- October 2005
- September 2005
- August 2005
- July 2005
- June 2005
- May 2005
Syndication
You can read full entries of Palisade Blog using an RSS reader. Use this link —




Are there people using such mechanism?
I mean client pulling password from backend or server to do comparison. Also should there be a recommendation or suggestion section in ur blog?
-
Gp