NYCPHP Meetup

NYPHP.org

Sessions and Authentication (was: [nycphp-talk] AJAX and State)

Kenneth Downs ken at secdat.com
Fri Sep 7 10:41:13 EDT 2007


bz-gmort at beezifies.com wrote:
> Kenneth Downs wrote:
>> That can only be done if the password is stored on the browser 
>> between requests.  No thanks!
>> At any rate, in principle I believe that sessions are a bad way to do 
>> things, they just have that bag-on-the-side feel.  The only permanent 
>> use of a session in Andromeda is to store user information, notably 
>> user_id and password.
>
> Why do you need to store the password?
>
> Once the user has authenticated, their authenticated.  You don't need 
> to keep a password lying around past that point unless you want to 
> make them re-authenticate each time they access some data.  And since 
> your storing that information on the server, it's somewhat irrelevant 
> to store it since your already trusting whatever other mechanisms you 
> have between the user and the server.

Database access.  Each trip to the server requires that you make a 
connection to the server.

In the PHP+MySQL world it is taken as an article of faith that you 
connect to the database as a super-user or admin, and your application 
code handles security.  But not everybody thinks this way.

That approach has many problems in a large-table-count system, including 
but not limited to documentation of security policies, effectiveness, 
efficiency, and scalability.  Probably the the most significant problem 
is that you cannot provide your customer's IT departments with true 
access to the database, which is a requirement to get some jobs.

As part of an overall more secure architecture, we connect the user to 
the database with a real database account, the database server is in 
charge of security and the program code has nothing to do with it.  In 
fact, the program by itself has no ability to connect to the database 
unless given credentials by a user.  This solves many problems, but it 
does require us to keep track of the user's password once they've given 
it to us, so that we can connect to the database on each of their 
requests. 

Hence my only use of a session.

>
> Though I would point out that with browsers these days, that password 
> is gonna be stored on the browser no matter what you do short of 
> embedding a flash or java applet to process the logon.  They save so 
> much information, the user might have to explicitly confirm saving the 
> address, but it will be saved.

True, you cannot stop the various "wallet" mechanisms from storing it 
<Sigh>.  But at least I did not add yet another :/


-- 
Kenneth Downs
Secure Data Software, Inc.
www.secdat.com    www.andromeda-project.org
631-689-7200   Fax: 631-689-0527
cell: 631-379-0010




More information about the talk mailing list