Re: Password safe web application with postgre

Bohdan Linda wrote:
> Hello,
>
> I have the following problem. A multiuser app has authentization and
> authorization done based on pgsql.
>
> The frontend is web based so it is stateless; it is connecting to database
> on every get/post. There is also a requirement that the user is
> transparently logged in for some period of time.
>
> Tha most easy way is to store login credentials into the session. The
> drawback is that session is stored in file, so the credentials are
> readable. I want to avoid it.

Don't store login info in the session - just the user's ID and whatever 
other session data is appropriate for your application. The basic idea is:

1. User makes a request.

2. Server looks for the session cookie (require cookies - storing 
session info in the URI means that links to off-site locations will leak 
the session ID via the referrer information).

2a. If it exists, grab the user's ID from the session data and use it 
for authorization.

2b. If it doesn't exist or if it exists but the session is no longer 
valid, route user to login page. The user enters their username and 
password. The server authenticates the information and establishes a 
session tied to a cookie. The value of the cookie must be non-guessable 
or your app is vulnerable - Google around and you'll find some papers 
about some major websites that have stupidly stored login data in the 
cookie. Base the cookie vaue on a good random number generator. The MD5 
of a long random number is often used - I'm not a crypto guy so I can't 
pass judgment on how "random" that is.

 From here on, the browser/server is just passing that random token back 
and forth. It contains no username or password info. Since it is the 
temporary pass to the system, it still needs to be protected. That's why 
cookie-based sessions are preferred to URI based ones and HTTPS is 
preferred to HTTP. And avoid the mistake of having a login that sits on 
an HTTP page but posts to an HTTPS page. It's vulnerable. One of my 
banks still does this so I always just click "login" which fails but 
takes me to the HTTPS login page where I do my actual login.

The session info on the server end only needs the ID of the user 
associated with the session for authorization purposes. The user's name 
and password need not be stored in the session - just enough info to be 
able to determine access rights.

You can make some modest security improvements by storing things such as 
the browser identification and IP address in the session data and 
verifying it on each request but IP verification fails if the user is 
behind a proxy like AOL's where each request may come from a different IP.

Cheers,
Steve