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