How tight is this password protection?

Question

Hi
I'm looking for a little clarification on whether my password
security is
robust enough.
I am using asp/vbscript on a windows server
I always POST variables from the form to the asp script, I
then use
something like vMYPIN=request.form("pin_number") to get the
pin that the
user typed
in. I then use some sql to see if that pin exists in the
database, and
if it does then i use session("PIN")=True to set the session
variable.
On subsequent pages the first line is if(session("PIN") then
page is ok
else redirect to logon page.
I hope that covers what i do, would really appreciate some
feedback on
whether this is a good and secure method.

Answer 1

Many thanks for this that has certainly helped me a lot
"Lionstone" <[email protected]> wrote in
message
news:[email protected]...
>
> "dave" <[email protected]> wrote in message
> news:[email protected]...
>> it's a mysql database of delegate data.
>>
>> I've been reading things about sql injection attacks
and have become a
>> little anxious about my site security.
>>
>> Are my methods secure or what should i be doing?
>>
>> Thanks for your reply
>
> This type of security and SQL injection are not really
related.
> In any case, session variables are your best option
since they reside on
> the server. If someone has server access, then you've
got bigger problems
> to solve.
>
> If the user needs some sort of username/password
combination, then it's
> best to have an SSL certificate and to use https during
login. If you use
> normal http, then the username/password are transmitted
in plain text.
> Nothing is perfect, but a combination of https and
session-based security
> is about as good as you'll get on the web.
>
> Rather than just check for somevar=true, consider
storing the username in
> a session variable (which is what DW's log in user
behavior does). That
> way, should you desire, you can even tell who did what
instead of just
> that "a logged in user" did something.
>
> As far as web security goes, protecting against SQL
injection is at least
> as important as controlling access. Beating SQL
injection is simple, but
> don't confuse simple with "very little work." There is
only one rule -
> validate, validate, validate. Client-side (javascript)
validation is
> useless for security purposes. You can use it as a
front-line option so
> the user doesn't have to wait for the form to submit if
they've made an
> honest mistake, but that's all it's good for. Validate
again on the
> server. Validation consists of two parts:
> 1. Data type
> 2. Data domain
>
> Data type is easy; you can use isNumeric, isDate, etc.
Data domain will
> take more thought. This is where you protect against
people entering
> in -1 for age, for instance, or Jan 31, 1799 as their
birthdate (and no,
> you can't rely on your form since anybody can build a
form that submits to
> YOUR web site). Also check string lengths - if a text
box allows up to 50
> characters, check the length of the input to make sure
it's no more than
> that.
>
> Last step - use prepared statements for your SQL. This
often means stored
> procedures, but doesn't have to. DW with the 8.02
updater will use
> prepared statements, so look at the code generated by
any of the server
> behaviors for the basics.
>
> Again, nothing and nobody is perfect, so make sure that
the account used
> to access the database has minimal permissions - exactly
what it needs,
> and not one drop more. I prefer to leverage stored
procedures for this;
> if the web account is allowed to take an action, then
there's a procedure
> for it. The account has zero permissions on any tables
and cannot do
> anything besides execute those procedures I've given
permission for.
>
> Hope that gets you started. :)
>